[systemd-devel] systemd.net-naming-scheme change after update

[Thomas HUMMEL]

Hello,

I've read about consistent network device naming here :

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

- https://www.freedesktop.org/software/systemd/man/systemd.link.html#

and here

- 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#consistent-network-interface-device-naming_configuring-and-managing-networking

But I still cannot explain neither how exactly it works on CentOS nor a 
change I experienced in the onboard ethernet device's name when updating 
my system (runing systemd-udev-239) from CentOS 8.1 to CentOS 8.2 (i386) 
with one method but not with another one :

Starting from CentOS 8.1 where the onboard ethernet device name was 
eno1np0, I tried :

a) to reinstall with a kickstart based mechanism (via the xCAT HPC 
provisioning software) pointing to the 8.2 repos

-> device name stayed the same once booted in CentOS 8.2

# udevadm info /sys/class/net/eno1np0 | grep ID_NET
E: ID_NET_DRIVER=bnxt_en
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=eno1np0
E: ID_NET_NAME_MAC=enx3cecef4247de
E: ID_NET_NAME_ONBOARD=eno1np0
E: ID_NET_NAME_PATH=enp198s0f0np0

This is what I was expecting.

b) to update to 8.2 running yum update

-> device name changed to enp198s0f0np0

- I did not change any udev rules
- I did not change NamePolicy (NamePolicy=kernel database onboard slot path)
- I did not disable anything relative to consistent naming with neither 
net.ifnames=0 nor biosdevname=0

According to this policies order, it seems legit to me to end up with 
onboard naming scheme. But how could I have in the yum update case ended 
up with a path naming scheme ?

In a more general way, I don't fully understand how the rename is 
supposed to be done and/or the link between NamePolicy and udev renaming 
rules as they don't seem to apply to ID_NET_NAME_* names

For instance, on CentOS, you go through the following rules :

- 60-net.rules calling /lib/udev/rename_device

which I don't think match my case as my config files has no HWADDR var set :

# Generated by parse-kickstart
TYPE="Ethernet"
DEVICE="eno1np0"
UUID="8482a953-65dc-4814-b6b4-a9d9c7edc4a1"
ONBOOT="yes"
BOOTPROTO="dhcp"
IPV6INIT="yes"

So I should go to

- 71-biosdevname.rules calling biosdevname

SUBSYSTEMS=="pci", PROGRAM="/sbin/biosdevname --smbios 2.6 --nopirq 
--policy physical -i %k", NAME="%c"  OPTIONS+="string_escape=replace" 


which should in my case set the NAME var to em1 as this is the output of 
the command when run manually

- 75-net-description.rules which calls IMPORT{builtin}="net_id"

-> is this what sets the ID_NET_NAME_* udev properties ?

Does this step somehow use the NAME var set after biosdevname ?

- 80-net-setup-link.rules

IMPORT{builtin}="net_setup_link"

NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"

What I understand here in my case is that NAME is not empty (because of 
biosdevname step) so I don't understand why I don't end up with em1 
instead of the
  onboard style name. This would mean ID_NET_NAME has been set in a 
previous step ? What was the use of the biosdevname stop then ?


finally, what does "If the kernel claims that the name it has set for a 
device is predictable" mean 
(https://www.freedesktop.org/software/systemd/man/systemd.link.html#) ?

And what is the kernel name (%k) : is it always ethX ?

Thanks for your help

--
Thomas HUMMEL