#1105223 udev: on-board interface naming for i40e with bpo kernel

Package:
udev
Source:
udev
Description:
/dev/ and hotplug management daemon
Submitter:
andrew bezella
Date:
2025-06-15 13:57:01 UTC
Severity:
normal
Tags:
#1105223#5
Date:
2025-05-13 17:31:42 UTC
From:
To:
Dear Maintainer,

thank you for the time and effort you put into debian.

the systemd predictable network device names change on
bookworm when running the 6.12.22+bpo-amd64 kernel and
its i40e driver vs the default 6.1 series (6.1.0-34-amd64).
this is apparently expected due to driver changes and #1080975
was closed, referencing the Network device naming schemes[1].
however, on our hardware some of the renames seem to violate the
On-board naming policy defined there.

with the 6.1 kernel the on-board network interfaces are named `eno1`
and `eno2` but once booted into the 6.12 kernel they are named `eno1np0`
and `eno2np1`.  the interfaces are Ethernet Connection X722 for
10GBASE-T and use the i40e driver.  these renamed interfaces in 6.12
do not match the policy for the On-board naming schemes which says on-
board devices should end in "o[[:digit:]]+" (paraphrased as it was
confusing w/o italics).

regardless of this bug's outcome, a mention of these i40e driver
changes and resultant interface renames in the "Issues to be aware
of for trixie" section of the release notes might be appropriate.
the renames were unexpected and even after the fact i am having
trouble finding a mention of the i40e driver adding support for the
devlink_port API in the `linux-image-6.12.22+bpo-amd64/changelog.gz`.
and tbh i wouldn't have understood its ramifications (i.e., lack of
network on reboot) even if i had happened to see it pre-upgrade.

regards,

  andy

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

on a freshly-installed bookworm system:
# cat /etc/debian_version
12.10
# uname -vr
6.1.0-34-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25)
# ip l show | grep -F " en" | cut -d: -f2
 eno1
    altname enp26s0f0
 eno2
    altname enp26s0f1
 enp94s0f0
 enp94s0f1
# udevadm info -e | grep -F ID_NET_NAMING_SCHEME= | sort -u
E: ID_NET_NAMING_SCHEME=v252
# udevadm info -e | grep -F ID_NET_NAME_
E: ID_NET_NAME_MAC=enx3cecefd0da34
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp26s0f0
E: ID_NET_NAME_MAC=enx3cecefd0da35
E: ID_NET_NAME_ONBOARD=eno2
E: ID_NET_NAME_PATH=enp26s0f1
E: ID_NET_NAME_MAC=enx3cfdfeb49d30
E: ID_NET_NAME_PATH=enp94s0f0
E: ID_NET_NAME_MAC=enx3cfdfeb49d31
E: ID_NET_NAME_PATH=enp94s0f1
# dmesg | grep -F "renamed from"
[   32.323995] i40e 0000:1a:00.0 eno1: renamed from eth0
[   32.631978] i40e 0000:1a:00.1 eno2: renamed from eth1
[   32.891945] i40e 0000:5e:00.0 enp94s0f0: renamed from eth2
[   33.151972] i40e 0000:5e:00.1 enp94s0f1: renamed from eth3

after a reboot into the bpo kernel:
# cat /etc/debian_version
12.10
# uname -vr
6.12.22+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.22-1~bpo12+1 (2025-04-25)
# ip l show | grep -F " en" | cut -d: -f2
 eno1np0
    altname enp26s0f0np0
 eno2np1
    altname enp26s0f1np1
 enp94s0f0np0
 enp94s0f1np1
# udevadm info -e | grep -F ID_NET_NAMING_SCHEME= | sort -u
E: ID_NET_NAMING_SCHEME=v252
# udevadm info -e | grep -F ID_NET_NAME_
E: ID_NET_NAME_MAC=enx3cecefd0da34
E: ID_NET_NAME_ONBOARD=eno1np0
E: ID_NET_NAME_PATH=enp26s0f0np0
E: ID_NET_NAME_MAC=enx3cecefd0da35
E: ID_NET_NAME_ONBOARD=eno2np1
E: ID_NET_NAME_PATH=enp26s0f1np1
E: ID_NET_NAME_MAC=enx3cfdfeb49d30
E: ID_NET_NAME_PATH=enp94s0f0np0
E: ID_NET_NAME_MAC=enx3cfdfeb49d31
E: ID_NET_NAME_PATH=enp94s0f1np1
# dmesg | grep -F "renamed from"
[   31.392947] i40e 0000:1a:00.1 eno2np1: renamed from eth1
[   31.398904] i40e 0000:1a:00.0 eno1np0: renamed from eth0
[   31.405096] i40e 0000:5e:00.0 enp94s0f0np0: renamed from eth2
[   31.411265] i40e 0000:5e:00.1 enp94s0f1np1: renamed from eth3

#1105223#22
Date:
2025-06-15 13:48:51 UTC
From:
To:
+1 on Andy’s point above: I don’t understand the new inconsistency here but that is besides the point - on an upgrade, interface names should not be changed in such a surprising manner. I got a notification that dnsmasq was modified and "do I want a diff / keep / accept / shell to inspect question” - I would expect something similar from systemd/udev/ whatever system is responsible for this.

Thank you for all your work,
florin