Your message dated Fri, 29 Jan 2021 18:44:04 +0100
with message-id <[email protected]>
and subject line Re: Bug#953019: udev: unexpected network interface name
changes on upgrade from stretch
has caused the Debian Bug report #953019,
regarding udev: unexpected network interface name changes on upgrade from
stretch
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
953019: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953019
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: udev
Version: 241-7~deb10u3
After upgrading a system from stretch to buster, the names of some network
interfaces changed unexpectedly. Specifically:
stretch# udevadm test-builtin net_id /sys/class/net/enp94s0f0
calling: test-builtin
=== trie on-disk ===
tool version: 232
file size: 8669279 bytes
header size 80 bytes
strings 1850783 bytes
nodes 6818416 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
ID_NET_NAME_MAC=enxd09466xxxxxx
ID_NET_NAME_PATH=enp94s0f0
Unload module index
Unloaded link configuration context.
buster# udevadm test-builtin net_id /sys/class/net/ens1f0np0
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
Using default interface naming scheme 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxd09466xxxxxx
ID_OUI_FROM_DATABASE=Dell Inc.
ID_NET_NAME_PATH=enp94s0f0np0
ID_NET_NAME_SLOT=ens1f0np0
Unload module index
Unloaded link configuration context.
This is the same interface, as shown by the ID_NET_NAME_PATH values.
Even if it weren't for the newly detected ID_NET_NAME_SLOT I think I would
still have had to reconfigure things due to the extra np# suffix.
I had serial console access so this was only a minor inconvenience, but
how could I have avoided being surprised? Isn't predictability the main
selling point for this interface naming scheme?
Some hardware info:
5e:00.0 Ethernet controller [0200]: Broadcom Limited BCM57416 NetXtreme-E
10GBase-T RDMA Ethernet Controller [14e4:16d8] (rev 01)
Handle 0x0901, DMI type 9, 17 bytes
System Slot Information
Designation: Mezzanine 1
Type: x8 PCI Express 3
Current Usage: In Use
Length: Other
ID: 1
Characteristics:
3.3 V is provided
PME signal is supported
Bus Address: 0000:5e:00.0
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: Dell Inc.
Version: 2.4.8
Release Date: 11/27/2019
[...]
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: PowerEdge R440
[...]
--- End Message ---
--- Begin Message ---
Hi Sergio
On Tue, 3 Mar 2020 15:12:41 +0100 Sergio Gelato
<[email protected]> wrote:
> * Michael Biebl [2020-03-03 14:34:37 +0100]:
> > > stretch# udevadm test-builtin net_id /sys/class/net/enp94s0f0
> >
> > > ID_NET_NAME_PATH=enp94s0f0
> >
> > ...
> >
> > > buster# udevadm test-builtin net_id /sys/class/net/ens1f0np0
> >
> > > ID_NET_NAME_PATH=enp94s0f0np0
> > > ID_NET_NAME_SLOT=ens1f0np0
> >
> >
> > Are you using the same kernel?
>
> I've run "udevadm test-builtin net_id /sys/class/net/enp94s0f0" after
> "apt-get dist-upgrade" and before rebooting into the new kernel and
> seen the new values of ID_NET_NAME_PATH and ID_NET_NAME_SLOT.
> (I have several servers with this hardware configuration. I would not
> have known to check this the first time; this is an observation from
> the second upgrade.)
>
> > Do you get different names if you boot
> > your buster system with the stretch kernel?
>
> That I haven't tried yet. I have two more servers of this type to
upgrade.
> For a quick test, I've now upgraded systemd from stretch-backports…
>
> # apt-get install --only-upgrade -t stretch-backports udev
> [...]
> The following additional packages will be installed:
> libpam-systemd libsystemd0 libsystemd0:i386 libudev1 systemd
> Suggested packages:
> systemd-container
> The following packages will be upgraded:
> libpam-systemd libsystemd0 libsystemd0:i386 libudev1 systemd udev
> 6 upgraded, 0 newly installed, 0 to remove and 193 not upgraded.
> [...]
> # udevadm test-builtin net_id /sys/class/net/enp94s0f0
> Load module index
> Parsed configuration file /lib/systemd/network/99-default.link
> Created link configuration context.
> Using default interface naming scheme 'v240'.
> ID_NET_NAMING_SCHEME=v240
> ID_NET_NAME_MAC=enxd09466xxxxxx
> ID_OUI_FROM_DATABASE=Dell Inc.
> ID_NET_NAME_PATH=enp94s0f0
> ID_NET_NAME_SLOT=ens1f0
> Unload module index
> Unloaded link configuration context.
> # reboot
>
> After the reboot into kernel 4.9.210-1, the new interface name is
ens1f0.
> So the switch to the slot-based name follows the systemd upgrade,
while
> the np0 suffix seems kernel-related.
At this point, I guess we might already have users where changing the
naming scheme now would break their setup as well. So I guess it's best
to just close this bug report.
Btw, nowadays there is "man systemd.net-naming-scheme"
So you can manually pin down the version scheme it you don't want it to
change.
Regards,
Michael
signature.asc
Description: This is a digitally signed message part
--- End Message ---
