Upgrade from udev212-r1 to =>215 interfacename changed again

[boospy]

Hi,

We have all us Gentoo's (Server amd64 hardened 32 and 64bit) running on KVM. For a view weeks ago there was an udevupgrade. In this case networkinterfacenames are changed. For example eth0 --> enp0s18v2. So we've changed alle about 35 Servers. This day i've done updates again. And i see an Upgrade to udev 215-rXX. So i do the upgrades normally. But after reboot the first VM i see, no network, and i see the interfacename has changed back to eth0. Sorry but what a fu.... !!!!

Is this a bug, or ... i don't know. But this is not fun. Changing always the interfacenames.

Has anyone same issue?

Best Regards
boospy

[SamuliSuominen]

There was no change between 212 and 215 in the handling of interface names. Both are using same configs, /lib/systemd/network/99-default.link (override is at /etc/systemd/network/99-default.link) and /lib/udev/rules.d/80-net-setup-link.rules (override is at /etc/udev/rules.d/80-net-setup-link.rules).

So, I guess...

1. Verify you have both 99-default.link and 80-net-setup-link.rules in place at /lib, perhaps post output of `ls -ld /lib/systemd/network/99-default.link /lib/udev/rules.d/80-net-setup-link.rules` and `cat /lib/systemd/network/99-default.link /lib/udev/rules.d/80-net-setup-link.rules` here?
2. Verify you don't have anything in /etc that would override them, perhaps post output of `ls /etc/systemd/network` and `ls /etc/udev/rules.d` to this thread for everyone to see?
3. Verify you are not using the net.ifnames=0 kernel commandline, like from /proc/cmdline, perhaps post output of `cat /proc/cmdline` here?
4. Verify you don't have any system breaking INSTALL_MASK set that would delete configuration files? Like `emerge --info |grep INSTALL_MASK`

And umm, verify your interface has some attributes available, like for example:

[UberLord]

Rant time!

This is why interface renaming is a Bad Thing.

The name of the interface ONLY matters for assigning a static fixed address manually or special firewall rules.
In both cases, this is only needed for servers where there is no hotplugging of interfaces and upgrades are carried out in a controlled manner.
In this instance, the only way the interface name could change is if the kernel enumerated devices in a different order [1]

The every other case, the interface name does not matter. Servers can get their static addresses via DHCP or IPv6 RS/RA (ie, not manual) and some firewalls can be configured to be interface agnostic as well. Server daemons also generally bind to a fixed address (could be derived by DHCP remember) or the global address.

It removes control of the interface from the kernel

The kernel has a special socket that programs can open so they can listen to kernel events such as Hey, I have a new interface.
When something else wants to rename this interface based on this event, like say a DHCP client wanting to configure it quite fast, instead has to listen to this something else instead because this DHCP client could UP the interface preventing the device being renamed and causing chaos like that.
This forces the DHCP client to listen to both as the user may suddenly see sense and stop using udev. This causes code bloat, and would be repeated for each rival udev implementation.

Thank-you for listening!

[1] one of the original design goals of udev was interface renaming because someone got upset that the Linux kernel changed the way the PCI bus was enumerated thus changing eth0 and eth1 to eth1 and eth0.
Ironically udev has changed the way it names interfaces many more times than the Linux kernel.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool

[SamuliSuominen]

[UberLord]