Richard Lewis wrote: > On Mon, 6 Jan 2025 13:38:49 +0000 Justin B Rye > <[email protected]> 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
