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/msg00003.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
Reply to: