Proposed F19 Feature: systemd/udev Predictable Network Interface Names

Kay Sievers kay at vrfy.org
Thu Jan 24 03:15:13 UTC 2013


On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski <orion at cora.nwra.com> wrote:
> On 01/23/2013 05:29 PM, Kay Sievers wrote:
>>
>> What udev does here is the only sensible thing to do, if there is no
>> authoritative information from the firmware about that, we don't make
>> assumptions, we use the reasonable stable PCI geography. Guessing
>> around which might the "human" slot number should be avoided for many
>> reasons.
>
>
> FWIW - I did a BIOS upgrade and reconfig on one of our machines and the PCI
> slot numbers as shown in lscpi changed for our SATA controllers. Caused a
> bit of panic when we ended up pulling the wrong drive.

Yeah, we see that from time to time, sometimes even just by
re-configuring things, not only on firmware upgrades.

> Perhaps the BIOS
> assisted names would have been more stable in this case for the ethernet
> names, I don't know.

It should, yes. Firmware provided index/slot/interface numbers seem to
work pretty well so far.

> I'm not trying to disparage this work, it seems reasonable (although I've
> been bitten by a lot of crappy software assuming network devices are named
> eth#, but it's able to be turned off, so meh).

Right, it's a pain. Some software likes the eth* names to find the MAC
address to use that as a machine-id. But all that already happens with
biosdevname, and the reported issues seems pretty rare these days.

> Just passing along a data
> point.  YMMV and all that.

Thank you.

Kay


More information about the devel mailing list