interface names mess - predictable interfaces names broken

travnick · Feb 12th 2024

Hi all!

When booting the OMV 7 today (runs on QNAP TS-453A, 4x eth integrated) I faced really strange issue that one - and only one interface is not renamed to enpXs0, but left with eth1/eth2 name. This of course breaks avahi and other configuration options that rely on interface name.

OMV is installed on top of debian (since wanted to have OMV running on LVM for flexibility)

Also there is no autodetect of wire plugged into the eth port.

How to get it working properly?

Code

root@osiol:~# ifconfig -a
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether xx_my_mac_here_xx  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp10s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether xx_my_mac_here_xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x81200000-8127ffff  

enp5s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether xx_my_mac_here_xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x81500000-8157ffff  

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.109  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::265e:beff:fe1c:256  prefixlen 64  scopeid 0x20<link>
        ether xx  txqueuelen 1000  (Ethernet)
        RX packets 336  bytes 49695 (48.5 KiB)
        RX errors 0  dropped 10  overruns 0  frame 0
        TX packets 104  bytes 24970 (24.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x81400000-8147ffff  

eth2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether xx_my_mac_here_xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x81300000-8137ffff  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16  bytes 1528 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1528 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lxcbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.0.3.1  netmask 255.255.255.0  broadcast 10.0.3.255
        ether 00:16:3e:00:00:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Display More

Code

root@osiol:~# dmesg |grep eth
[   10.899632] igb 0000:05:00.0: added PHC on eth0
[   10.899672] igb 0000:05:00.0: eth0: (PCIe:2.5Gb/s:Width x1) xx_my_mac_here_xx
[   10.899756] igb 0000:05:00.0: eth0: PBA No: 001300-000
[   10.932223] igb 0000:06:00.0: added PHC on eth1
[   10.932264] igb 0000:06:00.0: eth1: (PCIe:2.5Gb/s:Width x1) xx_my_mac_here_xx
[   10.932347] igb 0000:06:00.0: eth1: PBA No: 001300-000
[   10.965135] igb 0000:09:00.0: added PHC on eth2
[   10.965170] igb 0000:09:00.0: eth2: (PCIe:2.5Gb/s:Width x1) xx_my_mac_here_xx
[   10.965250] igb 0000:09:00.0: eth2: PBA No: 001300-000
[   10.996803] igb 0000:0a:00.0: added PHC on eth3
[   10.996842] igb 0000:0a:00.0: eth3: (PCIe:2.5Gb/s:Width x1) xx_my_mac_here_xx
[   10.996913] igb 0000:0a:00.0: eth3: PBA No: 001300-000
[   11.771210] igb 0000:06:00.0 enp6s0: renamed from eth1
[   11.864326] igb 0000:05:00.0 enp5s0: renamed from eth0
[   11.964397] igb 0000:0a:00.0 enp10s0: renamed from eth3

Display More

crashtest · Feb 13th 2024

Since you installed OMV, over Debian, I'm going to assume that you used the scripted install.

Are you trying to fix your current install or would you be willing to rebuild?
(And)
How many of the 4 interfaces are you actually using?

travnick · Feb 14th 2024

Right now I have only one interface in use, but would like to have it all working, and there are plans for bonding.

Followed this https://docs.openmediavault.or…stallation/on_debian.html and Install OMV7 on Debian 12 (Bookworm)

By rebuild, you mean remove and install it once again (OMV), or total debian remove and install from scratch?

Ideally it would be to repair rather than reinstalling without knowing the reason and potentially have the same issue in the future.

travnick · Feb 14th 2024

For a few reboots, it looked like I solved the issue. I've even configured all of 4 interfaes in OMV web UI. At least there are no issues with mixed ethX and enpX now. Currently I see only enpX or ethX.

Unfortunately, after few reboots, interfaces are up only after I execute dhclient.

I did mdadm test of renamed and eth2 interfaces gives the clue that maybe there is some persistent database for devices that introduces the issues.

So found and fired systemd-hwdb update, also removed /lib/udev/hwdb.bin and after system restart I see no issues with ethX mixing with enpX interface names.

crashtest · Feb 14th 2024

Here's something to keep in your back pocket:

We ran into another issue with predictive naming when building R-PI's. It was solved by nailing down the wired interface name with a .link file.

At /etc/systemd/network/

Create the file 10-persistent-net.link

#With the following contents:

[Match]

MACAddress=dc:a6:32:57:17:77

[Link]

Name=eth0
________________________________________________

The above is an example, with the MAC address being from the wired port on my R-PI. Substitute in the MAC address for the interface that you want to nail down. The name can be anything you like. I chose eth0, from before the time when they decided to help us out with predictive naming.

It takes a reboot to activate it.

The reason why I mentioned, "would you be willing to rebuild" is because OMV writes interface names to it's configuration during the build. I don't know if those entries are permanent, updated later, etc. So,, it would be best to nail down interface names before the build.

I haven't experimented with a file for multiple interfaces. However, this file can be elaborate if you want to set names for more than one interface. Guidance on how to do that is -> here.

travnick · Feb 16th 2024

Thank you for the suggestion, but I'd like to solve the issue rather than making a workaround (for now :D)

After many reboots later (all done on the same machine, one instance on SSD, second on 3HDD raid1):

First instance of OMV7 SSD disk (by OMV7 installer, directly on the disk, ext4 partition):
- on this system I see no such issue, I can reboot, adjust network interface preferences and there is no "eth1" naming issue. WOL, MTU adjustments works as expected without any issues.
Second instance of OMV7 (installed on top of debian, raid1 with 3 HDDS, lvm and btrfs for the root filesystem)
- the name enp6s0 is stable (tested with many reboots), but as soon as I enable WOL (by the web UI), then after reboot the eth1 name appears. (setting MTU also triggers this behavior)

How do I diagnose the issue further?

votdev · Feb 16th 2024

Quote from travnick

Second instance of OMV7 (installed on top of debian, raid1 with 3 HDDS, lvm and btrfs for the root filesystem)
the name enp6s0 is stable (tested with many reboots), but as soon as I enable WOL (by the web UI), then after reboot the eth1 name appears. (setting MTU also triggers this behavior)

At the final end the network configuration is generated from netplan for systemd-networkd. If there is a problem with WOL, you need to have a look in this area.

travnick · Feb 16th 2024

Where precisely I should look?

There is a file /etc/netplan/20-openmediavault-enp6s0.yaml. If there is wakeonlan: true (modified by web UI), then after reboot, the eth1 appears. After that, if I manually modify this to false and do the restart, then it goes back to enp6s0 (of course web UI has wrong state, but it's normal in this case)

interface names mess - predictable interfaces names broken

macom Feb 12th 2024

Participate now!