Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
On Mon, Jan 27, 2014 at 1:25 PM, Thomas Bächler wrote:
> Am 27.01.2014 05:18, schrieb David Anderson:
>> Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R)
>> PRO/1000 Network Connection
>> ...
>> Jan 26 19:10:38 ironman kernel: e1000e :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*
>
> FWIW, you can copy /usr/lib/udev/rules.d/80-net-name-slot.rules to
> /etc/udev/rules.d/ and comment out line 10:
>
> # NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
This is probably the best thing to do (at least until we can figure
out something better), it will name your nics according to
ID_NET_NAME_PATH instead, which is not as pretty, but won't suffer
from the same issue.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
On Mon, Jan 27, 2014 at 6:39 AM, David Anderson wrote: >> You have two devices of type Ethernet with the same Instance values. >> >> > Regardless, should udev be capable of handling this gracefully? > 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.). Udev should not operate in the firmware namespace, and just allocate the eno1 name here. It's the firmware that "owns" these names, not userspace. > 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. Devices are independent and should not depend on each other, we cannot really depend on the state of another, otherwise unrelated, device. > 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. Yeah, that's the only real option for now. The only thing we could do is falling back to the default PCI geography name on error; but even then, it would not be predictable which of the devices with the conflicting firmware names will win at bootup. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
Am 27.01.2014 05:18, schrieb David Anderson:
> Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R)
> PRO/1000 Network Connection
> ...
> Jan 26 19:10:38 ironman kernel: e1000e :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*
FWIW, you can copy /usr/lib/udev/rules.d/80-net-name-slot.rules to
/etc/udev/rules.d/ and comment out line 10:
# NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
В Mon, 27 Jan 2014 05:39:58 + David Anderson пишет: > On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov wrote: > > > В Mon, 27 Jan 2014 04:18:20 + > > David Anderson пишет: > > > > > 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 :00:19.0 eth0: Intel(R) > > PRO/1000 > > > Network Connection > > > ... > > > Jan 26 19:10:38 ironman kernel: e1000e :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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov wrote: > В Mon, 27 Jan 2014 04:18:20 + > David Anderson пишет: > > > 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 :00:19.0 eth0: Intel(R) > PRO/1000 > > Network Connection > > ... > > Jan 26 19:10:38 ironman kernel: e1000e :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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
В Mon, 27 Jan 2014 04:18:20 + David Anderson пишет: > 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 :00:19.0 eth0: Intel(R) PRO/1000 > Network Connection > ... > Jan 26 19:10:38 ironman kernel: e1000e :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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
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 :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :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? Regardless, should udev be capable of handling this gracefully? 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
