XPost: linux.debian.doc
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)