The "stable" interface naming scheme is a scam. And I have proof. Test upgraded a VM today, from bookworm to trixie. And guess what. Everything worked, except after reboot the network interface was unconfigured? Guess what. The name changed...
Scam is probably the wrong word, and it's choice might be a bit feeling fueled, but it's really not true that this only depends on the HW.
systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0].
Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the same, no software update, not change in how the QEMU cli gets generated, really nothing changed from the outside virtual HW POV, interface name still changes.
The underlying problem was a real one, the solution seems like a bit of a sunken cost fallacy, and it added more problem dimensions than there previously exist.
Besides, even if the HW would change, shouldn't a _predicatble_ naming scheme be robust to not care about that as long as the same NIC is still plugged in somewhere?
Disclaimer, as stated elsewhere: I really like systemd, I'm not one that speaks out against it lightly, but the IF naming is not something they got right, but rather made worse for the default case.
Being able to easily pin interface names through .link files is great, but requiring users to do that or have no network after an upgrade, especially for simple one-NIC use cases in a completely controlled environment like a VM is just bonkers.
Ah, ok, I didn't think of systemd version changes. Thanks.
Regarding your rhetorical question about "the same NIC", I think the problem is in determining whether the NIC is the same, and it is not an easy one to solve. I remember that older Suse Linux versions used to pin the interface name to the NIC's MAC address in an udev rule file that got autogenerated when a NIC with a given MAC first appeared on the system, but they stopped doing that.
Yeah, the permanent MAC address (i.e., the one the card actually reports to the system not the one dynamic one it can use) would be the safest bet, as that is the most stable thing there is, and more importantly, it is very relevant for switches and firewalls in enterprise settings, so if it changes it's often likely that network access will be broken any way, so one basically can only win with using the MAC as main identifier IMO, at least compared to the current status quo.
As long as you only got NICs with different permanent MAC addresses installed that does not matter for getting actually long-term stable names.
And for the other case you can still fallback to the other policies, it still will be much more stable by default.
Please note that I don't say that MAC is perfect, but using something that is actually tied to a NIC itself would fare much better by default compared to the NICs position as determined by a bunch of volatile information, and what normally does not matter to me at all, as e.g., I will always use a 100G NIC as ceph private network while the 25G ones as public one, no matter where they are plugged in. That someone configures something by location is the excpection, not the norm.
I don't know if this is still the case but the last time I went without ifnames=0 adding a GPU would cause all the network interfaces to get new names. Junk.
I've had too many incidents to fix / work around since "stable" interface names were introduced. Sorry that you are offended. But the fact of the matter is, most of these issues would not have hit me if we'd just kept the old ethX naming scheme.
I do change ifupdown to systemd-networkd on every server I care about. Matching on MACAddress is a great imprvement. It doesn't help that Debian still insists on keeping ifupdown.
