FS#53606 - [dhcpcd] Does not work with 'predictable network interface name' eno[X]
Attached to Project:
Arch Linux
Opened by Gerry Kessler (renegat) - Friday, 07 April 2017, 17:02 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 10 April 2018, 14:22 GMT
Opened by Gerry Kessler (renegat) - Friday, 07 April 2017, 17:02 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 10 April 2018, 14:22 GMT
|
Details
Description:
Instead of enp[X]s[Y] the 'Intel Corporation Ethernet Connection I218-V' adapter is named to eno[X] on Intel NUC. With this name dhcpcd fails irregulary on boot. Restarting dhcpcd service does irregulary fail / work With predictable network interface names disabled it works reliable again. Additional info: dhcpcd 6.11.5-1 systemd 232-8 config and/or log files etc: kernel: e1000e 0000:00:19.0 eno1: renamed from eth0 dhcpcd[454]: eno1: waiting for carrier dhcpcd[454]: eno1: removing interface kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready dhcpcd[454]: eno1: waiting for carrier dhcpcd[454]: eno1: removing interface kernel: e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready Steps to reproduce: - enable dhcpcd.serivce or systemd-netword with dhcp-profile - boot - in most cases network adapter named 'eno[x]' will not be configured - disable predictable network interface naming - reboot - eth0 will be configured |
This task depends upon
Here's a dhcpcd log from a clean boot with "persistent" naming enabled.
Mar 27 22:39:48 [493]: dhcpcd-7.0.2 starting
Mar 27 22:39:48 [493]: udev: starting
Mar 27 22:39:48 [493]: dev: loaded udev
Mar 27 22:39:48 [493]: enp5s0: executing `/libexec/dhcpcd-run-hooks' PREINIT
Mar 27 22:39:48 [493]: enp5s0: executing `/libexec/dhcpcd-run-hooks' NOCARRIER
Mar 27 22:39:48 [493]: no interfaces have a carrier
Mar 27 22:39:48 [493]: enp5s0: waiting for carrier
Mar 27 22:39:48 [493]: wlp6s0: libudev: add
Mar 27 22:39:48 [493]: wlp6s0: interface added
Mar 27 22:39:48 [493]: wlp6s0: executing `/libexec/dhcpcd-run-hooks' PREINIT
Mar 27 22:39:49 [493]: wlp6s0: executing `/libexec/dhcpcd-run-hooks' NOCARRIER
Mar 27 22:39:49 [493]: wlp6s0: waiting for carrier
Mar 27 22:39:49 [493]: wlp6s0: libudev: move
Mar 27 22:39:49 [493]: dev: wlp6s0 has settled
Mar 27 22:39:49 [493]: wlp6s0: waiting for carrier
Mar 27 22:39:49 [493]: wlp6s0: carrier acquired
Mar 27 22:39:49 [493]: wlp6s0: executing `/libexec/dhcpcd-run-hooks' CARRIER
If udev is active and running, dhcpcd will only start on interfaces which udev claims to have finished with.
Also, dhcpcd will only listen to new interfaces from udev rather than the kernel.
Lastly, there's nothing in the OP's log to indicate dhcpcd stopped udev from renaming the interface to eno[X]
The eth0 is now renamed to "enp0s25" instead of 'eno#' on NUC5I5RYK with 'Intel Corporation Ethernet Connection (3) I218-V (rev 03)' and DHCP works as expected.
So I cannot confirm if the issue persists if a network interface is renamed to 'eno#'by udev.
FS#57879was fixed, can we have those debug logs now?dhcpcd 7.0.1-1
NUC5I5RYK with 'Intel Corporation Ethernet Connection (3) I218-V (rev 03)':
Network interface still renamed to "enp0s25" instead of 'eno[#]' - dhcpcd works normal.
NUC D34010WYK Ethernet controller: Intel Corporation Ethernet Connection I218-V (rev 04) now again renamed to 'eno1':
Issue does not occur anymore for now.
Booted several times with 4.14.32-1-lts and 4.15.15-1 dhcpcd works normal now.
Whatever the problem was - it seems to be gone now.
Can be closed.