Hello everyone,
In my 13.2 installation my network interfaces where both named as eno1/ensXpY.
However, after the (offline via DVD) upgrade to 42.2 and later the upgrade to 42.3 my network interfaces are named as eth0/eth1!
biosdevname IS installed, however is not used.
There is no biosdevname=0 (and no biosdevname=1 as well) in my Grub menu entries
There is a file (/etc/udev/rules.d/70-persistent-net.rules) which is generated after a reboot when I delete it!
So, how can I enable the predictable names again?
It’s a big issue for me because my script don’t use the ethX naming for years now!
Even firewall is not working because the SuSEFirewall2 configuration file is not aware of the new interfaces!
When upgrading a remote machine from openSUSE 13.2, make sure your network interfaces are named correctly.
openSUSE 13.2 used so-called predictable network interface names (for example, enp5s0), whereas openSUSE Leap 42.1 uses persistent interface names (eth0). After upgrading and rebooting, the network interface names may therefore change. This could lock you out of the system. To avoid interfaces from being renamed, run the following command for each of your network interfaces before you reboot the system:
/usr/lib/udev/udev-generate-persistent-rule -v -c enp5s0 -n enp5s0 -o /etc/udev/rules.d/70-persistent-net.rules
Replace enp5s0 with the name of your network interface.
It’s down to the systemd version in use IIRC. I note that 70-persistent-net.rules mentions…
# This file was automatically generated by the /usr/lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x100e (e1000)
So you could edit with your preferred interface naming if desired.
FWIW, I know the predictable interface name can be got from the traditional name (eg eth0) using…
sudo udevadm test /sys/class/net/eth0 2>/dev/null |grep ID_NET_NAME_
You are a life-saver! The udevadm command did the trick, thank you!
However, I don’t get it. In my Fedora 24 (with a much newer systemd (233) the interface names are still in the “new” enp…
Also, my onboard card is no longer eno1 but enp2s0 (which implies that it’s not an on board!)
On the “philosophical” side, although a lot of people didn’t like the predictable names, I believe it was absolutely right! So, going back to hardcoded ethX devices with udev rules IS wrong. And based on the documentation inside the scripts it looks like it a configurable option.
I will compare the scripts with my Fedora, although I don’t know the order to command execution etc.
FWIW, it can also be run with a wildcard to get naming for all available interfaces in one hit…
sudo udevadm test /sys/class/net/* 2>/dev/null |grep ID_NET_NAME_
However, I don’t get it. In my Fedora 24 (with a much newer systemd (233) the interface names are still in the “new” enp…
It’s because openSUSE Leap is based on SLES which is still using the traditional naming, and 42.3 is using systemd version 228. Tumbleweed is using the predictable naming though.
I need to check with RHEL 7.x, but from tomorrow. I know for sure that RHEL uses the predictable name, but I don’t remember from the top of my head the systemd version .
On 11/12/2017 02:46 AM, tpe wrote:
>
> I need to check with RHEL 7.x, but from tomorrow. I know for sure that
> RHEL uses the predictable name, but I don’t remember from the top of my
> head the systemd version .
>
>
I know for sure that it doesn’t have to though. It depends.
Not disagreeing that “changing” things is always a problem. But when you have
automatic unpredictable predictable possible erroneous names vs. a way to ensure
constant naming using the human mind, not sure which method I prefer.
Well, I have made my mind:
I don’t want to have udev settings my names. I was present in a lot of motherboard changes that required manual modifications in the relevant files at 03:00 in the morning. But, I never had an issue with the strange enpXsY names even after a motherboard/NIC change. But this is for the physical world.
In the virtual world, where the devices never changes, I prefer the ethX.