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

[Andrey Borzenkov]

В Mon, 27 Jan 2014 04:18:20 +0000
David Anderson <dave at natulte.net> пишет:

> 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?

Looks like it. According to specs

--><--
Device Type Instance is a unique value (within a given onboard device type)
--><--

You have two devices of type Ethernet with the same Instance values.

> Regardless, should udev be capable of handling this gracefully?

You can always override udev names with your own. What do you suggest
to do automatically? There is no way to find out which interface is
really the first and which is the second.

>                                                                 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