NetworkManager не показывает соединение по Ethernet

После обновления с Ubuntu 16.04 до 16.10 я заметил, что мое устройство eth0 пропало. Моя машина также по умолчанию не подключается к сети, и соединение не отображается в NetworkManager gnome.

Вывод dmesg показывает, что устройство было переименовано:

[    1.109498] igb 0000:26:00.0 enp38s0: renamed from eth0

Я могу заставить подключение работать, выполнив ifconfig enp38s0 0.0.0.0 0.0.0.0 && dhclient.

Как мне сделать так, чтобы

• это сохранялось, чтобы подключение устанавливалоcь автоматически
• устройство отображалось в NetworkManager

Я уже заглядывал в /etc/network/interfaces, и ни eth0, ни enp38s0 там не указаны.

С чистой установкой сервера 17.10 с LXDE у меня возникла эта проблема, я читал все повсюду и пробовал все. Это также не давало мне использовать openvpn через сетевой менеджер.

Следующее исправило проблему:

Мой файл /etc/network/interfaces:
удалил все строки, кроме:

auto lo
iface lo inet loopback

Затем я отредактировал /etc/NetworkManager/NetworkManager.conf
из:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

[device]
wifi.scan-rand-mac-address=no

Добавил строку [keyfile]

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

Текущий /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile

[keyfile]  
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

[ifupdown]
managed=true

[device]
wifi.scan-rand-mac-address=no

Последняя выполненная команда:

sudo service network-manager restart 

И все корректно отображалось в сетевом менеджере после нескольких часов борьбы! Это для домашнего сервера, возможно, это было вызвано настройкой IP во время установки, что добавило значения для статического IP в /etc/network/interfaces.

У меня была такая же проблема, и я просто добавил ,except:type:ethernet в /etc/NetworkManager/NetworkManager.conf

Результат:

[main]
plugins=ifupdown,keyfile

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

[ifupdown]
managed=true

Я отчаянно пытался найти проблемы с конфигурацией в /etc/NetworkManager/, но не понимал, что /usr/lib/NetworkManager тоже существует.

Проблема была в /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

В итоге я полностью удалил файл, быстро перезагрузил, и все снова заработало.

Выполнение sudo apt update привело к тому, что ethernet не отображался в виджете сети, но сетевые подключения через ethernet продолжали работать.
Это произошло, когда /var/log/apt показал:

Preparing to unpack .../linux-firmware_1.187.10_all.deb ...
Unpacking linux-firmware (1.187.10) over (1.187.9) ...
Preparing to unpack .../python3-pil_7.0.0-4ubuntu0.3_amd64.deb ...
Unpacking python3-pil:amd64 (7.0.0-4ubuntu0.3) over (7.0.0-4ubuntu0.2) ...
Setting up linux-firmware (1.187.10) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-66-generic
update-initramfs: Generating /boot/initrd.img-5.4.0-65-generic
Setting up python3-pil:amd64 (7.0.0-4ubuntu0.3) ...
Log ended: 2021-03-11  13:11:10

Я отредактировал /etc/NetworkManager/NetworkManager.conf из:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true      #Исправлено: Это было "false" <<<<<<<<<

[device]
wifi.scan-rand-mac-address=no

И добавил отсутствующий [keyfile] плюс строку устройств <<<<<<:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

Затем я перезапустил NetworkManager, и проблема была решена. Проблема была вызвана обновлением linux-firmware.

[keyfile] unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

Это решило проблему для меня.

Ubuntu 20.04.3 LTS, AMD Ryzen 3900 в ноутбуке.

Спасибо

Отсутствие записи [keyfile] казалось проблемой для меня на Kali 2022, работающем на RasPi 4, точно как предлагали другие ответы здесь (поэтому благодарности вышеуказанным ответам!).

Тем не менее, редактирование файла NetworkManager.conf можно считать краткосрочным решением, так как этот файл может быть заменен/обновлен при обновлении пакета. Хотя ваш менеджер пакетов может уведомить вас о конфликте – apt обычно это делает – лучше перестраховаться. Более стабильным решением было бы использовать существующий каталог /etc/NetworkManager/conf.d и поместить туда свою пользовательскую конфигурацию. (Примечание: Это каталог конфигурации для современной версии NetworkManager, и ваш может отличаться! Запустите NetworkManager --print-config, чтобы узнать, где находятся ваши файлы конфигурации NetworkManager)

Назовите файл как хотите, я выбрал 99-keyfile-fix.conf, просто убедитесь, что он заканчивается на .conf. Все, что вам нужно добавить туда, это строки [keyfile], так что:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

Сохраните файл и выполните systemctl restart NetworkManager (или service NetworkManager restart, если вы все еще это используете), и когда NetworkManager перезапустится, вы снова должны увидеть ваши подключения там.

В качестве небольшого дополнительного совета, если вы делаете это на настольном ПК, вы можете опустить except:type:wifi, если у вашего настольного ПК нет WiFi-устройства. Аналогично, если у вас нет устройства с поддержкой Ethernet (в таком случае вы могли попасть на неправильный ответ AskUbuntu!), вы можете опустить except:type:ethernet.

Я столкнулся с этим на 1 из 4 систем, которые недавно были обновлены с ubuntu 20.04 до Ubuntu 22.04.

Добавление

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet

в /etc/NetworkManager/NetworkManager.conf сработало, но это все еще оставило вопрос о почему это было необходимо на одной системе, а не на остальных трех.

/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf существовал и имел одинаковое содержимое на как “хорошей”, так и “плохой” системе.

Тем не менее, NetworkManager –print-config выявил разницу: на “хороших” системах 10-globally-managed-devices.conf был очищен пустым файлом в /run, на “плохой” системе этого не было.

Делая еще одно обоснованное предположение, я решил выполнить “dpkg -l | grep netplan” на “хороших” и “плохих” системах. Похоже, что разница между “хорошими” машинами и плохой машиной заключается в том, что хорошие машины имели установленный netplan.io, а плохая машина – нет.

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

Я установил netplan.io на “плохой” системе, вернул изменения в /etc/NetworkManager/NetworkManager.conf и перезагрузил систему. После перезагрузки проводное соединение продолжало работать.