Bug#1092176: release-notes: systemd v257 has new rules for network interface names
Richard Lewis wrote:
> On Mon, 6 Jan 2025 13:38:49 +0000 Justin B Rye
> <justin.byam.rye@gmail.com> wrote:
>
>> we probably ought to stop thinking of it as an item to go
>> under "Possible issues during upgrade" and start advertising it under
>> "Preparing for the upgrade" as a chronic bug that sysadmins always
>> need to beware of any time they upgrade systemd. The only safe
>> approach is to set up an /etc/systemd/network/*.link file to replace
>> the "predictable names" with predictable names.
>
> Maybe a slightly less extreme version of this would be: document it as
> a regular change (because i think it doesnt happen often, and eg
> standard desktops probably dont need to care if the name changes),
> But rather than focus on the details of the change (which is quite
> hard to understand), just say it has changed and tell people to
> consider using .link files to fix it?
I'm still struggling with the question of where to put it.
"4.1.x Ensure a robust network connection"?
a "general preparedness for remote servers" sort of issue, though
it's one that's guaranteed to have varying details every time.
"4.5.x Possible issues with network interface names"?
Mind you I don't want to have to give a recipe for fixing it (step
one: buy plane tickets to the data centre...").
"5.x NIC name stability issues"?
this has the reverse problem from the first: it isn't really a
trixie-specific issue, it's an issue with "predictable names" for
critical network connections.
>> Mind you, given that there's a mechanism for checking what your
>> network interfaces will be called after the next reboot, why doesn't
>> systemd run that in postinst and emit big warnings if they've changed?
>
> Whereas this one would be really nice as a "run this before first
> reboot" thing in 5.2?
> (i'd actually quite like to run this regularly myself, and wasnt aware of it)
This was written back in January, before #1107187, which can be
triggered by a backport kernel on bookworm with no change in systemd,
so it wouldn't be caught by asking "udevadm test-builtin". In fact
the only way I can see of catching it is to see if anybody else has
reported the bug. (Or of course you might maintain an entire
duplicate testbed machine to do trial upgrades on... or the simpler
alternative, an assistant sysadmin who can take the blame.)
We might want to do it as an item in the "Preparing for the upgrade"
section saying just something like "if you're upgrading a remote
machine, beware of interface name changes triggered by a new systemd
naming policy, new kernel modules, or new motherboard firmware - see
https://wiki.debian.org/NetworkInterfaceNames#trixie for reported
issues with qemu and the i40e driver".
I'm not sure how strongly we should be recommending the custom .link
approach as a solution. On the one hand it seems to me that it ought
to be standard operating procedure at least for servers, but on the
other hand it would be really annoying to have to set up just for the
duration of a dist-upgrade since it necessarily involves changing the
interface name at least once. Some users might in fact be better off
with alternative safetynets such as the bridging approach recently
added to that page. Of course, that option's probably poorly suited
to remote servers.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: