Hi, On 2025-06-21 03:13, Justin B Rye wrote: > 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.
Right. We encountered this problem upgrading a test server from Bookworm to Trixie, see #1105204. My understanding is that in at least some circumstances the network interface gets renamed because of new metadata made available by the new kernel *and* naming scheme changes introduced by the new systemd version that make use of such information. Because of this, one cannot just upgrade to Trixie and run the following before reboot to find out what the name of the network interface will be *after* reboot, because the new kernel isn't running yet. $ udevadm test-builtin net_id /sys/class/net/$IFACE > 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". That sounds good, although I wouldn't single out qemu and specific network interface drivers as the problem affects a variety of systems and it's probably better to be generic and err on the side of caution. > 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. Standard Debian installations performed using debian-installer have networking configured via /etc/network/interfaces. Moving the default setup to the systemd approach of using custom .link files may be good practice in general but is perhaps not what we want to recommend as a workaround for this problem in the Release Notes? In any case, I see 3 different recommendations we could give, in no particular order. 1) Pass net.naming_scheme=v252 to the kernel to ensure the Bookworm naming scheme is used 2) For systems relying on network connectivity and using a single network interface such as VPSs, cloud instances, and similar, disable Predictable Interface Names with net.ifnames=0 and use eth0 (more predictable) in /etc/network/interfaces instead 3) Set a custom interface name using a systemd .link file
