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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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

Closed by  Doug Newgard (Scimmia)
Tuesday, 10 April 2018, 14:22 GMT
Reason for closing:  Fixed
Comment by Roy Marples (rsmarples) - Tuesday, 27 March 2018, 22:55 GMT
I just tested this, and dhcpcd it not to blame.
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]
Comment by Doug Newgard (Scimmia) - Thursday, 29 March 2018, 14:43 GMT
He never said it stopped it from renaming the interface, just that when it was renamed, dhcpcd didn't work reliably.
Comment by Roy Marples (rsmarples) - Thursday, 29 March 2018, 14:49 GMT
Can the OP then please add debug to dhcpcd.conf so that we can see what udev is telling dhcpcd to do?
Comment by Gerry Kessler (renegat) - Thursday, 29 March 2018, 15:02 GMT
As I was reverting to predictable network interface naming today in order to submit the asked information I noticed that the behavior of renaming the network interfaces has changed:

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.





Comment by Doug Newgard (Scimmia) - Thursday, 29 March 2018, 15:09 GMT
There is a bug is systemd 238.0 which causes it to name the interface that way. 238.51 should go back to the eno# naming.
Comment by Eli Schwartz (eschwartz) - Monday, 09 April 2018, 18:56 GMT
Since  FS#57879  was fixed, can we have those debug logs now?
Comment by Gerry Kessler (renegat) - Monday, 09 April 2018, 22:36 GMT
systemd 238.51-1
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.


Loading...