Обновленный к 19,04 и НИКАКОЙ Ethernet теперь

Кажется, та же самая ошибка здесь. Я думаю, что проблема вызвана тем, что NetworkManager выполняет неправильную процедуру dhclient и вызывает конфликты IP в коммутаторе моей сети, в результате чего соединение обрывается на 30 минут. Смотрите также эту ошибку: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1793763

ОБНОВЛЕНИЕ: Чтобы обойти эту проблему, вы можете используйте ifplugd вместе с ifupdown для обработки соединений Ethernet, при этом все еще используя NetworkManager для беспроводных соединений. Для этого:

Установите ifupdown и resolvconf:

apt install ifupdown resolvconf

отключите systemd-resolved

systemctl stop systemd-resolved
systemctl disable systemd-resolved.service

отредактируйте /etc/NetworkManager/NetworkManager.conf, чтобы оставить устройства ifupdown в одиночку, используйте resolvconf для обновления /etc/resolv.conf и используйте простые DNS-серверы с сервера dhcp вместо службы 127.0.0.53, разрешенной системой.

[main]
# don't manage devices configured in /etc/network/interfaces
plugins=ifupdown,keyfile
# pass nameserver dhcp config to resolvconf
rc-manager=resolvconf
# use plain nameservers directly from DHCP server instead of intermediate resolved
dns=default

[ifupdown]
managed=false

Затем добавьте следующие строки в / etc / network / interfaces для определения устройства Ethernet (в моем случае enp0s25)

iface enp0s25 inet dhcp
iface enp0s25 inet6 auto

Убедитесь, что в файле нет auto enp0s25 строк, потому что ifup должен выполняться не автоматически при загрузке, а с помощью ifplugd при подключении к сети Ethernet.

Итак, затем установите ifplugd и настройте его так, чтобы устройство enp0s25 было включено для корректного подключения / отключения триггеров.

apt install ifplugd

Также, сделайте файл /etc/dhcp/dhclient-enter-hooks.d/resolved пустым, потому что иначе resolvconf никогда не будет работать с ifupdown:

echo "" > /etc/dhcp/dhclient-enter-hooks.d/resolved

также не удаляйте этот файл, или он будет переустановлен при следующем обновлении системы.

Наконец, запустите и включите ifplugd, перезапустите NetworkManager для обновления конфигурации.

systemctl restart NetworkManager
systemctl enable ifplugd
systemctl start ifplugd

и / или перезагрузите компьютер, чтобы проверить, все ли настроено правильно.

Отказ от ответственности 1 : Я не воспроизводил этот скрипт при новой установке Ubuntu, чтобы проверить, полностью ли он корректен (однако я проверил bash_history;). Пожалуйста, ответьте, если что-то не работает.
Отказ от ответственности 2 это работает для Ubuntu LTS 18.04
Отказ от ответственности 3 : Возможно, это также может работать с системным разрешением или даже с DNSMasq или без привязки, но я не знаю как точно, и я лично этого не хочу.

Я столкнулся с той же проблемой, что и вы. Обходной путь, который я нашел, состоял в том, чтобы заставить netplan заново сгенерировать конфигурацию сети:

sudo netplan generate
sudo netplan apply

После выполнения двух команд вы сможете настроить сеть с помощью ваших обычных инструментов конфигурации.

По умолчанию, netplan будет иметь файл конфигурации с именем: /etc/netplan/01-network-manager-all.yaml со следующим содержимым:

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

Это будет просто скажите системе, чтобы все интерфейсы контролировались сетевым менеджером. Я не знаю точно, почему это сработало для меня, потому что netplan уже должен был управлять сетевым интерфейсом.

Для справки вывод lspci для моего контроллера Ethernet:

$ lspci | grep -i ether
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Решил это для меня, установив dkms для драйвера для r8168. Правда, под ядром 4.18 сетевой адаптер работал под r8169 просто отлично, но не под «улучшенной» версией ядра 5.0, используемой с kubuntu 19.04.

Я просто публикую свои наблюдения здесь в качестве ответа. Я надеюсь, что в конечном итоге я найду решение, поэтому я смогу соответствующим образом обновить этот ответ.

У меня точная проблема:

Во время включения этой проблемы не происходит . Но это происходит всегда после перезапуска ОС ( программная перезагрузка ).

Пока единственным решением является следующее: Отключите кабель Ethernet; загрузите свою машину; подключите кабель после завершения загрузки. Соединение Ethernet никогда не будет работать, если сетевой кабель подключен во время загрузки!

Я последовал советам в https://ubuntu-mate.community/t/19-04- Ethernet-проводное соединение отказывается подключаться при подключении до загрузки / 19333/8 , и как оригинальный постер, у меня не было улучшений. Вот мои наблюдения, и я прошу вас ( Once_a_NoOb_always_a ) проверить их:

1. Эта проблема началась после обновления с Ubuntu 18.10 до 19.04. Первоначально (во время первой перезагрузки после обновления) проблема не возникала. Но позже (после второй перезагрузки) это начало происходить настойчиво .

2. Если запустить машину с отключенным кабелем Ethernet и подключить его после загрузки, проблема не возникает .

3. В любом случае соединение на уровне канала будет успешным (даже после того, как вы отсоедините и снова подключите кабель или после выполнения ip link set enp3s0f1 down и ip link set enp3s0f1 up). По маршрутизатору видно, что соответствующий порт Ethernet подключен и пакеты перемещаются в обоих направлениях. Однако происходит что-то очень странное: я использую статические IP-адреса для своего проводного и беспроводного соединения в моем Ubuntu; они заканчиваются на 14 и 15 соответственно. Когда я включаю интерфейс Ethernet (проводной), мой маршрутизатор видит один и тот же IP-адрес, оканчивающийся на 14 в обоих интерфейсах Ubuntu box.

Мой предварительный вывод, что сетевой стек каким-то образом смешивает MAC-адреса двух интерфейсов. (Обратите внимание, что обычно мой беспроводной интерфейс отключается аппаратно, когда я загружаюсь и использую свой компьютер; обычно я использовал только проводное соединение. Однако даже в таком случае мой обновленный Ubuntu box не подключается к сети Ethernet. Похоже, что решение физически отключает кабель Ethernet во время загрузки и подключает его после загрузки.)