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

[David Anderson]

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.


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

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.

In any case, I ended up writing my own rules that correctly set up
eno1/eno2 based on the port #s on the board. Slightly annoying, but short
of bugging Intel for a firmware update, not much else to do.

Thanks!
- Dave


>
> >                                                                 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/045352a9/attachment-0001.html>