I am running Poweredge R620 servers. With Debian 10 I had no trouble, I could reliably set my network names using udev and they came up consistently even when moving from older hardware years ago. Knowing full well that upgrading to Debian 11 would break everything, I have resisted for years, but I finally gave up and started moving forward.
After fighting for the past day with a machine, I think the answer here is going to be that beginning with Debian 11 there is simply no way to reliably name the network interfaces now.
Starting with bullseye, udev is officially dead. There are still some remaining files buried on the system but /etc/udev/rules.d/70-persistent-net.rules no longer has any effect on the network interfaces.
/etc/default/grub -- "net.ifnames=0 biosdevname=0" have been removed and update-grub run
/etc/systemd/network/ -- I created the link files such as 10-eth0.link with the appropriate MAC addresses, but because the ethX names already exist, renaming is not possible:
[Match]
MACAddress=74:86:7a:ed:f6:a3
[Link]
NamePolicy=
Name=eth0
systemctl status systemd-networkd.service -- confirmed that this service is indeed active and running
Very early in dmesg I continue to see this:
[ 2.193760] tg3 0000:01:00.0 eth0: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[ 2.227087] tg3 0000:01:00.1 eth1: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[ 2.247850] tg3 0000:02:00.0 eth2: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[ 2.263753] tg3 0000:02:00.1 eth3: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
The problem here is that the ethX names are being assigned backwards. The physical plugs have other brackets in the way so what I previously used as eth0 and eth1 is now being assigned to eth3 and eth2. And despite all of the above, debian and systemd refuse to ever assign "predictable" names to any of the interfaces (nothing shows up in dmesg). I ran across some info about a "BIOSdevname" setting in the actual BIOS, but can find no such setting in the last available BIOS rev for these servers. Because the system is assigning the ethX names, I am unable to reassign the correct names using the systemd link files.
The only solution I've found to work is to use the link files and assign the interface with names like dmz0, dmz1, etc. What's the deal here and what ever happened to the concept that I should be able to set up my computer the way I want to? The udev utility was 100% reliable for all the machines I've run since it was first introduced, and now we're stuck with a system that simply can't be given alternate information? Yeah I'm frustrated and annoyed.
I don't know if anyone else has run across other possible solutions, I fought with the last box for two weeks trying to name eight interfaces in the proper order and never could find anything that would work.
Yeah systemd is a load of crap, why is the init process messing with network settings?
Can we now get rid of systemd and have init back?
1 job really good, not half ass many jobs
I mean it's kind of cool how systemd multitasks starting up services, so like I can already ssh in before half the other things are running. And it's certainly nice to have a lot more information now about running processes. But when it screws something up, it REALLY screws something up.
how about switching to another init system or debian based distro that fits your needs?
I've considered Devuan, but haven't taken the plunge into it. The problem here is, at least to my understanding, that predictable naming is supposed to be a core part of the newer linux kernel, and since I can find no sign in dmesg that those names are even being attempted, it worries me that something very basic has been broken that I can't go back to. I Just don't know enough about it to risk taking down a live server to try rebuilding in a different distro without at least first understanding why exactly this particular thing is broken in Debian. "The devil you know" and all that...
My main struggle with it is how many individual files need to be created manually. Timer, service, script for recurring stuff.
I know there have been a few different systemd GUI projects but none of them seem active these days.