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
forever - or until linux-8.0.0 stops supporting that commandline
parameter, long after you've forgotten you were using it...
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.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: