Bug#1050833: release-notes: Bookworm renames network interfaces
Hi Justin,
thanks for the elaborate followup.
Just a few quick answers:
> Did the installer give you a 70-persistent-net.rules file? It seems a
> bit of a pointless mechanism for hardware like yours...
I did not check on the test system (on which I installed bullseye and upgraded
to bookworm) if there was one, I assume though that there was none, otherwise
I would not expect the network device renaming after the upgrade.
On my production machine (initial installation is much older than bullseye), I
found one, which still seems to work (since the system still has an wlan0
interface). Judging after etckeeper, I commented the eth line during the
upgrade from stretch to buster (I do not recall why though):
rd@home:~$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# Unknown net device (/devices/soc0/soc/210.aips-bus/2188000.ethernet/net/
eth0) (fec)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}
=="d0:63:b4:00:2b:ac", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth0"
# Unknown net device (/devices/soc0/soc/210.aips-bus/219.usdhc/
mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0) (brcmfmac)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}
=="b8:5a:f7:82:aa:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*",
NAME="wlan0"
rd@home:~$
What I don't understand:
Before the upgrade from bullseye to bookworm, this machine still had the eth
network interface names, even though the line in /etc/udev/rules.d/70-
persistent-net.rules was already commented out.
> >> Sure, *if* the change was in bookworm. But if people didn't read
> >> the stretch and buster release notes, why would we expect a warning in
> >> the bookworm release notes to do any good?
> >
> > I am also somewhat concerned that users don't read the release notes
> > carefully, break their systems. This information should probably be in a
> > more prominent place and clearly visible during the upgrade. I liked the
> > previous solution better that systems by default continue to use the old
> > naming scheme.
> Well, systems still do continue to use the old naming scheme, unless
> you change your apt sources to point at a new release! And it's
> really much easier to change your configuration once to use the new
> names than to change your grub configuration and carry that around
> forever - or until linux-8.0.0 stops supporting that commandline
> parameter, long after you've forgotten you were using it...
I fully agree. But it would be much better if I would learn before the upgrade
about this change and not get as a surprise a headless system which does not
connect to the network anymore after the upgrade.
> Personally I have a .link file in /etc/systemd/network to make sure
> my machines use consistent names for their interfaces regardless of
> their hardware differences, and if you're administrating machines with
> different architectures that might well be what you'd want, too.
Many thanks for sharing this. For reference, I found an example here:
https://wiki.archlinux.org/title/Systemd-networkd#Renaming_an_interface
Thanks again
Rainer
--
Rainer Dorsch
http://bokomoko.de/
Bug#1050833: release-notes: Bookworm renames network interfaces
Rainer Dorsch wrote: >> Are you saying that armhf machines still used one of the old interface >> naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on >> bullseye, and hadn't yet switched over to "predictable" names? > > That is at least what I observed. I don't have insights, why armhf behaves > differently here. Maybe I should go and ask on the armhf mailinglist - oh, except that you've done that for me, thanks! Let's see if anyone follows up. The name "end0" doesn't match anything that the systemd documentation told us the Predictable Names scheme would generate, so I should also try to find out what's going on there... ah, looks as if it's "d for devicetree": https://github.com/systemd/systemd/commit/65c2ad985a8debdf6d7d11fee5b466f280260f4b#diff-74ecd06b7b5ba73ee97dbca326e44e3dddf6e8841bda2e073b06bdc4d8bd158dR682 You'd think they'd have learned by now that when you change this stuff, you need to mention to sysadmins that you're planning to lock them out of their servers next time they do a remote reboot, but no, it isn't mentioned anywhere in https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html Except, wait, if this was caused by a change in systemd v254, doesn't that make it a bookworm-to-trixie tripwire? Perhaps I'm looking at the wrong arbitrary unsignposted fluctuation in naming policy... >> For >> the architectures I know anything about, interface names like eth0 >> disappeared quite a while ago, with particular warnings in the stretch >> and buster release notes: >> >> https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en. >> html#new-interface-names >> >> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en >> .html#migrate-interface-names > > If I understand the sentence > > "This change does not apply to upgrades of jessie systems; the naming will > continue to be enforced by /etc/udev/rules.d/70-persistent-net.rules." > > correctly, this means old systems stay with the old naming scheme by default, > newly installed systems use the new naming scheme. It was true for jessie-to-stretch upgrades, but then buster lost the machinery keeping /etc/udev/rules.d/70-persistent-net.rules updated for changed network hardware, and the support has crumbled further since then - it's not exactly clear how much is left. Upstream insists it isn't supported at all, but then again udev still seems to allow those rules files... > That is an excellent solution, since it does not break existing systems > during > the upgrade. > > But what I observed in the armhf install is exactly the opposite. A running > bullseye system did not work anymore after the upgrade to bookworm due to the > network interface naming change. Since these are often headless systems, you > then rely on a serial interface for debugging. > > As a side note: > I have two amd64 kvm cloud hosted machines at different providers. I upgraded > one of them to bookworm, both use still uses eth0 as interface name. I see > the > they have both > > net.ifnames=0 > > configured as kernel parameter in /etc/default/grub in the variable > GRUB_CMDLINE_LINUX. > > Since I did not actively configure that, I assume that there are quite a few > machines out there with disabled Predictable Network Interface renaming > behavior. I'm told (so it went into the bookworm release notes) that Xen only recently switched from "eth0" to "enX0"; no idea what the situation is like on KVM. >> If the sequence of events has been different on armhf, that might need >> a new entry in the "Complications and corner cases" section of the >> wiki page. The question is, how exactly did you come to be still >> using "eth0" in a bullseye /etc/network/interfaces file? > > I just run the installer for bullseye on a cubox-i/armhf machine. I do not > recall that I did anything special. I could repeat it, but maybe it is better > if somebody else does a test (just in case I missed something, it is likely > that I miss it again, though I don't know what that could be). Did the installer give you a 70-persistent-net.rules file? It seems a bit of a pointless mechanism for hardware like yours... >> Sure, *if* the change was in bookworm. But if people didn't read >> the stretch and buster release notes, why would we expect a warning in >> the bookworm release notes to do any good? > > I am also somewhat concerned that users don't read the release notes > carefully, break their systems. This information should probably be in a more > prominent place and clearly visible during the upgrade. I liked the previous > solution better that systems by default continue to use the old naming scheme. Well, systems still do continue to use the old naming scheme, unless you change your apt sources to point at a new release! And it's really much easier to change your configuration once to use the new names than to change your grub configuration and carry that around forev
Bug#1050833: release-notes: Bookworm renames network interfaces
Hi Justin, many thanks for the quick follow-up. Am Mittwoch, 30. August 2023, 07:46:04 CEST schrieben Sie: > Are you saying that armhf machines still used one of the old interface > naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on > bullseye, and hadn't yet switched over to "predictable" names? That is at least what I observed. I don't have insights, why armhf behaves differently here. > For > the architectures I know anything about, interface names like eth0 > disappeared quite a while ago, with particular warnings in the stretch > and buster release notes: > > https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en. > html#new-interface-names > > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en > .html#migrate-interface-names If I understand the sentence "This change does not apply to upgrades of jessie systems; the naming will continue to be enforced by /etc/udev/rules.d/70-persistent-net.rules." correctly, this means old systems stay with the old naming scheme by default, newly installed systems use the new naming scheme. That is an excellent solution, since it does not break existing systems during the upgrade. But what I observed in the armhf install is exactly the opposite. A running bullseye system did not work anymore after the upgrade to bookworm due to the network interface naming change. Since these are often headless systems, you then rely on a serial interface for debugging. As a side note: I have two amd64 kvm cloud hosted machines at different providers. I upgraded one of them to bookworm, both use still uses eth0 as interface name. I see the they have both net.ifnames=0 configured as kernel parameter in /etc/default/grub in the variable GRUB_CMDLINE_LINUX. Since I did not actively configure that, I assume that there are quite a few machines out there with disabled Predictable Network Interface renaming behavior. > If the sequence of events has been different on armhf, that might need > a new entry in the "Complications and corner cases" section of the > wiki page. The question is, how exactly did you come to be still > using "eth0" in a bullseye /etc/network/interfaces file? I just run the installer for bullseye on a cubox-i/armhf machine. I do not recall that I did anything special. I could repeat it, but maybe it is better if somebody else does a test (just in case I missed something, it is likely that I miss it again, though I don't know what that could be). > Sure, *if* the change was in bookworm. But if people didn't read > the stretch and buster release notes, why would we expect a warning in > the bookworm release notes to do any good? I am also somewhat concerned that users don't read the release notes carefully, break their systems. This information should probably be in a more prominent place and clearly visible during the upgrade. I liked the previous solution better that systems by default continue to use the old naming scheme. Thanks again Rainer -- Rainer Dorsch http://bokomoko.de/
Bug#1050833: release-notes: Bookworm renames network interfaces
Rainer Dorsch wrote: > I did a test installation with a bullseye installer on a cubox-i > (armhf architecture) and then upgraded to bookworm. After the upgrade > the network was gone. Even booting with the previous kernel > 5.10.0-23-armmp does not bring the network back. > > After some more investigation, I found that the network interfaces got > renamed from eth0 to end0, which required manual modifications in my > /etc/network/interfaces file. Fortunately, I did this test before > upgrading production systems. Are you saying that armhf machines still used one of the old interface naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on bullseye, and hadn't yet switched over to "predictable" names? For the architectures I know anything about, interface names like eth0 disappeared quite a while ago, with particular warnings in the stretch and buster release notes: https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#new-interface-names https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names If the sequence of events has been different on armhf, that might need a new entry in the "Complications and corner cases" section of the wiki page. The question is, how exactly did you come to be still using "eth0" in a bullseye /etc/network/interfaces file? > On one of my production systems the renaming also broke the packages > shorewall, dnsmasq, and some custom scripts. > > On the debian-arm mailing list the topic was discussed in this threat: > > https://lists.debian.org/debian-arm/2023/08/msg3.html > > Suggestions in the thread: > - Try adding "net.ifnames=0" to kernel's commandline. > - Adding a statement to the release notes like "did you know your > interface name will change after the reboot thus possibly breaking > your network configuration?" > - Add a warning to debconf which the user has to confirm during the > upgrade > - ifupdown can do interface name wildcards and mac matching. The > other solutions for this problem (systemd-networkd, NetworkManager, > ifupdown-ng, probably ifupdown2) -> but this solves only part of the > problem, e.g. neither dnsmasq and shorewall are not covered nor custom > scripts If you're worried about "predictable" names making things unpredictable, the canonical solution is to set up a .link file specifying how you want the crucial interface(s) to be named. See the section "CUSTOM SCHEMES USING .LINK FILES". > Adding a prominent warning to the release notes should a low hanging > fruit and would have helped me. Likely I would not have run in the > issue in the first place or at least the debugging would have been > easier :-) Sure, *if* the change was in bookworm. But if people didn't read the stretch and buster release notes, why would we expect a warning in the bookworm release notes to do any good? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1050833: release-notes: Bookworm renames network interfaces
Package: release-notes Severity: normal Dear Maintainer, I did a test installation with a bullseye installer on a cubox-i (armhf architecture) and then upgraded to bookworm. After the upgrade the network was gone. Even booting with the previous kernel 5.10.0-23-armmp does not bring the network back. After some more investigation, I found that the network interfaces got renamed from eth0 to end0, which required manual modifications in my /etc/network/interfaces file. Fortunately, I did this test before upgrading production systems. On one of my production systems the renaming also broke the packages shorewall, dnsmasq, and some custom scripts. On the debian-arm mailing list the topic was discussed in this threat: https://lists.debian.org/debian-arm/2023/08/msg3.html Suggestions in the thread: - Try adding "net.ifnames=0" to kernel's commandline. - Adding a statement to the release notes like "did you know your interface name will change after the reboot thus possibly breaking your network configuration?" - Add a warning to debconf which the user has to confirm during the upgrade - ifupdown can do interface name wildcards and mac matching. The other solutions for this problem (systemd-networkd, NetworkManager, ifupdown-ng, probably ifupdown2) -> but this solves only part of the problem, e.g. neither dnsmasq and shorewall are not covered nor custom scripts Adding a prominent warning to the release notes should a low hanging fruit and would have helped me. Likely I would not have run in the issue in the first place or at least the debugging would have been easier :-)
