# 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:

```

$ udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

ID_NET_NAME_MAC=enx1c6f65d35e8c

ID_OUI_FROM_DATABASE=GIGA-BYTE TECHNOLOGY CO.,LTD.

ID_NET_NAME_PATH=enp4s0

```

And this is mostly of course explained also at http://wiki.gentoo.org/wiki/Udev/upgrade

----------

## 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.

----------

## SamuliSuominen

 *UberLord wrote:*   

> Rant time!
> 
> This is why interface renaming is a Bad Thing.
> 
> 

 

What "This"? "This" seems more like a case of bad INSTALL_MASK or other user error.

Anyway, I agree that the control should be left to the kernel, unfortunately, there is currently no feature in the kernel to gain predictable or persistent interface naming, so we are left with userspace to correct it for us.

----------

## UberLord

 *ssuominen wrote:*   

>  *UberLord wrote:*   Rant time!
> 
> This is why interface renaming is a Bad Thing.
> 
>  
> ...

 

I don't actually use Gentoo right now, my Linux machines don't use udev or systemd either (well, one does)

 *Quote:*   

> 
> 
> Anyway, I agree that the control should be left to the kernel, unfortunately, there is currently no feature in the kernel to gain predictable or persistent interface naming, so we are left with userspace to correct it for us.

 

Lies. My interface names are predictable and persistent without any user-space tool thank-you very much.

Now, if I hotplug devices, like say a USB wireless stick, then no, they are not persistent or predictable. But my argument is this - hotplugged interfaces are generally setup via automatic methods, such as DHCP, so why does the interface name matter?

----------

