-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't disable predictable network interface names #207
Comments
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. |
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:
|
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? |
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. |
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.
|
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 |
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. |
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 Here is the relevant part of the code for setting predictable network names: |
Exactly what I struggled about. I posted the fix (reversible behaviour) here: #207 (comment) |
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.
added the /g option to ensure all occurrences are removed just to be safe or pedantic:-) |
ok - after fiddling around a bit more - working on a rpi4 with a fresh bookworm 64bit lite.
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. |
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:
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? |
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 The I rebooted with I didn't save the original initramfs to inspect. My best guess is the good ol I also took a unorthodox upgrade path manually migrating from |
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
raspi-config/raspi-config
Lines 2150 to 2158 in 0fc1f95
The text was updated successfully, but these errors were encountered: