Can't disable predictable network interface names

[mschlenstedt]

Same as closed issue #166 I cannot reopen it, so created this new one.

I have the same problem here - upgrading from buster to bullseye enabled predictable network interface names on my system (tested on Pi3 and Pi1).

Adding net.ifnames=0 to /boot/cmdline.txt solved the problem.

I think you missed adding this option (it is removed when $RET=0, but not added when $RET=1

https://github.com/RPi-Distro/raspi-config/blob/0fc1f9552fc99332d57e3b6df20c64576466913a/raspi-config#L2150-L2158

[XECDesign]

Works okay on this end. Could you provide a bit more information? I suspect you might be expecting the names on the internal interfaces that aren't connected via USB to change, which isn't the case.

[mschlenstedt]

Yes, that's right. I am talking about the internal devices, like eth0. I haven't tried USB devices. From my point of view this setting should be valid for all devices, not only usb devices.

Until Debian Buster I had traditional naming of the devices, like eth0, wlan0 etc. After doing the upgrade to Bullseye, the new predictable device naming was active. E. g. eth0 changed this way:

Changing the Network naming in Raspi Config didn't change anything - from my point of view because there's a sed command missing for adding "net.ifnames=0" to /boot/cmdline.txt. You remove this option when disabling, but do not add it when enabling. Changing the code this way works fine here for me:

if [ $RET -eq 0 ]; then 
   sed -i $CMDLINE -e "s/net.ifnames=0 *//" 
   rm -f /etc/systemd/network/99-default.link 
   rm -f /etc/systemd/network/73-usb-net-by-mac.link 
   STATUS=enabled 
 elif [ $RET -eq 1 ]; then 
   sed -i $CMDLINE -e "s/rootwait/net.ifnames=0 rootwait/" 
   ln -sf /dev/null /etc/systemd/network/99-default.link 
   ln -sf /dev/null /etc/systemd/network/73-usb-net-by-mac.link 
   STATUS=disabled

[XECDesign]

The internal interface names are predictably eth0 and wlan0 already. I don't know why, but the way Debian has it setup is that only USB (and possibly PCI?) devices use the other naming scheme. Changing the behavior now would only cause things to break for people who rely on the existing behaviour.

Maybe we could change it for Bookworm if there's a compelling reason to diverge from Debian's behaviour. So that I understand it better, what is the point if you don't have multiple interfaces?

[mschlenstedt]

Well, my problem was that I had an existing /etc/network/interfaces which referenced to eth0 and wlan0. After upgrade to Bullseye network hasn't come up, because eth0 and wlan0 disappearred and I had instead an enxb827ebc1f771 device. So my interfaces file was invalid.

So I wanted to change back to eth0 naming scheme, but since raspi-config do not change back the parameter at /boot/cmdline.txt, nothing happend at all. So I had to add the parameter by myself.

I still think raspi-config did not configure this correctly since it deletes the parameter at $RET=0 but do not add it back again in $RET=1.

[XECDesign]

Oh, that sounds like the opposite of what I thought. I thought you wanted enxb827ebc1f771, but were ending up with eth0.

What you're describing isn't the behaviour I'm seeing, so I'll need to dig into why that might be happening.

net.ifnames=0 shouldn't be needed. It should be handled by those symlinks. It's only removed when enabling predictable interface names in case it was added by the user.

[mschlenstedt]

Ok, maybe I haven't described that very well. ... sorry.

So the SymLinks were installed but seems to have no effect. Maybe also interesting: I only had the problems with eth0, while wlan0 wasn't renamed and was still wlan0 after upgrade. So maybe only a bug with Ethernet devices.

Furthermore keep in mind that I upgraded from buster. Maybe this only

[XECDesign]

Oh you may have an older pi which has Ethernet hooked up through usb. But then I don’t know why disabling predictable interface names wouldn’t get you back to eth0. Will take a look after the holiday break.

[helarsen]

raspi-config will irreversibly break the ethernet port In Bookworm (rpi5) if setting predictable network names.

When using raspi-config to set predictable network interface names then the string net.names=0 is removed from /boot/firmware/cmdline.txt if /boot/firmware/cmdline.txt does not hold the string then eth0 is not configured and the built-in ethernet port is not working. In addition - using raspi-config to revert the setting (to non-predictable) does not work because the string net.names=0 is not re-inserted. I.e. the change to network interface names made by raspi-config is not reversible and unless you manually add the string the ethernet interface is broken.

Here is the relevant part of the code for setting predictable network names: sed -i $CMDLINE -e "s/net.ifnames=0 *//"

[mschlenstedt]

When using raspi-config to set predictable network interface names then the string net.names=0 is removed from /boot/firmware/cmdline.txt [...] In addition - using raspi-config to revert the setting (to non-predictable) does not work because the string net.names=0 is not re-inserted. I.e. the change to network interface names made by raspi-config is not reversible and unless you manually add the string the ethernet interface is broken.

Exactly what I struggled about. I posted the fix (reversible behaviour) here: https://github.com/RPi-Distro/raspi-config/issues/207#issuecomment-1361242484

[helarsen]

To make the operation reversible, the string "net.names=0" should be removed before addition - in case it was there already or you end up with two of the same. Nothing prevents the user from calling the disable first and multiple times in fact adding the string each time. Now - maybe the kernel does not care - who knows.

if [ $RET -eq 0 ]; then 
   sed -i $CMDLINE -e "s/net.ifnames=0 *//g" 
   rm -f /etc/systemd/network/99-default.link 
   rm -f /etc/systemd/network/73-usb-net-by-mac.link 
   STATUS=enabled 
 elif [ $RET -eq 1 ]; then 
   sed -i $CMDLINE -e "s/net.ifnames=0 *//g" 
   sed -i $CMDLINE -e "s/rootwait/net.ifnames=0 rootwait/" 
   ln -sf /dev/null /etc/systemd/network/99-default.link 
   ln -sf /dev/null /etc/systemd/network/73-usb-net-by-mac.link 
   STATUS=disabled

added the /g option to ensure all occurrences are removed just to be safe or pedantic:-)

[helarsen]

ok - after fiddling around a bit more - working on a rpi4 with a fresh bookworm 64bit lite.

1. From the first boot, onboard ethernet is eth0.
2. sudo raspi-config and set predictable network
3. reboot
4. the ethernet port does some times not connect at first boot and sometimes it does!
5. Once it has been connected - it works fine after that for subsequent boots.
6. It always enumerates as end0

So after these findings - it seems that the "net.names=0" strings presence in cmdline.txt has not anything to say in this. In any case, "net.names=0" is not present in a fresh installation and raspi-config is never affecting this fact. So why it some times fails connection I have no good answer.

[XECDesign]

This issue is quite old and references releases and procedures which aren't supported.

For anyone who is having trouble with predictable interface on bookworm, can you please provide steps to reliably reproduce the problem? I've just tried the following on a clean PiOS Bookworm arm64 desktop install on a pi400 and everything worked as expected:

1) Update all packages to the latest version 2) Check that /sys/class/net shows eth0, eth1 and wlan0. eth0 and wlan0 are internal devices, so I'd only expect eth1 (a usb ethernet adapter) to change. 3) Enable predictable interface names through raspi-config and reboot 4) Check /sys/class/net and see that eth1 has been replaced with enx, as expected. 5) Check that both eth0 and enx work 6) Disable predictable interface names and reboot 7) See the same behaviour as in step 2.

I repeated the steps above on a pi5 and saw that eth0 does indeed change to end0. I rebooted 5 times and it connected each time.

What do I need to do, starting from a clean PiOS bookworm install to see the problem?

Is there anything interesting in journalctl or dmesg when it's not connecting in your case?

[jc2a]

Upgrading from bullseye to bookworm on 3 different 1B Rev2 boards, 1 of them did not want to disable predictable interface names after upgrading. The other two had it disabled before upgrading.

Both 73-usb-net-by-mac.link and 99-default.link were masked in systemd-networkd. I enabled debug logging for networkd and from the first mention of the built-in interface it had the enx name. No indication that networkd renamed the link.

The renamed eth0 to enx message was emitted by the kernel after /init was run in the initramfs but before systemd on the rootfs was executed.

I rebooted with net.ifnames=0 on the kernel cmdline and sure enough the interface was then named eth0. Based on the timing I regenerated the initramfs with update-initramfs -k all -u. Removed net.ifnames=0 from the kernel cmdline and rebooted again. The interface is now eth0 on all subsequent reboots.

I didn't save the original initramfs to inspect. My best guess is the good ol 70-persistent-net.rules from bullseye managed to sneak in with the other udev rules. I suspect simply regenerating the initramfs without setting net.ifnames=0 would have cleared this condition on my system. I don't have any other systems to upgrade or I would verify this.

I also took a unorthodox upgrade path manually migrating from raspberrypi-bootloader raspberrypi-kernel without an initramfs to raspi-firmware linux-image-rpi-v6 with an initramfs on all 3 of these systems, which may have introduced some weirdness as well.