I'm confused (again) - this time about predictable network names.
I have two *on-board* Ethernet ports enabled on a Dell server running PM 5.4 (this system has always been 5.x from the start)
My network interface names are en0 and en1
I believe they are named like this rather than something like enp2s0f0 purely because they are onboard ports. Is that correct?
In /lib/systemd/network/99-default.link
So...onboard gets precedence to slot and path, hence en01 ?
But I don't know if they count as "predictable" or not. I'm thinking in particular of what might happen if I had to do a chassis swap - i.e. in the event of a motherboard failure, I would put the disks in an identical system which would obviously have the same model of motherboard.
Or during an upgrade from 5.x to 6.x, where predictable network names seem to be strongly emphasised in Buster.
Can anybody tell me if it is likely that all would be well, and the first onboard interface would still be eno1 and the second eno2? i.e. all this counts as "predictable"?
Digging a bit further:
In mode detail for eno1, I see this:
Just to confuse me even further, I see this in dmesg:
Where are these eth0/eth1 coming from? The kernel itself?
/etc/default/grub has nothing: GRUB_CMDLINE_LINUX=""
There is no 70-persistent-net.rules - it does not exist.
There is no /etc/udev/rules.d/10-network.rules either.
I have two *on-board* Ethernet ports enabled on a Dell server running PM 5.4 (this system has always been 5.x from the start)
My network interface names are en0 and en1
Code:
# ls /sys/class/net/
eno1 eno2 lo vmbr0
I believe they are named like this rather than something like enp2s0f0 purely because they are onboard ports. Is that correct?
In /lib/systemd/network/99-default.link
Code:
[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent
So...onboard gets precedence to slot and path, hence en01 ?
But I don't know if they count as "predictable" or not. I'm thinking in particular of what might happen if I had to do a chassis swap - i.e. in the event of a motherboard failure, I would put the disks in an identical system which would obviously have the same model of motherboard.
Or during an upgrade from 5.x to 6.x, where predictable network names seem to be strongly emphasised in Buster.
Can anybody tell me if it is likely that all would be well, and the first onboard interface would still be eno1 and the second eno2? i.e. all this counts as "predictable"?
Digging a bit further:
Code:
# udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
ID_NET_NAME_MAC=enxd4ae52b54c50
ID_OUI_FROM_DATABASE=Dell Inc.
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_PATH=enp2s0f0
--
# udevadm test-builtin net_id /sys/class/net/eno2 2>/dev/null
ID_NET_NAME_MAC=enxd4ae52b54c51
ID_OUI_FROM_DATABASE=Dell Inc.
ID_NET_NAME_ONBOARD=eno2
ID_NET_NAME_PATH=enp2s0f1
In mode detail for eno1, I see this:
Code:
# udevadm info /sys/class/net/eno1
P: /devices/pci0000:00/0000:00:1c.4/0000:02:00.0/net/eno1
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/net/eno1
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=NetXtreme II BCM5716 Gigabit Ethernet
E: ID_MODEL_ID=0x163b
E: ID_NET_DRIVER=bnx2
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_MAC=enxd4ae52b54c50
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp2s0f0
E: ID_OUI_FROM_DATABASE=Dell Inc.
E: ID_PATH=pci-0000:02:00.0
E: ID_PATH_TAG=pci-0000_02_00_0
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Broadcom Limited
E: ID_VENDOR_ID=0x14e4
E: IFINDEX=2
E: INTERFACE=eno1
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eno1
E: TAGS=:systemd:
E: USEC_INITIALIZED=964148
Just to confuse me even further, I see this in dmesg:
Code:
# dmesg | grep renamed
[ 0.941421] bnx2 0000:02:00.0 eno1: renamed from eth0
[ 0.964359] bnx2 0000:02:00.1 eno2: renamed from eth1
Where are these eth0/eth1 coming from? The kernel itself?
/etc/default/grub has nothing: GRUB_CMDLINE_LINUX=""
There is no 70-persistent-net.rules - it does not exist.
There is no /etc/udev/rules.d/10-network.rules either.