Hi!

We tested a bookworm to trixie update on one of our systems. The host
did not come back online after reboot, and the issue seems to be caused
by the 252 -> 257 systemd update.

The main network interface on the system was named "enp1s0" by systemd
252.36 shipped with bookworm. After upgrading the machine to trixie and
rebooting, the host was unreachable via the network. Logging in via
out-of-bound console it became evident that systemd v257 on trixie chose
a different name for the network interface: "ens1".

After rebooting the machine passing net.naming_scheme=v252 to the kernel
command line, we verified that the interface name went back to "enp1s0".

The important change seems to be that v257 sets ID_NET_NAME_SLOT=ens1,
and *that* is chosen as the interface name to use instead of
ID_NET_NAME_PATH=enp1s0.

Here's the diff of `udevadm test-builtin net_id /sys/class/net/$IFACE`
--- v252.txt	2025-05-12 20:44:42.252702652 +0200
+++ v257.txt	2025-05-12 20:43:50.668953530 +0200
@@ -11,7 +11,7 @@
 Loading kernel module index.
 Loaded 'libkmod.so.2' via dlopen()
 Found container virtualization none.
-Using interface naming scheme 'v252'.
+Using default interface naming scheme 'v257'.
 Parsed configuration file "/usr/lib/systemd/network/99-default.link"
 Parsed configuration file "/usr/lib/systemd/network/80-vm-vt.link"
 Parsed configuration file "/usr/lib/systemd/network/80-container-vz.link"
@@ -20,10 +20,12 @@
 Parsed configuration file "/usr/lib/systemd/network/80-6rd-tunnel.link"
 Parsed configuration file "/usr/lib/systemd/network/73-usb-net-by-mac.link"
 Created link configuration context.
-ID_NET_NAMING_SCHEME=v252
+ID_NET_NAMING_SCHEME=v257
 ID_NET_NAME_MAC=enx001b21e7ca26
 enp1s0: MAC address identifier: hw_addr=00:1b:21:e7:ca:26 → x001b21e7ca26
 ID_OUI_FROM_DATABASE=Intel Corporate
+sd-device: Failed to chase symlinks in "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/enp1s0/of_node".
+enp1s0: Failed to get device of_node, ignoring: No such device
 sd-device: Failed to chase symlinks in "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/of_node".
 0000:01:00.0: Failed to get device of_node: No such device
 sd-device: Failed to chase symlinks in "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/physfn".
@@ -31,10 +33,8 @@
 0000:01:00.0: Could not obtain onboard index: No such file or directory
 ID_NET_NAME_PATH=enp1s0
 enp1s0: PCI path identifier: domain=n/a bus_and_slot=p1s0 func=n/a port=n/a → enp1s0
-sd-device: Failed to chase symlinks in "/sys/class/pci".
-sd-device: Failed to chase symlinks in "/sys/bus/subsystem/devices/pci".
-sd-device: Failed to chase symlinks in "/sys/class/subsystem/pci".
-sd-device: Failed to chase symlinks in "/sys/firmware/subsystem/pci".
+ID_NET_NAME_SLOT=ens1
+enp1s0: PCI slot identifier: domain=n/a slot=1 func=n/a port=n/a → ens1
 enp1s0: Could not find USB parent device: No such file or directory
 enp1s0: Could not get BCMA parent device: No such file or directory
 Unload kernel module index.

Control: forcemerge 1105204 1105223
Control: tags 1105204 wontfix
Control: close 1105204
caused
systemd
and
chose
kernel
"enp1s0".

This is expected due to kernel changes. Names can always change if the
kernel changes its internal behaviour, you have to fix them if you
don't want that to happen. This is documented at:

https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html

Hi Luca,

Does this mean that all interfaces called enpXs0 on Bookworm will be
renamed to ensX when upgrading to Trixie?

A way to address this issue could be, to freeze the naming scheme upon
first installation of the system. Say you install a new bookworm system
with systemd v252, you pin it to net.naming_scheme=v252.

Upgrading the system to trixie which has systemd v257, it would stay
with the previous naming scheme.

The obvious downside would be, that newly installed systems potentially
behave differently then upgraded systems.
Another aspect is, that this net.naming_scheme can (currently) only be
set via a kernel command line parameter and the integration with grub
could be fiddly.

Michael

Hi Michael,

Right, we could either recommend users to do that or to explicitly set
their network interface names to avoid surprises.

It would be great for folks to be able to predict (hehe) *before*
rebooting whether or not their network interface name will change. My
understanding is that there is no easy way to find out though, not
before one is running the new kernel and systemd, because it's only with
the upgrade of both the kernel (which sets new metadata) and systemd
(which uses it) that the renaming happens. Is that correct?