<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov <span dir="ltr"><<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">В Mon, 27 Jan 2014 04:18:20 +0000<br>
David Anderson <<a href="mailto:dave@natulte.net">dave@natulte.net</a>> пишет:<br>
<div class="im"><br>
> This is a continuation of a discussion I had on #systemd. I have a server<br>
> that has two onboard ethernet chipsets, and a fresh Arch linux install<br>
> (systemd/udevd v208). On this system, consistent interface naming fails,<br>
> and I end up with eno1 and eth1 after bootup.<br>
><br>
> The full boot log is at <a href="http://pastebin.com/raw.php?i=KR1YqHYp" target="_blank">http://pastebin.com/raw.php?i=KR1YqHYp</a> , but the<br>
> apparently relevant part is:<br>
><br>
><br>
> Jan 26 19:10:38 ironman kernel: e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000<br>
> Network Connection<br>
> ...<br>
> Jan 26 19:10:38 ironman kernel: e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000<br>
> Network Connection<br>
> ...<br>
</div>> *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface<br>
> name eth1 to eno1: File exists*<br>
<div class="im">> Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network<br>
> Connection.<br>
</div>> *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0<br>
> to eno1*<br>
<div class="im">><br>
><br>
> From that, it appears that udevd is trying to rename both interfaces to<br>
> eno1.<br>
><br>
> As you can see from the boot log, the two chipsets are on separate PCI<br>
> buses (bus 0, dev 0x19, and bus 2, dev 0).<br>
><br>
> Looking in /sys , neither device has an acpi_index attribute, and both have<br>
> an "index" attribute equal to 1. I'm by far not an expert on this data, but<br>
> index=1 naively sounds right, since they're both the only ethernet device<br>
> on their bus. According to The Source (<br>
> <a href="http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131" target="_blank">http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131</a>),<br>
> lack of acpi_index means that "index" is used instead, and we end up<br>
> with two devices mapping to eno1.<br>
><br>
> Further debugging information: full `dmidecode` output (<br>
> <a href="http://pastebin.com/raw.php?i=MLXkYF2s" target="_blank">http://pastebin.com/raw.php?i=MLXkYF2s</a> ), and some shell spelunking in /sys<br>
> ( <a href="http://pastebin.com/raw.php?i=TbSvDMSB" target="_blank">http://pastebin.com/raw.php?i=TbSvDMSB</a> ).<br>
><br>
><br>
> At this point, I need more expert help. Is this a udev bug where it<br>
> produces incorrect output in the presence of multiple PCI buses? Is it a<br>
> firmware bug where my motherboard provides incorrect data to udev?<br>
<br>
</div>Looks like it. According to specs<br>
<br>
--><--<br>
Device Type Instance is a unique value (within a given onboard device type)<br>
--><--<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You have two devices of type Ethernet with the same Instance values.<br>
<div class="im"><br>
> Regardless, should udev be capable of handling this gracefully?<br>
<br>
</div>You can always override udev names with your own. What do you suggest<br>
to do automatically? There is no way to find out which interface is<br>
really the first and which is the second.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks!</div><div>- Dave</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> Should I<br>
> report a bug? Do you need more information from my system?<br>
><br>
> Thoughts on temporary workarounds so that I can continue configuring my<br>
> system with consistent interfaces also welcome, but my major concern is<br>
> whether udev is doing the right thing, and how to make it do the right<br>
> thing if not.<br>
><br>
> Cheers,<br>
> - Dave<br>
<br>
</div></div></blockquote></div><br></div></div>