Hey, I came across this weird issue with fresh server install of Debian 12.
tl;dr interface names can change after reboot. No hardware changes, nothing. Just after reboot.
I’ve installed debian 12 on ProLiant DL580 Gen9, as you can see every interface has a proper “persistent” altname, but it’s not used. For example, ens8f1 can become eth3 after reboot and then come back to ens back again. My /etc/network/interfaces fails to load when that happens.
Can I force the system to switch to “altnames”?
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens8f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:10:18:ae:a8:c0 brd ff:ff:ff:ff:ff:ff
altname enp69s0f0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:10:18:ae:a8:c2 brd ff:ff:ff:ff:ff:ff
altname enp69s0f1
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:10:18:ae:a8:c4 brd ff:ff:ff:ff:ff:ff
altname enp70s0f0
5: ens8f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:10:18:ae:a8:c6 brd ff:ff:ff:ff:ff:ff
altname enp70s0f1
inet 172.24.44.241/24 scope global ens8f1
valid_lft forever preferred_lft forever
inet6 fe80::210:18ff:feae:a8c6/64 scope link
valid_lft forever preferred_lft forever
6: eno49: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 48:0f:cf:f5:e5:00 brd ff:ff:ff:ff:ff:ff
altname enp3s0
7: eno49d1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 48:0f:cf:f5:e5:01 brd ff:ff:ff:ff:ff:ff
altname enp3s0d1
8: ens9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 50:65:f3:8a:fe:b0 brd ff:ff:ff:ff:ff:ff
altname enp4s0
9: ens9d1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 50:65:f3:8a:fe:b1 brd ff:ff:ff:ff:ff:ff
altname enp4s0d1
Well, the thing is that first of all, you can see I have a mix and match of old and new naming, and if possible, instead of reverting to eth1,2,3, i’d much rather have the system use enp3s0 consistently.
I’m curious if someone has also come across this and dealt with it without creating custom udev rules, because this seems to be mostly debian related.
#!/bin/bash
ifconfig enp5s0 down;ip link set dev enp5s0 name eth1
ifconfig enp8s0 down;ip link set dev enp8s0 name eth0
service networking restart
add to cron to start at reboot or write a systemd service (better idea) for it.
released on a dwtfyw (do what the f*** you want) license . no warranties, no guarantees , no money back if it hoses your system. so yes back up before doing this.
Nice script, but please do not use the old and outdated ifconfig, this is better:
#!/bin/bash
INTERFACES=( "enp1s0" "enp2s0" )
ALIASES=( "eth0" "eth1" )
for i in ${!INTERFACES[*]}; do
ip link dev ${INTERFACES[$i]} set down
ip link dev ${INTERFACES[$i]} set name ${ALIASES[$i]}
done
service networking restart
Now all you need to do is change the two arrays at the start, YW
What i’m looking for is a system setting that causes it to behave in this strange manner. I’m pretty sure (but NOT 100%) that on rocky/centos the interface naming was consistent.
This bug is ancient, I recall something with udev rules. Proxmox 6 had this bug ages ago on HPE dl380 gen8. Never fixed it, but since rebooting was so infrequent, didn’t really care much. It got fixed with proxmox 7 upgrade.
The bug in my case was interfaces getting named to “rename6,” “rename7” and alike (instead of anything sane like “ethX” or “enpXsY” or whatever).
This also affected some version of SLES, I think it was old though, something like SLES 12 (saw it on some customer’s servers), but the behavior was more like yours than like what I’ve had to deal with.
I don’t have a fix other than identifying the interfaces and renaming them with ‘ip’.
The problem is, if the interfaces get random names (like eth7 or rename8), despite only being 6 interfaces on the server, (which happened to me), then the script will still fail. Not sure if interfaces get consistently named to new and old styles with the same names each time, or if they get a new name on each reboot, or every other reboot. Sometimes eth1 was rename3 and sometimes it was rename4 (I never had rename1 and 2 for some reason, which explains why it went all the way up to rename8, but I digress).
I don’t have any solution, like mentioned. Changing udev rules is probably the only real solution.
I got annoyed, because whenever I removed/exchanged a PCIe card my network interface names changed - this broke my network bridges I setup earlier. This way interface names remain fixed. I strongly recommend to stick to interface names which aren’t reserved by the system like lo, eth0 etc.
I think i see here something that I would be comfortable with, mainly the step 4 Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da) I just need to figure out how to turn it on, since that article states it’s disabled by default.
See the post by @risk above, below mine. I think they nailed it.
The short gist of it is to create an alias for the MAC address by creating two files for the interface, one for the link and one for the rules. That is, create the two files /etc/systemd/network/myAliasName.link and /etc/systemd/network/myAliasName.network - in the example cited above, “myAliasName” was called “wan”. Link file names it, network file specifies all the rules (IPv6, IPv4, DHclient, static IP et cetera)
Trying to get a interface name that will stay put on a bench machine, where I’m likely to add hardware. Had tried setting my own name based on matching MAC address: partly worked: I also have VLANs, and run KVM-QEMU hypervisor with guests on various VLANs. Problem is the VLANS have the same MAC and systemd was trying to rename them to same as physical, which of course failed.
Fixed:
add to Dratatto’s answer additional match on Type=ether. The vlans will by type=vlan so prevents them from matching.
