On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov <[email protected]>wrote:
> В Mon, 27 Jan 2014 04:18:20 +0000 > David Anderson <[email protected]> пишет: > > > 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 > >
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
