[systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces

[David Anderson]

This is a continuation of a discussion I had on #systemd. I have a server
that has two onboard ethernet chipsets, and a fresh Arch linux install
(systemd/udevd v208). On this system, consistent interface naming fails,
and I end up with eno1 and eth1 after bootup.

The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the
apparently relevant part is:


Jan 26 19:10:38 ironman kernel: e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000
Network Connection
...
Jan 26 19:10:38 ironman kernel: e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000
Network Connection
...
*Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface
name eth1 to eno1: File exists*
Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network
Connection.
*Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0
to eno1*


>From that, it appears that udevd is trying to rename both interfaces to
eno1.

As you can see from the boot log, the two chipsets are on separate PCI
buses (bus 0, dev 0x19, and bus 2, dev 0).

Looking in /sys , neither device has an acpi_index attribute, and both have
an "index" attribute equal to 1. I'm by far not an expert on this data, but
index=1 naively sounds right, since they're both the only ethernet device
on their bus. According to The Source (
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131),
lack of acpi_index means that "index" is used instead, and we end up
with two devices mapping to eno1.

Further debugging information: full `dmidecode` output (
http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys
( http://pastebin.com/raw.php?i=TbSvDMSB ).


At this point, I need more expert help. Is this a udev bug where it
produces incorrect output in the presence of multiple PCI buses? Is it a
firmware bug where my motherboard provides incorrect data to udev?
Regardless, should udev be capable of handling this gracefully? Should I
report a bug? Do you need more information from my system?

Thoughts on temporary workarounds so that I can continue configuring my
system with consistent interfaces also welcome, but my major concern is
whether udev is doing the right thing, and how to make it do the right
thing if not.

Cheers,
- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140127/64a63ae3/attachment.html>