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

[Andrey Borzenkov]

В Mon, 27 Jan 2014 05:39:58 +0000
David Anderson <dave at natulte.net> пишет:

> On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov <arvidjaar at gmail.com>wrote:
> 
> > В 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)
> > --><--
> >
> 
> Can you link me to the relevant spec? I suspect that Intel interpreted this
> as "unique value within a bus" instead of "unique machine-wide," but I'm
> interested in the context surrounding that statement.
> 

http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf

7.42
Onboard Devices Extended Information (Type 41)

> 
> If it is indeed a firmware bug, there's nothing obvious for udev to do. A
> suggestion on IRC was to disambiguate by bus/device ID in such cases
> (lowest bus:device gets eno1, next gets eno2, etc.). I don't know if this
> is desirable, or even if udev can do this since it would require a second
> pass over the affected devices with a global view of all such devices.
> 

This means interface names will be dependent on scan order (the first
one wins) which rather defeats the idea of automatically generated
persistent names.