Re: Naming of network devices - how to improve it in buster
On Thu, Jul 13, 2017 at 6:14 AM, Russell Stuart
<russell-debian@stuart.id.au> wrote:
> On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote:
>>
>> Stateless "/etc".
>>
>> Systems with multiple NICs where the order in which they're
>> recognized by the kernel can vary.
>
> I asked for a person.
You raised more than one point. I was replying to "I still don't
understand what use case the current scheme is aimed at."
I don't know of a person who types the weird new names. I rename all
my NICs "enX". But I don't think that many people end up with the
"en48e244f61c1b" that you mentioned (it would anyway be
"enx48e244f61c1b" not "en48e244f61c1b"). I'd expect the more common
variants to be "enoX", "ensX", and "enpXsY".
> I guess I really asking for a use case.
> "Stateless /etc" isn't either.
Why isn't "stateless /etc" a use-case?! Red Hat controls udev
development. It or its customers might want to have such systems.
> I've never seen the kernel vary the order it enumerates a PCI bus.
It's happened to me. It's happened to ex-colleagues. When there isn't
a file under "/etc" to map NIC name to NIC MAC address.
> This isn't an accident. Quoting "According to: "PCI Express System
> Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY
> DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743":
>
> The specification states that the enumeration software must
> perform a depth-first search, so before proceeding to discover
> additional functions/ devices on bus 0, it must proceed to search
> bus 1.
For PCI Express; for all I know, other technologies might enumerate
differently or change the enumeration method with different driver
versions.
and
Per driver. There's no guarantee that the kernel will load the drivers
in the same order at boot. There was even a (specific) note in one of
the RHEL 5 release notes about systems with NICs using both e1000 and
e1000e being enumerated in a different order.
>From https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
:
The classic naming scheme for network interfaces applied by the kernel
is to simply assign names beginning with "eth0", "eth1", ... to all
interfaces as they are probed by the drivers. As the driver probing is
generally not predictable for modern technology this means that as soon
as multiple network interfaces are available the assignment of the names
"eth0", "eth1" and so on is generally not fixed anymore and it might
very well happen that "eth0" on one boot ends up being "eth1" on the
next.
Reply to: