I’m a bit puzzled by what I’m seeing. We’re doing lots of automated installs via Kickstart, and the predictive interface names during Kickstart don’t match the names that are presented by the installed system.
For instance, I’ve got the following four interface names present during Kickstart:
and yet when Rocky boots for normal usage, somehow the interface names now become:
I’m assuming the np# portion refers to a physical port on the network card, but why is that name not used during Kickstart?
Or maybe the question should be, why does it become the interface name under Rocky proper? e.g., why do I see this in dmesg:
[ 3.241385] usbcore: registered new interface driver cdc_ether
[ 6.892182] mlx5_core 0000:98:00.1 enp152s0f1: renamed from eth3
[ 6.904849] mlx5_core 0000:b1:00.0 enp177s0f0: renamed from eth4
[ 6.925118] mlx5_core 0000:4b:00.1 enp75s0f1: renamed from eth1
[ 6.947146] mlx5_core 0000:b1:00.1 enp177s0f1: renamed from eth5
[ 6.964074] mlx5_core 0000:4b:00.0 enp75s0f0: renamed from eth0
[ 6.986098] mlx5_core 0000:98:00.0 enp152s0f0: renamed from eth2
[ 33.513288] mlx5_core 0000:98:00.1 enp152s0f1np1: renamed from eth3
[ 33.592246] mlx5_core 0000:4b:00.0 enp75s0f0np0: renamed from eth0
[ 33.620145] mlx5_core 0000:b1:00.1 enp177s0f1np1: renamed from eth5
[ 33.638210] mlx5_core 0000:98:00.0 enp152s0f0np0: renamed from eth2
[ 33.652080] mlx5_core 0000:b1:00.0 enp177s0f0np0: renamed from eth4
[ 33.694620] mlx5_core 0000:4b:00.1 enp75s0f1np1: renamed from eth1
That’s a lot of volatility for a network interface name, and I’m genuinely confused as to which naming convention to code for – especially given that systemd interface names are supposed to be stable.
If anyone can help shed some light here, it would be greatly appreciated, because we’re not seeing similiar behavior from any of the other Rocky builds so far – although in fairness, the hosts in question here are not using bonding and everything else is.
Historically that’s what we’ve always done, but it’s not an option here since each interface has its own specific configuration, and we can’t take chances with kernel enumeration suddenly deciding to swap the logical names of eth0 and eth2, so we have to stick with systemd predictive naming.
I ran into the same problem on my Dell PowerEdge R540 with 6 NICs.
Devices renaming was very inconsistent.
Sometimes not all were renamed at all and still had an ethX device name.
I tried disabling kernel renaming (ie. biosdevname=0 net.ifnames=0).
That still lead to inconsistent naming (ie. after a reboot eth2 was now eth5, etc)
I finally went with systemd rules based upon MAC address.
That would result in device with MAC aa:bb:cc:dd:ee:ff always have the device name netxxx.
I did that for each interface.
I also had to fix the NM connections in /etc/NetworkManager/system-connections to reflect the changes.
Unfortunately, I ended up just redoing the install to see if that eliminated the behavior, so it remains to be seen if it happens again.
It’s still a big question mark for me, though, because we have other hardware acquired around the same time that also presents interfaces with np# in the name, but it does this already during Kickstart so the problem of the drifting interface name doesn’t come up on those systems.
The other possibility (although it seems like a remote one to me) is that this is caused by some underlying hardware issue. The servers in question are part of a small batch of ten, seven of which are currently cycling through hardware enumeration indefinitely and are not able to POST. Two of these seven exhibited the drifting interface name behavior earlier, so I reinstalled them and they got through Kickstart no problem but went to enumeration purgatory immediately after the post-Kickstart reboot. :-/
I have various servers with various cards. I’ve seen many types of names, including
eno1, ibp59s0, ens5f0, and enp8s0f0 on el9.
I do have eno1np0 on el8 – a Dell R640, where I enabled “partitions” in BIOS.
Each of two physical ports (np0 and np1) shows as 8 interfaces (with unique enpN prefix).
I even tested SR-IOV on top of those. Interfaces galore …
Hmmm, in that case … is it possible then that these servers shipped from the manufacturer with NIC partitioning enabled in the BIOS when the OS was initially provisioned and the Kickstart kernel/stack doesn’t make the distinction, but the actual OS kernel/stack does?
Are systemd or NetworkManager permitted to rename interfaces on their own after the OS finishes booting? (removable interfaces and deliberate renames via ip notwithstanding)