Your message dated Mon, 23 Dec 2024 16:18:38 +0000
with message-id
<CAJ3BuoTdFLD0MUucdt=QHDR83ySnDXZev+=i7xx9rtprsdm...@mail.gmail.com>
and subject line Re: Bug#1050833: release-notes: Bookworm renames network
interfaces
has caused the Debian Bug report #1050833,
regarding release-notes: Bookworm renames network interfaces
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1050833: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050833
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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/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
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 :-)
--- End Message ---
--- Begin Message ---
On Wed, 30 Aug 2023 23:05:05 +0200 Rainer Dorsch <m...@bokomoko.de> wrote:
> 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):
Based on the above, this bug is related to changes made in
stretch/buster, and docmented in those release-notes
(i didnt check this, but i remember reading about it)
The only supported approach is to read each release's release-notes
thoroughly, and switch to the supported
schemes asap: we dont continue to document breaking changes in future
major releases.
Please reopen if i misunderstood
> > >> 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
--- End Message ---
