Re: How to avoid systemd/udev unpredictable NIC names
On Tue, Aug 31, 2021 at 01:44:09AM +0200, Steve Keller wrote:
> One interface is on the mainboard (eth0), the other is a PCI card
> (eth1). BTW, PCI really, not PCIe other something like that. It's a
> really old machine.
OK. I recommend making two "dot link" files, one for each card, in
order to assign the names you want them to have.
> Actually, I don't know this. When I wrote unpredictable new naming
> scheme I meant systemd's enp<pci-bus>s<slot> scheme, since it's
> unpredictable for me as long as I don't learn these numbers for my
> mainboard and PCI card config.
>
> Why is systemd-udevd unqualified for this jobs?
Because PCI slot numbers change. They can change when you add a device,
or remove a device (even if they're not network interfaces), or upgrade
your motherboard firmware.
These names are not "predictable" because they're based on the PCI slot
number, which is not stable.
> Well, this is exactly what I dislike with systemd
> & co. I've read lots of docs & man pages, still I don't know the
> exact process of how the interfaces are renamed after the kernel names
> the eth<n>. Does udevd run first, does systemd call udev, does
> systemd do the renaming itself or is it done by "net_setup_link udev
> builtin" as systemd.link(5) states?
I don't pretend to know every permutation. On my system, which is a
desktop PC with a builtin NIC configured with a .link file, I get this:
[ 1.102914] libphy: r8169: probed
[ 1.103400] r8169 0000:02:00.0 eth0: RTL8168gu/8111gu, 18:60:24:77:5c:ec, XID 509, IRQ 127
[ 1.103761] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 1.104945] r8169 0000:02:00.0 lan0: renamed from eth0
In other words, the kernel probes NICs, and starts handing out names
to them based on the order in which the probing completes. The first
one that successfully responds gets called eth0, the second one gets
called eth1, and so on.
Then, because I have a .link file, the matching interface is renamed to
the name I selected (lan0). I chose this name specifically because it
is *not* one of the names the kernel will assign.
Nobody has ever explained to me how this all works, so I expect that
something will explode in the following scenario:
1) A .link file exists which maps one of the NICs to "eth0".
2) System is booted.
3) First interface is probed and named eth0.
4) Second interface is probed and named eth1.
5) The second interface matches the .link file, and is renamed to eth0.
6) Now there are two interfaces named "eth0", and things explode.
I don't know whether this is how it *actually* works, but I don't want
to find out the hard way. So I chose names that make it impossible
for this to happen.
If there are no .link files, and assuming I'm not using net.ifnames=0,
the NICs will be renamed to the "predictable" names (eno0 or enp2s5 or
whatever) instead of the names that I selected.
If I use net.ifnames=0 then there won't be any renaming. The NICs will
keep their probing-order-assigned named (eth0, eth1, and so on).
> NFS with systemd is a nightmare.
I haven't had an issue with it, personally. Make sure your interfaces
are configured in /etc/network/interfaces with "auto" and not with
"allow-hotplug". That solves 80% of the problems I hear about.
The only NFS issues I've had in recent years are related to NFS version
mismatches (NFSv3 vs. NFSv4 and so on). Nothing caused by systemd.
Reply to: