Re: Ethernet trouble
On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:
> Maybe we should ask the OS to actually help, instead of
> "helping" us.
>
> For example, the OS knows when it is being installed. At install
> time, it could enumerate NICs and assign them permanent names
> based on the MAC addresses: eth0, eth1...
>
> At any subsequent boot, the OS could then continue to assign the
> same names. If a device appears to be missing, the name is
> skipped. eth3 doesn't become eth2, eth2 just goes missing for
> that boot. This is immensely useful in discovering when a NIC
> has suffered hardware damage or is otherwise not present.
This is basically how the udev persistent-naming scheme worked.
Support for it was officially discontinued in buster.
The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.
If the NIC failed and was replaced, the replacement NIC would become eth1,
rather than eth0, and this confused some people.
Prior to the udev thing, when the kernel dynamically assigned names
to interfaces in whatever order they happened to pop up during boot,
replacing a single NIC with a different single NIC would have kept
the name "eth0" the whole time. This is what many people were expecting,
and what the udev persistent-naming scheme took away.
Now, this is all historic. Both the pre-udev "whatever you have
gets called whatever I want to call it" scheme, and the udev
persistent-naming scheme, are unsupported. If you choose to use
them, they may work for you, or they may not.
The currently supported approach is systemd.link(5). If you want to
assign a name to an interface, you create a file that sets up the
mapping as you wish it to be made. Usually from the MAC address.
This puts a slightly higher burden of knowledge on the sysadmin, but
I really don't see a better choice. Anything that tries to magically
do the Right Thing is going to fail in at least one common scenario.
Editing a systemd.link file isn't any harder than editing the udev
persistent rules file, and if you replace a NIC and want to keep the
same name, you'll have to edit one of these files anyway.
Reply to: