this post was submitted on 10 May 2026

9 points (100.0% liked)

Debian operating system

3875 readers

1 users here now

Debian is a free operating system (OS) for your computer. An operating system is the set of basic programs and utilities that make your computer run. Debian provides more than a pure OS: it comes with over 59000 packages, precompiled software bundled up in a nice format for easy installation on your machine.

founded 6 years ago

MODERATORS

cydork@lemmy.ml

Still fighting with network names in newer Debian releases (mander.xyz)

submitted 3 days ago by Shdwdrgn@mander.xyz to c/debian@lemmy.ml

13 comments fedilink hide all child comments

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.

top 13 comments

sorted by: hot top controversial new old

[–] moonpiedumplings@programming.dev 1 points 2 days ago (1 children)

Here is what I did, although it may not be what you want.

I used cockpit, and NetworkManager to convert both of my interfaces into a single bond, named bond0. Then I convert that bond interface into a bridge interface that also has an ip address and network connection, and can be used as a normal ethernet interface (calling that one eth0). Then I create a veth interface, attatch one end of it to eth0, and the other end becomes a usable interface called eth1.

I do this convoluted setup, because openstack (proxmox like software) wants two network interfaces, BUT I only have 100 mb/s per link. By bonding them it lets anything on the host or any vm use a total of 200 mb/s.

As a simpler version of this, if you only have a single interface, you could convert it into a bridge and call that eth0.

Of course, this probably does not work if you want consistent interfaces because you are autoconfiguring interfaces or something like that. But for same named interfaces that you are feeding into software like openstack,docker,proxmox/etc it works.

[–] Shdwdrgn@mander.xyz 1 points 2 days ago

In my case, the server has four gigabit network ports. And I do in fact create bridges on them because nearly all of my services run on VMs (I run two identical servers for redundancy of the services, and run load balancing off the firewall). Honestly this isn't really a matter of the exact interface names, but rather why the ability to give them the desired names was intentionally broken starting with Debian 11. And as a sidebar, also trying to understand why the newer system refuses to assign the predictable names, because if it did that then I would be free to simply rename them as ethX with the systemd link files the way udev used to. On the firewall with eight network ports, yeah having to give all new names to everything was a really big deal tied to a lot of different software packages. On these servers, though, there's not much running except kvm and I only had to readdress the bridges to the new interface names and everything worked.

It's just the principle of it that REALLY bugs me...

[–] digdilem@lemmy.ml 1 points 3 days ago (1 children)

Quick check: Try "cat /proc/cmdline" and confirm that the net.ifnames variable is missing after a reboot, to ensure it's not persisting somehow after you removed it.

[–] Shdwdrgn@mander.xyz 1 points 3 days ago (1 children)

BOOT_IMAGE=/boot/vmlinuz-5.10.0-42-amd64 root=UUID=1a99d775-a924-43e4-9ffa-d170827cc8df ro consoleblank=600 quiet

[–] digdilem@lemmy.ml 1 points 3 days ago (1 children)

Fair enough - not that then.

[–] Shdwdrgn@mander.xyz 2 points 3 days ago

Thanks for trying though, it could still easily be something I missed. And there's the chance that somehow the BIOS is blocking systemd from setting the names but that really seems like an overreach of what the BIOS should be doing.

[–] poinck@lemmy.world 1 points 3 days ago (1 children)

Do you need those predictable names because you are referencing them in scripts for something? And what is that something?

[–] Shdwdrgn@mander.xyz 1 points 3 days ago

In this case, it's just easier to remember eth0 for each of the servers, rather than having to look up the name each time I work on a different machine. There's no software reason for it, it's just for my own convenience. I can accept naming the interface to dmz0, it just really bugs me that debian no longer gives me an option to name things the way I want when I could easily make those changes on older versions.

[–] mhzawadi@lemmy.horwood.cloud -1 points 3 days ago (1 children)

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

[–] Shdwdrgn@mander.xyz 2 points 3 days ago (2 children)

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.

[–] eldavi@lemmy.ml 1 points 3 days ago (1 children)

how about switching to another init system or debian based distro that fits your needs?

[–] Shdwdrgn@mander.xyz 1 points 2 days ago

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...

[–] caseyweederman@lemmy.ca 1 points 3 days ago

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.