FS#33923 - [dhcpcd] Interface names change between install disk and initial boot

Attached to Project: Arch Linux
Opened by Skye Berghel (sberghel) - Tuesday, 19 February 2013, 07:05 GMT
Last edited by Dave Reisner (falconindy) - Tuesday, 30 July 2013, 11:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Ronald van Haren (pressh)
Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

Interface names change between install disk and initial boot. When I was installing Arch with the install disk, ip addr showed that I had two devices, lo and eth0. When I rebooted into my new system, ip addr showed that I had two devices, lo and enp3s0.

According to the Beginner's Guide, "From systemd-197's release and onward, udev now assigns predictable, stable network interface names that deviate from the legacy incremental naming scheme (wlan0, wlan1, etc.). These interface names are guaranteed to be persistent across reboots, which solves the problem of the lack of predictability of network interface name assignment."

"Persistent across reboots" means "when you reboot, the name will not change". This did not happen. The name changed.

Additional info:


Steps to reproduce:

(1) Take an Arch Linux CD (I used the latest one, 2013.02.01)
(2) ip addr
(3) Install and reboot.
(4) ip addr
This task depends upon

Closed by  Dave Reisner (falconindy)
Tuesday, 30 July 2013, 11:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should have been fixed by 2013.06
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 19 February 2013, 21:46 GMT
I guess this is an issue with dhcpcd startup order [#1]. Indeed, while booting ISO sometimes appears renamed, but others no because interface is busy.

[#1]systemd-devel@lists.freedesktop.org/msg08426.html"> http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg08426.html
Comment by Tom Gundersen (tomegun) - Tuesday, 19 February 2013, 22:08 GMT
In the short-term we could 'solve' this by adding 'After/Wants=systemd-udev-settle.service' to dhcpcd.service.

In the long-term we might want to switch to a proper network daemon (such as NetworkManager) which will wait for udev to finish processing network devices before using them. However, as was pointed out on the ML, that would bring with it a considerable amount of dependencies, so it is not ideal...
Comment by Thomas Bächler (brain0) - Tuesday, 19 February 2013, 22:30 GMT
So first, network daemons should use netlink to listen for interfaces (Lennart's words!). Then, they should use netlink, but also listen on udev. Or only listen on udev? At some point, there should be some stability here!

We certainly don't want systemd-udev-settle.service. There's a race condition between udev and other netlink listeners, and it must be solved in either udev or the kernel.
Comment by Tom Gundersen (tomegun) - Tuesday, 19 February 2013, 22:44 GMT
Well, the situation is not ideal, but I cannot see a way around services listening on udev (as well as netlink). Even if the interface names are not changed, other properties might be (and are) set by udev rules, which should (must) happen before the devices are being used.

See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=59964#c1.
Comment by Samael Z. Emrys (skdermk) - Friday, 01 March 2013, 00:40 GMT
I used net-auto-wired for configuring my wired connection but I didn't see any interface name change upon boot (I didn't use the scrip mentioned in the beginner's Guide Wiki). Name 'eth0' for my ethernet connection remained constant upon reboot after installation.
Comment by Dimitri (diman) - Thursday, 21 March 2013, 17:59 GMT
like described in https://wiki.archlinux.org/index.php/Network_Configuration

just use
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

to disable automatic names.
Comment by Marius (65kid) - Wednesday, 05 June 2013, 09:39 GMT
I proposed an alternative dhcpcd service file a few weeks ago which doesn't time out if the interface doesn't come up by specifying -b instead of -w (dhcpcd-no-wait@.service). see https://bugs.archlinux.org/task/34956

As far as I can see, this service file could solve this issue by using a udev rule to start an instance for all renamed interfaces:
SUBSYSTEM=="net", NAME!="", ENV{SYSTEMD_WANTS}="dhcpcd-no-wait@$name.service"

This would provide the same functionality as the dhcpcd.service without the race condition. I tested this once on my local machine and it seemed to work as expected. Comments welcome...
   dhcpcd-no-wait@.service (0.3 KiB)
Comment by Dave Reisner (falconindy) - Friday, 07 June 2013, 13:11 GMT
Fairly sure we've fixed this in 2013.06 -- I do not believe using -b is a good idea with the udev activated unit since it only serves to increase the gap between the service forking (the point at which systemd activates network.target) and when the network *actually* comes up.

Loading...