В Mon, 27 Jan 2014 05:39:58 +0000 David Anderson <[email protected]> пишет:
> 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. > 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
