<div dir="ltr">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.<div>

<br></div><div>The full boot log is at <a href="http://pastebin.com/raw.php?i=KR1YqHYp">http://pastebin.com/raw.php?i=KR1YqHYp</a> , but the apparently relevant part is:</div><div><br></div><div><br></div><div><div>Jan 26 19:10:38 ironman kernel: e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection<br>

</div><div>...</div><div>Jan 26 19:10:38 ironman kernel: e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection<br></div><div>...</div><div><b>Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists</b><br>

</div><div>Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection.</div><div><b>Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1</b></div></div><div><br></div>

<div><br></div><div>From that, it appears that udevd is trying to rename both interfaces to eno1.</div><div><br></div><div>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).</div>

<div><br></div><div>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 ( <a href="http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131">http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131</a> ), lack of acpi_index means that "index" is used instead, and we end up with two devices mapping to eno1.</div>

<div><br></div><div>Further debugging information: full `dmidecode` output ( <a href="http://pastebin.com/raw.php?i=MLXkYF2s">http://pastebin.com/raw.php?i=MLXkYF2s</a> ), and some shell spelunking in /sys ( <a href="http://pastebin.com/raw.php?i=TbSvDMSB">http://pastebin.com/raw.php?i=TbSvDMSB</a> ).</div>

<div><br></div><div><br></div><div>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?</div>

<div><br></div><div>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.</div>

<div><br></div><div>Cheers,</div><div>- Dave</div></div>