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
