Emanuele Rocca wrote > 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
Urgh, enp1s0 becoming ens1 is a whole new subcategory of breakage; I'll link to that bugreport from the wiki page too. Do we have any idea what it was about that particular piece of hardware that made the kernel decide to start giving it an ID_NET_NAME_SLOT? (I mean, at least the i40e case was a slightly interesting NIC...) And once again they blandly say that the expected consequence of "predictable names" is unpredictable names. >> 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. Yes, that wording is too squeezed; maybe something more 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 [[the wiki page on Network Interface Names]] and in particular its section on [[known issues for trixie]], which include issues with qemu and the i40e driver. I'd try to summarise whatever the trigger was for #1105204, but meanwhile we haven't worked out where in the Release Notes we want to put this yet. >> 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? No, whether you're using a /etc/systemd/network/*.link file to *name* your network interfaces is an independent question from how you're *configuring* them (though I'll admit it does make it seem more natural to use a /etc/systemd/network/*.network file). I should make that explicit on the wiki page. > 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 These solutions *can* work, but they always strike me as dangerously fragile and likely to come back and bite you after you've forgotten about them. Then again apparently iwd users get a variant on (2) automatically, and seem perfectly happy with this - see "Complications" under IWD. > 3) Set a custom interface name using a systemd .link file I do this just so that all my machines can use the same standard network configuration regardless of trivial differences in hardware. Why do they keep making the names longer? How is that ever an improvement for anybody? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
