# Network interfaces suddently renamed after reboot.

## mgnut57

After a reboot, my network interface names got messed up. I would appreciate any advice on fixing this. 

I have 3 physical interface devices:

```
# lspci | grep Ether

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)

04:00.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)

04:00.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
```

The two Intel devices are on a single card.

I have attempted to keep the interfaces called "ethX", despite the change to "predictable" names. I have 3 files in the /etc/systemd/network directory:

```
# ls /etc/systemd/network/

90eth0.link  90eth1.link  90eth2.link
```

These map the MAC address to the names. 

Note that my system uses OpenRC, but I believe that these files should still be used. 

I also have a udev file: /etc/udev/rules.d/71-persistent-net.rules, with the same mapping between MAC addresses and device name as is used in the systemd files above. 

What is really strange is that my active network devices are now called "eth1", "eth2" and "eth3". What happened to "eth0": 

```
# grep eth0 boot.log

[   14.946490] eth0: renamed from ip_vti0

```

(My boot scripts include "dmesg >> /var/log/boot.log" to capture this information.) 

So, what happened to eth0? Why do my network device names not correspond to what I have specified?

I could use the new "predictable" network names, but how do I distinguish between the two interfaces on the Intel card and ensure that the names remain predictable? 

Frankly, the whole situation is frustrating, because my network names were predicable until the new "predictable" names were introduced.

----------

## Ant P.

Where does ip_vti0 come from?

----------

## mgnut57

 *Ant P. wrote:*   

> Where does ip_vti0 come from?

 

That was what I was wondering. I have no idea what this is.

----------

## Ant P.

/sys/class/net/ should have a symlink telling which driver owns it.

----------

## mgnut57

 *Ant P. wrote:*   

> /sys/class/net/ should have a symlink telling which driver owns it.

 

```
$ ls -l /sys/class/net/

total 0

lrwxrwxrwx 1 root root 0 Mar  7 18:57 eth0 -> ../../devices/virtual/net/eth0

lrwxrwxrwx 1 root root 0 Mar  7 18:57 eth1 -> ../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/eth1

lrwxrwxrwx 1 root root 0 Mar  7 18:58 eth2 -> ../../devices/pci0000:00/0000:00:1e.0/0000:04:00.0/net/eth2

lrwxrwxrwx 1 root root 0 Mar  7 19:00 eth3 -> ../../devices/pci0000:00/0000:00:1e.0/0000:04:00.1/net/eth3

lrwxrwxrwx 1 root root 0 Mar  7 18:57 lo -> ../../devices/virtual/net/lo

lrwxrwxrwx 1 root root 0 Mar  7 18:57 sit0 -> ../../devices/virtual/net/sit0

lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun0 -> ../../devices/virtual/net/tun0

lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun1 -> ../../devices/virtual/net/tun1

lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun2 -> ../../devices/virtual/net/tun2

lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun3 -> ../../devices/virtual/net/tun3

lrwxrwxrwx 1 root root 0 Mar  7 18:57 tunl0 -> ../../devices/virtual/net/tunl0
```

I assume that it is related to this:

```
$ zgrep VTI /proc/config.gz 

CONFIG_NET_IPVTI=y

# CONFIG_IPV6_VTI is not set

```

But this was true for the prior kernel version.

I should have mentioned earlier that I booted into a newer version of the kernel which I had not used before. I assume this issue is related. This still doesn't explain why my network device name assignments were not respected.

----------

## Ant P.

Something on your system is renaming that virtual interface to eth0, causing your ethernet cards to become misnumbered. That's not default or expected behaviour on any distro I've used, but I don't use systemd so I can't say if it's trying to be “helpful” here.

----------

## mgnut57

 *Ant P. wrote:*   

> Something on your system is renaming that virtual interface to eth0, causing your ethernet cards to become misnumbered. That's not default or expected behaviour on any distro I've used, but I don't use systemd so I can't say if it's trying to be “helpful” here.

 

I am not using systemd. My system uses OpenRC. 

I am wondering what might happen if I try to force the names to "internet0", "lan0", etc, instead of "ethX".

----------

## UberLord

 *mgnut57 wrote:*   

> I am not using systemd

 

 *mgnut57 wrote:*   

> I have 3 files in the /etc/systemd/network directory

 

Are you sure you're not using systemd?   :Question: 

----------

## mgnut57

 *UberLord wrote:*   

>  *mgnut57 wrote:*   I am not using systemd 
> 
>  *mgnut57 wrote:*   I have 3 files in the /etc/systemd/network directory 
> 
> Are you sure you're not using systemd?  

 

Yes. 

I have another system which also does not use systemd and the network interfaces are successfully (re)named by these files. 

udev has been infected by systemd and it is udev that reads these files. 

```

 # ps -Af | grep systemd

root      2553     1  0 Mar07 ?        00:00:00 /lib/systemd/systemd-udevd --daemon

root     11189 21671  0 21:07 pts/1    00:00:00 grep --colour=auto systemd

 # equery belongs /lib/systemd/systemd-udevd

 * Searching for /lib/systemd/systemd-udevd ... 

sys-fs/udev-239 (/lib/systemd/systemd-udevd)

```

----------

## Tony0945

Are you using eudev?  You should be. I can't tell from the files because they have the same names.

The later versions of udev only work with systemd

On my server with eudev

```
 # ps -Af | grep systemd

root       993   981  0 10:47 pts/0    00:00:00 grep --colour=auto systemd

```

Run "rc-update show" and see if it anything looks odd.Last edited by Tony0945 on Sat Mar 09, 2019 4:51 pm; edited 1 time in total

----------

## mgnut57

 *Tony0945 wrote:*   

> Are you using eudev?  You should be. I can't tell from the files because they have the same names.
> 
> The later versions of udev only work with systemd
> 
> On my server with eudev
> ...

 

No, I am not using eudev. 

I need to convert? Is there a guide?

This post says  that conversion isn't really required, unless one is an anti-systemd purist:

https://forums.gentoo.org/viewtopic-t-1055086-start-0.html

Simon

----------

## Tony0945

See "Migrating from udev to eudev" on the wiki https://wiki.gentoo.org/wiki/Eudev

You may have to uninstall udev. Try the wiki instuctions and see what happens. Report any blockers back here.

----------

## mv

 *Quote:*   

> I have attempted to keep the interfaces called "ethX". [...] These map the MAC address to the names.

 

If I understand correctly, you have some rules there like

```
ATTR... NAME="eth0"
```

This is broken: The kernel might just have initialized a new eth0 device while {e,}udev tries to rename some other device to eth0 -> this race can lead to all sort of problems.

This race problem is not related with udev vs. eudev.

Solution: Use a different namespace, e.g. lan0 ... lan3 (everything except eth* and other kernel-reserved stuff is fine).

----------

## Leio

sys-fs/udev is meant to be used when NOT having systemd, just like eudev. So it is your choice if you use udev or eudev.

udev is compiled from systemd tarball and is the main tested thing (by the majority of other popular distros), and eudev is a fork that sometimes gets updates pulled from udev.

There may be some out of the box default differences in terms of network naming and such, but if that's the case, udev can presumably be configured to behave like eudev does by default, should you so choose.

Just clarifying that NO, you don't HAVE to convert, only if you want to choose that.

----------

## mgnut57

 *Leio wrote:*   

> sys-fs/udev is meant to be used when NOT having systemd, just like eudev. So it is your choice if you use udev or eudev.
> 
> udev is compiled from systemd tarball and is the main tested thing (by the majority of other popular distros), and eudev is a fork that sometimes gets updates pulled from udev.
> 
> There may be some out of the box default differences in terms of network naming and such, but if that's the case, udev can presumably be configured to behave like eudev does by default, should you so choose.
> ...

 

Thanks for clarifying. 

I think my next move is to stop trying to force the names to be ethX style names and make them something completely different.

----------

## NeddySeagoon

mgnut57,

Its a bad thing to rename anything to names allocated on a first come first served basis by the kernel.

Add 

```
net.ifnames=0
```

 to your kernel command line to prevent interface renaming.

----------

## Leio

net.ifnames=0 disables the predictable network naming feature, so I don't see how the suggestion matches the intent.

eth0 and eth1 ARE the unpredictable names, depending on a first come first serve basis and may swap around on different boots, as I understand it.

The predictable network names feature solves that. Though I don't know what that ip_vti0 is about - searching suggests a swan VPN thing. I would expect something like "enp2s0", "ens1", "eno1" or such, depending what the network device is attached to.

But yes, net.ifnames=0 is one way to disable the predictable network names feature, thus have eth0, eth1, etc as far as udev is concerned (if udev is doing the renaming). sys-fs/udev prints out a rather long information at the end of its (re)install/upgrade on how to achieve that as well, including other methods how to disable the feature.

----------

## NeddySeagoon

Leio,

My main point was that eth0 is a rename of another interface.  net.ifnames=0 is more a diagnostic than a fix.

It will let us see the real names of the interfaces.

I don't know what ip_vti0 is either but I'm fairly sure its not a kernel name.

Being old and cynical, I'll just say that the predictable network naming feature just swaps one set of corner cases for a different set of corner cases and only served to upset a lot of users with a single interface.

I seen kernel interface names swap from kernel to kernel, where several different drivers are in use but never from boot to boot.

Its true that there is a race condition in enumerating several different interfaces that use different drivers.

MAC based interface naming solved that a long time ago and to me, had the advantage that rearranging the cards in PCI slots did not change interface names.

I'm not a fan of predictable network device names.

Its totally broken for USB dongles as they are named after the USB port they happen to gen plugged into. usb0 was much better.

Sorry for the rant ... its drifting off topic too.

I don't use either udev or eudev, so I don't have predictable network naming to turn off. 

That's not a path I recommend though.

Hmm ... vti  Virtual Tunnel Interface maybe.

----------

## Hu

 *Leio wrote:*   

> net.ifnames=0 disables the predictable network naming feature, so I don't see how the suggestion matches the intent.

 It makes the names be what the kernel initially assigned.  For a surprisingly large percentage of the population, kernel-assigned names work perfectly and the "predictable" names generated by systemd-udevd are worse, not better.

 *Leio wrote:*   

> eth0 and eth1 ARE the unpredictable names, depending on a first come first serve basis and may swap around on different boots, as I understand it.

 This is a common justification given for the misfeature, but speaking as someone who has had multiple motherboards with more than one NIC per board, I have never had kernel-assigned names cause any problems.  The kernel consistently assigns the same name to the same physical device, on boot after boot, both warm and cold.  This has been the case for a variety of kernel versions, and applies both when the two NICs are the same model and when they are different models.  I assume someone somewhere had a system where the names swapped out in an unpredictable manner, but I would expect that if this were a big problem in practice, the kernel developers would have been personally impacted and would have done something like "predictable interface names" right in the kernel, so that the interface has the right name from the moment that userspace can see it at all.  To me, that is the other bizarre aspect of this misfeature.  Why rename in usermode, which we know is racy, when you could do a kernel patch to let userspace set a policy (and have a default policy compiled into the kernel) that picks among the major naming modes: classic (ethN), PCI address based, MAC based, etc.?  That would ensure proper naming from the moment the device is created, independent of the speed with which userspace can react to the device creation messages.

Incidentally, the proponents of this misfeature made the political blowback much worse for themselves by insisting on naming it "predictable" when their names are actually more trouble to predict than the classic names.  Prior to this, we could tell users "put an IP on eth0, set a default route, and you're ready to go."  Now, we have to walk people through finding what name their NIC has before they can even begin configuring it.  That's not a nice step to add at the beginning when you're trying to help a struggling new user who just wants the system to work at all.

----------

## mgnut57

I agree that the new "predicable" names are anything but. 

In my opinion, when you have two identical interface cards (or two interfaces on the same card), the order of the names is not predicable.

----------

## Tony0945

Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork. I was unaware that the situation has changed, as I see no reason to go back.

Hu, I once had a Tyan server board that behaved unpredictably. It had two identical controllers on the motherboard. That was a feature of the board. I had to keep swapping the cable after reboot until I installed eudev and assigned names based on MAC address. I did use eth0 which I recognize was bad. Perhaps I had no trouble because I didn't use the second interface.  More recently (last year) I added an Intel board to one of my systems with an existing onboard Realtek. I did this for experimental purposes to see if there was a significant advantage to the Intel. I forced the order by delaying loading the driver module for the Intel board until after eth0 was up and running, ensuring that it would be eth1. I'm still running an older version of OpenRC so all modules are not automatically loaded, only those listed in /etc/conf.d/modules. I loaded the second module in /etc/local.d That might work for the OP but I assumed that he was running a later init system. Besides, I think he has two devices with the same driver. 

My 32-bit system also has ethernet devices, different devices and one built-in. When I was using it as a router, I named the faster card lan0 and the slower one wan0 via eudev MAC address rules. I chose those names because they made the firewall rules easier to understand ("Is eth0 the lan or is it eth1, hmmm!"). The "predictable names" I see usable for big servers with multiple identical cards. Even then, as you say, instead of the unpronounceable names, names indicating their network based on MAC (net0, net1... or netadmin, netmanuf, netexec, netadvert, netwww), would seem better and the whole system wouldn't change if one card died.

----------

## Leio

 *Tony0945 wrote:*   

> Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork.

 

This has been NEVER the case as of yet. When eudev was made, the only thing that happened was that the udev code was moved to the same code repository and release tarballs than systemd. It was buildable separate of systemd and no part of it depends on any other parts of systemd (besides pci/usb.ids maybe, but for that we have a separate package also, to have it shared across the udev options). I believe BSDs have a similar approach to code, but no-one is busy forking all that.

There are pros and cons to predictable names (yes, they are predictable across the same physical setup, unlike the alternative - the concerns raised are about not knowing what the name will be for a random different system). The majority of the Linux community has decided that the pros far outweigh the cons, but most of them don't deal with configuring stuff in text files. So lets leave it at that.

To me the on-topic question is, why some apparent virtual tunnel interface gets renamed, but the rest not. It seems eth1 through eth3 are real physical ones attached to PCI or PCI-E interface. I would expect these to be named enp4s0 or similar, maybe some old persistent-net.rules somehow got to keep them as eth*

----------

## NeddySeagoon

Leio,

Something somewhere is renaming interfaces to the names that the kernel allocates, so there is certainly some renaming going on.

Its odd that the rename is to eth0

----------

## Goverp

As an aside, the "predictable" names aren't stable, as I found when I added a USB3 card to my machine.  My ethernet card got renamed (which was a surprise, as I think it was a PCI device).  At which point I reverted to the old static names.  Which does expose me to a dangerous confusion - but only if I ever install a second ethernet card, and I doubt I will!

----------

## mv

 *Hu wrote:*   

> I have never had kernel-assigned names cause any problems.

 

I had. It is simply a question of luck and other kernel options.

 *Quote:*   

> and would have done something like "predictable interface names" right in the kernel

 

If this would have been possible, they would have done it. But there were long discussions, and the conclusion was that problems of this complexity should be solved in userspace.

 *Quote:*   

> Why rename in usermode, which we know is racy

 

No, it is not racy. It becomes only racy if the userspace tool should have been misconfigured by attempting to use names (e.g. "eth[0-9]*") which the kernel is supposed to use.

 *Quote:*   

> when you could do a kernel patch to let userspace set a policy

 

There is no reason to have complicated policies in kernel, especially if many natural policies (e.g. based on MAC or other data which makes the device unique enough on your system) should be easily changeable on boot. That's exactly what tools like udev were originally developed for (long before udev became part of systemd).

The original way of automatically storing the address also had its problems (e.g. when you exchanged the hardware of some interface) as well as the randomness of the eth* order. So compared to both, the default choice of "predictable" network interfaces certainly has some advantages, but each of the defaults has major drawbacks. For reliability you need to write your own rules. This is easy enough with {e,}udev and can be made absolutely robust if you can make certain assumption a-priori, e.g. if you can rely that you will ever have at most one ethernet device of a certain type. But exactly because of such assumptions, it would be questionable to make such rules a default.

----------

## krinn

Those predicatable names are total crap.

The "smart" idea behind it is that you could predict where your interface will be, while in real, all you could predict is the name the interface will get base on where the interface will be : and this is a total failure, because it is suppose to solve only that problem "where the interface will be".

That's what only bug users with eth* kernel naming scheme, because with multiple cards, you could predict the number of eth? entries you will get, but cannot predict who will be behind those names.

Then, you could identify who is who using their MAC address : and this time, really, the problem is solve!

You still are unable to tell "my 3com card will be eth1", it could be eth0 or eth3... but you are certain the 3com card will be either eth0, eth1, or eth2, and next to that, making a rule that target the mac of that 3com to force it to be the name you want.

That's where and what trouble users the most, because they naturally tend to want re-use eth* naming ; and this is where they fail, as kernel will only accept a renaming to another interface not already taken.

So if the "3com" card gets eth3, and user has identify it properly with a rule targetting its mac, the clash is coming because user will try to make that card eth0. A failure because eth0 is another card already.

The only proper way to solve this would be to name them in proper order ; so renaming eth0 first, in order to free eth0 namespace to futher rename eth3 into eth0 ; a non solvable issue if eth0 and eth3 need to be swap as you need a temporary interface name to hold one card to succeed.

But that's so easy to solve with different name: just making the rule renaming eth* interface to a name not use by kernel: myeth*, whatevername* ...

This to resume and shown that kernel eth* is more predictable than udev crap solution, you still cannot predict what card will be behind the eth* name, but you could predict the number of interface present, and predict then perfectly how many eth* you will get and make a rules for each interfaces and rename them into a name not using eth* name.

what udev has only done is avoiding the rename clash by using stupid names, that are base on some interface order and class the card is using ; its name is FULLY predictable as per the rules set by udev, but it won't change the fact you cannot predict where the interface will be, and so you're unable to know the name the interface will get (even you have read the udev rules to name an interface).

And you can compare the prediction result in such a scenario with 4 cards

kernel way:

* you will get 4 eth* entries, eth0-eth3

* you cannot know who will be behind each of them

udev "old way":

* you can make a rule that target all of them and change their name base on their mac to noclash_eth*

* you endup with 4 entries, name noclash_eth0 to noclash_eth2 and know who is behind each entry, because noclash_eth0 will be the card you have aim with its mac address

udev "predictable" way:

* you can "guess" that for each card, they will get their name depending on some physical entry ; ie: if it's a pci card... some other weird or critic rule or  whatever, in order to properly "predict" the name, you'll have to dig udev documentation to know the rule first.

* but you still cannot predict where they are, it depends on m/b configuration or if an interface sharing many aspect with the other is there or not ; and it hit user a lot, a card name pci1whatever will appears as pci2whatever because the m/b has re-assign pci slot itself ; you could had predict that the card will end pci2whatever, but you are just unable to predict when the change will be (sometimes m/b do that just because user has disable something that seems not related at all, like onbard sound card)

* you will then randomly endup with pci1whatever or pci2whatever, and this for each cards, so 4 cryptic entries name, without really knowing who is still behind

And when it's time to actually really using the cards: user will do the natural thing : "plug the cable into the 3com card" to use it.

* With kernel base, eth0 may not be the 3com card, and user is then unable to predict that eth0 is the card to use

* With kernel and renaming, myeth0 (or whatever) WILL BE that 3com card and only this one, and user is fully able to predict if i use myeth0 and i plug the cable into the 3com -> it work!

* With udev predictable name, user endup with some cryptic name for each interface, and user still don't know where the 3com is behind them, user has to look how the card was name, say pci1whatever and predict : i will always use pci1watever because the 3com should be behind it : and this will fail once the m/b or whatever change will make that pci1whatever name change!

so what method is the more predictable?

the two problems users have with kernel were clash when renaming and properly identify what card is behind a name, udev "predictable name" solve only the clash problem, even if we accept the names are predictable (who has read the rule to fully understand how that cryptic name is made?) ; you will never be sure that the name will not change.

----------

## Tony0945

 *Leio wrote:*   

>  *Tony0945 wrote:*   Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork. 
> 
> This has been NEVER the case as of yet.

  Won't continue arguing with a dev, but if udev and eudev are absolutely identical and unconnected to systemd , why do we have two?  

Perhaps udev was going to become dependant on systemd or rumored to become dependent on systemd. I DO recall that at one time it was an independent program than later subsumed into systemd or scheduled or rumored to become so. 

I greatly doubt that dev time was wasted in packaging and upgrading two identical packages with no difference but the name.

----------

## Anon-E-moose

 *krinn wrote:*   

> That's where and what trouble users the most, because they naturally tend to want re-use eth* naming ; and this is where they fail, as kernel will only accept a renaming to another interface not already taken.

 

I swap my eth[01]names, with a udev mac rule. Kernel doesn't care. 

From dmesg

[    1.639070] r8169 0000:03:00.0 eth0: RTL8168e/8111e at 0xffffc90000015000, a0:f3:c1:00:ba:6c, XID 0c200000 IRQ 64

[    1.640682] r8169 0000:0a:00.0 eth1: RTL8168f/8111f at 0xffffc90000025000, 08:60:6e:87:a3:cd, XID 08000800 IRQ 65

From my rules

# PCI device 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:f3:c1:00:ba:6c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:60:6e:87:a3:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

----------

## Anon-E-moose

 *Tony0945 wrote:*   

>  *Leio wrote:*    *Tony0945 wrote:*   Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork. 
> 
> This has been NEVER the case as of yet.  Won't continue arguing with a dev, but if udev and eudev are absolutely identical and unconnected to systemd , why do we have two?  
> 
> Perhaps udev was going to become dependant on systemd or rumored to become dependent on systemd. I DO recall that at one time it was an independent program than later subsumed into systemd or scheduled or rumored to become so. 
> ...

 

Eudev isn't exactly a carbon copy of udev, but it does seem to follow it (uses udev sources with some tweaks, from what I remember)

Udev and systemd were separate, once upon a time, but systemd subsumed udev (into it's source tarball) and there were plans to make it totally a systemd product not usable outside of it (as per msgs from LP quite some time ago). When eudev took off as a viable alternative, then we didn't hear much more about tying udev to only systemd. Thus we now have two "mostly" similar products. Of course if eudev were to go away there wouldn't be any assurance that LP and co wouldn't try and make it tied to systemd only, once again. In other words the "threat" of eudev keeps udev honest, in the sense of not being a systemd only service.

----------

## krinn

Anon-E-moose missing source https://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

Yes, udev on non-systemd systems is in our eyes a dead end, in case you

haven't noticed it yet. I am looking forward to the day when we can drop

that support entirely.

----------

## krinn

 *Anon-E-moose wrote:*   

> I swap my eth[01]names, with a udev mac rule. Kernel doesn't care. 

 

It does, i don't think they have change that.

But the race only appears when the clash is possible.

card1 (should be rename eth1)

card2 (should be rename eth0)

if kernel see card1 first, it gave it eth0, udev rename it to eth1, no clash (no eth1 exist yet)

if kernel see card2 first, it gave it eth0, udev has no need to rename it, card1 can take eth1 without trouble too.

Still clash may appears if you lack a rule for a card. ie

kernel see card1 first with no rules -> eth0

kernel see card2 second and udev try to change it to eth0 -> boom

see, even you, if you had another network card, you will have no rule for it, and may fall into the problem if the card is seen before the two others.

not a big deal, but using another name than eth* naming would had always saved you from that.

----------

## Hu

 *Tony0945 wrote:*   

> Hu, I once had a Tyan server board that behaved unpredictably. ...

  *mv wrote:*   

> I had. It is simply a question of luck and other kernel options.

 OK, so we have two confirmed instances of people who were inconvenienced by the classic logic.  :Smile:   I figured there had to be somebody out there. *Leio wrote:*   

> The majority of the Linux community has decided that the pros far outweigh the cons,

 What do you consider "the majority of the Linux community"? *mv wrote:*   

>  *Quote:*   and would have done something like "predictable interface names" right in the kernel If this would have been possible, they would have done it. But there were long discussions, and the conclusion was that problems of this complexity should be solved in userspace.

 The problem of generating automated names based on physical attributes seems simple enough.  udev does it with no configuration at all, by default.  Yes, persisting state so that a user-chosen name would be used would be a user-space problem, as would guaranteeing that hardware changes (such as moving to a different slot) does not change the name.  Picking "predictable" default names could be done in the kernel.  Could you cite these discussions? *mv wrote:*   

>  *Hu wrote:*   Why rename in usermode, which we know is racy No, it is not racy. It becomes only racy if the userspace tool should have been misconfigured by attempting to use names (e.g. "eth[0-9]*") which the kernel is supposed to use.

 So udev gets a chance to see the card come up with its original name, compute a new name, and assign that new name before any other user process is aware the card has a name at all?  No process other than udev ever gets to see or consider using the old name in any way?  My understanding was that udev was not special in this regard.  It becomes aware of the new card through the same mechanism as everyone else, at the same time as everyone else sees it.  If other processes see the card come up, then yes, there is a race where they could try to use the original name, then udev renames it out from under them.  That race applies even if udev never picks a colliding name. *mv wrote:*   

>  *Hu wrote:*   when you could do a kernel patch to let userspace set a policy There is no reason to have complicated policies in kernel, especially if many natural policies (e.g. based on MAC or other data which makes the device unique enough on your system) should be easily changeable on boot. That's exactly what tools like udev were originally developed for (long before udev became part of systemd).

 The policy isn't complicated.  It's an integer selector of mode (classic, MAC-based, topography based), applied to every device that gets a name.  It doesn't require a call back to usermode.  It doesn't track state in any way.  It only chooses what goes into the initial name, using only data the kernel already has loaded.  If automatic name mangling isn't sufficient for the user's needs, then a user-space program like udev would need to step in to assign explicit names.

I think this thread is drifting a bit.  mgnut57: would you prefer for a moderator to pull the "predictable names" discussion out into a separate thread?

----------

## mgnut57

OK, this is getting weirder. 

I decided to rename my interfaces to "internet0", "lan0" and "lanW0" using files in /etc/systemd/network:

```
# more /etc/systemd/network/*

::::::::::::::

/etc/systemd/network/90internet0.link

::::::::::::::

[Match]

MACAddress=00:1c:c0:d6:XX:XX

[Link]

Name=internet0

::::::::::::::

/etc/systemd/network/90lan0.link

::::::::::::::

[Match]

MACAddress=00:07:e9:1f:XX:XX

[Link]

Name=lan0

::::::::::::::

/etc/systemd/network/90lanW0.link

::::::::::::::

[Match]

MACAddress=00:07:e9:1f:XX:XX

[Link]

Name=lanW0
```

However, "internet0" becomes the renamed ip_vti0:

```
[   15.135066] internet0: renamed from ip_vti0

[   15.153392] systemd-udevd[2814]: Error changing net interface name 'tunl0' to 'internet0': File exists

[  134.657906] systemd-udevd[6193]: Error changing net interface name 'tun0' to 'internet0': Device or resource busy

[  134.657929] systemd-udevd[6193]: could not rename interface '8' from 'tun0' to 'internet0': Device or resource busy

[  134.679800] systemd-udevd[6193]: Process 'net.sh internet0 start' failed with exit code 1.

[  134.829273] systemd-udevd[6226]: Error changing net interface name 'tun1' to 'internet0': Device or resource busy

[  134.829312] systemd-udevd[6226]: could not rename interface '9' from 'tun1' to 'internet0': Device or resource busy

[   15.152236] internet0: renamed from sit0

[   15.183288] systemd-udevd[2830]: Error changing net interface name 'tunl0' to 'internet0': File exists

[   15.183313] systemd-udevd[2822]: Error changing net interface name 'ip_vti0' to 'internet0': File exists

[   86.582327] systemd-udevd[6545]: Error changing net interface name 'tun0' to 'internet0': File exists

[   86.582350] systemd-udevd[6545]: could not rename interface '8' from 'tun0' to 'internet0': File exists

[   86.594486] systemd-udevd[6545]: Process 'net.sh internet0 start' failed with exit code 1.

[   86.760273] systemd-udevd[6577]: Error changing net interface name 'tun1' to 'internet0': Device or resource busy

[   86.760322] systemd-udevd[6577]: could not rename interface '9' from 'tun1' to 'internet0': Device or resource busy

[   86.773674] systemd-udevd[6577]: Process 'net.sh internet0 start' failed with exit code 1.

```

And I now have an "eth0", which I was able to bring up:

```
# ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 73.XXX.XXX.XXX  netmask 255.255.254.0  broadcast 255.255.255.255

        inet6 fe80::21c:c0ff:fed6:fce2  prefixlen 64  scopeid 0x20<link>

        ether 00:1c:c0:d6:XX:XX  txqueuelen 1000  (Ethernet)

        RX packets 4999  bytes 1927347 (1.8 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 5218  bytes 1018099 (994.2 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

So still, I have  ip_vti0 interfering with the network interfaces.

----------

## mv

 *Anon-E-moose wrote:*   

> I swap my eth[01]names, with a udev mac rule. Kernel doesn't care.

 

Yes, as with most races, it is highly unlikely that you get in trouble. (That's why the race was not detected/cared about by ancient udev for years). However, it is a race, and whether you get bitten by it is a matter of luck. On some systems it might happen often and on other systems practically never.

 *krinn wrote:*   

> Still clash may appears if you lack a rule for a card

 

Not only then. The scenarios you have drawn does not describe the race:

1. kernel sees eth0 which udev is supposed to rename to eth1.

2. before udev can do the renaming, kernel announces eth1.

3. The attempt of udev to rename to eth1 fails.

Another possible scenario might be that the renaming happens between the kernel determining the new name eth1 and creating the device (I am not sure whether some preemptive model allows this; I am also not sure what the kernel does  in this case; in any case, I wouldn't want to risk.)

----------

## mv

 *Hu wrote:*   

> Could you cite these discussions?

 

It's the whole discussion about devfs vs. udev: Make simple heuristic rules in kernel or arbitrarily configurable rules in userspace or some half-hearted compromise.

 *Quote:*   

> If other processes see the card come up, then yes, there is a race

 

Surprise, surprise, it is possible to shoot yourself in your foot if you want to.

If you have a process which attempts to interfere with udev's job instead of waiting for udev's announcement of the device, then you can produce a problem.

By this definition, practically every program which does task X would be racy, because you can always write a job which does some sort of opposite to task X and run it simultaneously.

----------

## Drag0nFly

 *mv wrote:*   

>  *Anon-E-moose wrote:*   I swap my eth[01]names, with a udev mac rule. Kernel doesn't care. 
> 
> Yes, as with most races, it is highly unlikely that you get in trouble. (That's why the race was not detected/cared about by ancient udev for years). However, it is a race, and whether you get bitten by it is a matter of luck. On some systems it might happen often and on other systems practically never.
> 
>  *krinn wrote:*   Still clash may appears if you lack a rule for a card 
> ...

 

Greetings Gentoo-ers.

I got hit/bitten by this adorable little issue after upgrading one of my systems (which also booted without gfx due to the i915 driver blanking the display - oh joy! no net+no video  :Razz: ) 

The way udevd did this previously was–

in order to rename eth0 to eth1:

- It renamed eth0 to an intermediate name, rename[n]

- It then renamed eth1 to the - now available - eth0, thus succeeding

- Lastly, it renames rename[n] back to eth1 – also succeeding

And no race-condition should occur, even if both/all interfaces are active before udevd gets to renaming them.

From dmesg:

```
[Wed Sep 11 17:43:12 2019] udevd[58]: starting version 181

[Wed Sep 11 17:43:15 2019] udevd[176]: starting version 181

[Wed Sep 11 17:43:16 2019] udevd[181]: renamed network interface eth0 to rename2

[Wed Sep 11 17:43:16 2019] udevd[184]: renamed network interface eth1 to eth0

[Wed Sep 11 17:43:16 2019] udevd[181]: renamed network interface rename2 to eth1
```

(and yes, older udev version. So shoot me) :Wink: 

Enter eudev 3.2.5 (on exactly the same box, with identical udev rules and NICs used):

```
[   12.605789] udevd[711]: starting version 3.2.5

[   12.675801] udevd[712]: starting eudev-3.2.5

[   15.262743] udevd[743]: Error changing net interface name eth0 to eth1: File exists

[   15.262810] udevd[743]: could not rename interface '2' from 'eth0' to 'eth1': File exists

[   15.320907] udevd[746]: Error changing net interface name eth1 to eth0: File exists

[   15.320982] udevd[746]: could not rename interface '3' from 'eth1' to 'eth0': File exists
```

So, apparently it *first* tries to rename the interface directly, without going the intermediate route, causing it to fail.

It has the hallmarks of a bug to me.

 *krinn wrote:*   

> 
> 
> Another possible scenario might be that the renaming happens between the kernel determining the new name eth1 and creating the device (I am not sure whether some preemptive model allows this; I am also not sure what the kernel does  in this case; in any case, I wouldn't want to risk.)

 

Sorry for digging it up – I've really been wrestling with this issue (which should be a complete *non*-issue for over a day now, and this thread came up as the most enlightened/relevant conversation.

This renaming scheme has worked with numerous kernel versions before, with external USB NIC adapters as well as onboard NICs, without any issue.

----------

## Tony0945

DragOnFly,

Another kludge that worked for me and may work for you.

Use modules and don't load eth1's modules right away. After say a two second delay, load eth1's module. 

This won't work if both used the same module. The instance that I used this had an on-bard Realtek and a PCIe card Intel.

I delayed loading e1000 (or was it e1000e ?).  I also use an old version of OpenRC that loads only the listed modules.

On a later OpenRC you may have to blacklist the second module then load it (and unblacklist?).

IMHO if one blindly loads all modules , one might as well have them built in. On other distros that use a generic kernel with every module built it makes sense, but not for Gentoo.

----------

## Drag0nFly

Thanks for the suggestion; but they both use the same r8168 module. Just out of curiosity, though, how would you implement it? Tweak the initrd scripts?

----------

## Tony0945

Just left the intel driver out of conf.d/modules then loaded it in /etc/local.d/000.start. IIRC, /etc/init.d/net.eth1 was already waiting.

If that doesn't work, try:

```
modprobe e1000

service net.eth1 start
```

 in 000.start

Since both of your NIC's use the same driver, use (e)udev rules based on MAC address.

BTW: I tried Eth0 and Eth1. Didn't work, appears the capital letters aren't legal.

I think you can use nic0, nic1 . I know lan0, lan1 works.

----------

## Anon-E-moose

I have 2 network cards in my box, both 8169, I set names by mac addr.

```
$ cat /etc/udev/rules.d/70-persistent-net.rules 

# This file was automatically generated by the /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 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a1:b3:c1:00:ba:6c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="09:64:6e:87:a3:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
```

----------

## Drag0nFly

 *Anon-E-moose wrote:*   

> I have 2 network cards in my box, both 8169, I set names by mac addr.
> 
> 

 

Which udev variant (and version) are you using? Renaming interfaces based on mac addr (to eth*) does not work with the later udev versions due to namespace

collision.

----------

## Drag0nFly

 *Tony0945 wrote:*   

> Just left the intel driver out of conf.d/modules then loaded it in /etc/local.d/000.start. IIRC, /etc/init.d/net.eth1 was already waiting.
> 
> If that doesn't work, try:
> 
> ```
> ...

 

That would be too late in the process for me, as the local scripts start after firewall, et al. 

But I have to echo the sentiment of the OP - the predictable network interface names was an issue that was already solved. On single-NIC systems it was always eth0.

And in the case of multiple NICs, they were set based on mac addresses (and renaming from eth[x] to eth[y] without issue. 

It does not get more predictable than that. And it was easy and elegant to boot.

----------

## Anon-E-moose

 *Drag0nFly wrote:*   

>  *Anon-E-moose wrote:*   I have 2 network cards in my box, both 8169, I set names by mac addr.
> 
>  
> 
> Which udev variant (and version) are you using? Renaming interfaces based on mac addr (to eth*) does not work with the later udev versions due to namespace
> ...

 

I've heard of name space collision, but never personally seen it. I would try it and see if it works rather than basing it on someone elses opinion. 

You can also use another name rather the eth*. I just had everything on my old system set to speak to eth0 so I kept it (too lazy to change)  :Laughing: 

But if I had to do it over, I'd probably pick nic0, nic1, etc instead of eth*

I use an older version of eudev. And like Tony mentioned earlier, my network driver is module based rather than built in.

Edit to add: this is from my dmesg

```
$ grep -i eth /var/log/dmesg 

[    1.337698] r8169 0000:03:00.0 eth0: RTL8168e/8111e, a1:f6:c1:00:ba:6c, XID 2c2, IRQ 64

[    1.337700] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    1.342232] r8169 0000:0a:00.0 eth1: RTL8168f/8111f, 18:63:6e:87:a3:cd, XID 480, IRQ 65

[    1.342234] r8169 0000:0a:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    1.413800] r8169 0000:03:00.0 eth126: renamed from eth0

[    1.420245] r8169 0000:0a:00.0 eth125: renamed from eth1

[    1.420247] udevd[1964]: renamed network interface eth0 to eth126

[    1.428244] udevd[1972]: renamed network interface eth1 to eth125

[    1.428245] r8169 0000:03:00.0 eth1: renamed from eth126

[    1.436306] r8169 0000:0a:00.0 eth0: renamed from eth125

[    1.436314] udevd[1964]: renamed network interface eth126 to eth1

[    1.446230] udevd[1972]: renamed network interface eth125 to eth0
```

----------

## Drag0nFly

 *Anon-E-moose wrote:*   

>  *Drag0nFly wrote:*    *Anon-E-moose wrote:*   I have 2 network cards in my box, both 8169, I set names by mac addr.
> 
>  
> 
> Which udev variant (and version) are you using? Renaming interfaces based on mac addr (to eth*) does not work with the later udev versions due to namespace
> ...

 

There seems to be some misunderstanding, *I am* renaming the network interfaces via /etc/udev/rules.d, based on mac address, exactly as you are.

All my drivers are module-based, nothing is built-in.

As I posted earlier, this works on udev (181), but not with recent eudev (3.2.5) versions using identical rules and on an identical system. I also mentioned I was renaming eth0 to eth1 and

vice-versa.

If you are running a prior version of eudev which might not have this issue, it would be very useful to have the version number for testing,

which is why I asked.

To me it looks like eudev (or later versions at least) is skipping the intermediate renaming step, causing it to fail if an identically-named interface is already active.

----------

## Anon-E-moose

The version I run is very old 1.10, but still works, so I haven't been tempted to update. I just copied the ebuild to my local repo and masked versions beyond it.

Are you running the newer version with the rule-generator use flag turned on? (it affects network and cdrom persistence)

----------

## Hu

If I recall correctly, upstream udev declared that renaming an interface to a kernel name was an unsupported configuration and demanded that users not do that.  I vaguely recall there may have been a version that artificially failed at renaming to a kernel-style name, just to be very pointed about how unsupported it was.  Although mostly theoretical, there is a race condition even in the version that danced through the extra name to make your configuration work.  Suppose the following sequence of events:No network cards exist, because no kernel drivers for the installed cards are active.The kernel activates an interface, and names it eth0.udev notices this and renames it to rename0, in preparation to become eth1.udev is preempted.  The kernel activates two more network interfaces, naming them eth0 (because that is free again) and eth1 (next in sequence).udev resumes executing.  udev tries to rename rename0 to eth1 per your rule.  This fails, because a new card took that name in the interim.  Due to event ordering, udev has not yet renamed the new eth1 out of the way to make room for rename0.The only safe approaches are (1) don't rename cards at all, or (2) don't rename a card to a name that may get created as a result of an external event.

----------

## Anon-E-moose

 *Quote:*   

> udev is preempted. The kernel activates two more network interfaces, naming them eth0 (because that is free again) and eth1 (next in sequence).

 

Is that the way the kernel works or does it keep track of the last name used (internally)? I don't know I've never looked at that portion of the kernel code, thus my question.

I do agree that the truly "safe" way, if you're going to rename, is to use a non-kernel name, ie nic, wired, etc.

----------

## Drag0nFly

 *Hu wrote:*   

> If I recall correctly, upstream udev declared that renaming an interface to a kernel name was an unsupported configuration and demanded that users not do that.  I vaguely recall there may have been a version that artificially failed at renaming to a kernel-style name, just to be very pointed about how unsupported it was.  Although mostly theoretical, there is a race condition even in the version that danced through the extra name to make your configuration work.  Suppose the following sequence of events:No network cards exist, because no kernel drivers for the installed cards are active.The kernel activates an interface, and names it eth0.udev notices this and renames it to rename0, in preparation to become eth1.udev is preempted.  The kernel activates two more network interfaces, naming them eth0 (because that is free again) and eth1 (next in sequence).udev resumes executing.  udev tries to rename rename0 to eth1 per your rule.  This fails, because a new card took that name in the interim.  Due to event ordering, udev has not yet renamed the new eth1 out of the way to make room for rename0.The only safe approaches are (1) don't rename cards at all, or (2) don't rename a card to a name that may get created as a result of an external event.

 

This seems to be mostly theoretical. On all my systems either at work or at home; be it clients or servers with two or more NICs; many in riser cages, I've never seen network interfaces being activated immediately after udevd is invoked. They are consistently activated early during boot unless one has tweaked either initrd or blacklisted network modules, to be manually inserted later with the local.d approach mentioned earlier in the thread. But maybe I am the odd man out(?)

To me, this whole "demanding" of users to redo all their configs, due to a theoretical race condition does not make sense.

But again, from what eudev is actually printing to the kernel ring buffer when trying to rename the interface vs. the behavior with the old (pre-systemd) udev, it seems like the intermediate rename[n] step is omitted. Was this removed due to this apparent race condition?

Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this. A better way would obviously be for the kernel itself to name the interfaces with the new, long names, and then one could rename (with udev) to whatever one wants once the actual names are known. But I suppose this was done to reduce bloatness on the kernel-side.

----------

## Tony0945

DragOnFly,

The race condition is real. More than ten years ago I had a Tyan mobo with two built in NIC's. They mostly came up in a predictable order, but about one time in ten to 15 (i.e. once in two weeks), they would be reversed. This occurred with Windows also. With Windows (Win2k at that time), I could just reach over and pull the ethernet plug and plug it in the other slot. Linux, I would reboot usually getting the right one.  I think we had hal instead of udev at that time.

Eventually, I configured both eth0 and eth1 and connected them to the four port switch to my wireless bridge. Obviously, that works for only the most primitive ethernet work, but I tell the story to show that the race is real, but mostly predictable and existed on Windows as well.

The module loading delay trick was used on a different machine two years ago. I used eudev-1.10, the same as Anon-a-Moose.

Today, I have the same eudev installed to satisfy portage requirements for other packages but never launch the service. I use mdev as a hotplug agent and that suffices for mounting USB sticks. That brings up the question of whether udev is really needed by those other packages. 

```
MSI ~ # equery d udev

 * These packages depend on udev:

app-emulation/virtualbox-6.0.12 (udev ? >=virtual/udev-171)

net-print/hplip-3.18.12 (kernel_linux ? virtual/udev)

sys-apps/hwids-20190316 (udev ? virtual/udev)

sys-block/gparted-0.33.0 (hfs ? virtual/udev)

sys-fs/udev-init-scripts-27-r1 (>=virtual/udev-180)

virtual/dev-manager-0-r2 (virtual/udev)

MSI ~ # equery d udev-init-scripts

 * These packages depend on udev-init-scripts:

sys-fs/eudev-1.10-r3 (openrc ? >=sys-fs/udev-init-scripts-26)

```

 (e)udev has become a hodge-podge of diverse code thrown together with no apparent design process. Indeed, I recently discovered that although udevd.c, the actual netlink socket daemon is in the package but never compiled!   From talk on the internet, it appears that instead of using a well-designed kernel mechanism, so brain-dead hacker decided to just have a loop that sleeps and wakes up and asks "did anything happen?" scouring the whole device tree repeatedly, a "design" that makes me want to vomit.

----------

## Drag0nFly

 *Tony0945 wrote:*   

> DragOnFly,
> 
> The race condition is real. More than ten years ago I had a Tyan mobo with two built in NIC's. They mostly came up in a predictable order, but about one time in ten to 15 (i.e. once in two weeks), they would be reversed. This occurred with Windows also. With Windows (Win2k at that time), I could just reach over and pull the ethernet plug and plug it in the other slot. Linux, I would reboot usually getting the right one.  I think we had hal instead of udev at that time.
> 
> Eventually, I configured both eth0 and eth1 and connected them to the four port switch to my wireless bridge. Obviously, that works for only the most primitive ethernet work, but I tell the story to show that the race is real, but mostly predictable and existed on Windows as well.
> ...

 

It does not sound to me like you were encountering the race condition, rather that you had the kernel simply switch the interfaces around, which is why I use the rules in /etc/udev/rules.d/10-network.rules to rewrite in the first place. It would be catastrophic if the power went out, and it booted in reverse order, as this has consistently happened with me on the other side of the planet. (and yet, the box has always recovered thanks to the mac address lock)

Did you have similar output from udev suggesting it was renaming to an interface which already existed? Look at the dmesg code I posted earlier, there is a clear difference with how udev 181 and eudev 3.2.5 behaves.

The system I encountered this issue on has been through upwards of 10 major kernel releases (over 10 years). And it has never - ever - had an issue with renaming the interfaces - even when using an external usb-3 GbE interface. That is, until eudev showed up...

 *Tony0945 wrote:*   

> 
> 
> ```
> MSI ~ # equery d udev
> 
> ...

 

I can certainly believe that. I was thinking of manually compiling it after I checked if the renaming section was similar (or identical) to recent udev versions.

Not sure how much trouble there'll be by running a (now-ancient) udev version on a new system. Although, it would be fun to try as recent changes are not always for the best.

----------

## Hu

 *Anon-E-moose wrote:*   

>  *Quote:*   udev is preempted. The kernel activates two more network interfaces, naming them eth0 (because that is free again) and eth1 (next in sequence). Is that the way the kernel works or does it keep track of the last name used (internally)? I don't know I've never looked at that portion of the kernel code, thus my question.

 I checked the kernel code before posting my prior message.  As I read it, it always uses the lowest free number, even if that number only recently became free.  I base my conclusion on the implementation in net/core/dev.c:__dev_alloc_name.  There is even a dance using sscanf / snprintf to keep the numbering of different groups separate, so that a wlan0 does not prevent getting an eth0. *Drag0nFly wrote:*   

> To me, this whole "demanding" of users to redo all their configs, due to a theoretical race condition does not make sense.

 The udev maintainers have made questionable decisions before.  This one actually seems fairly reasonable, if a bit heavy-handed.  If the feature cannot work reliably, it should not work at all.  Unpredictable renaming of interfaces to the predictable names is worse than declaring the setup broken and forcing people to move to something more reliable.  I would rather go through the one-time pain of migrating to a consistently functional setup than deal with an environment where there is always a small question of whether the next reboot will transpose the devices. *Drag0nFly wrote:*   

> But again, from what eudev is actually printing to the kernel ring buffer when trying to rename the interface vs. the behavior with the old (pre-systemd) udev, it seems like the intermediate rename[n] step is omitted. Was this removed due to this apparent race condition?

 I don't know why it was removed.  If I were to guess, it would be because it's extra unnecessary work when your names are not racy, and it's unreliable when they are racy. *Drag0nFly wrote:*   

> Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this.

 Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended.  Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them.  Make them ethe and ethi (external/internal), for example.

----------

## Anon-E-moose

 *Hu wrote:*   

>  *Drag0nFly wrote:*   Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this. Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended.  Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them.  Make them ethe and ethi (external/internal), for example.

 

For me, I went to mac addr re-naming because the kernel wasn't consistent on which of my 2 8169 interfaces would be eth0 and eth1. Even when they were both driven by the same kernel module. As I stated earlier I've never had a problem since I've started using the mac addr, but it's a server that stays up 24x7, so it's bounced less that a 5-10 times a year, which cuts down on the chances of conflict.  

Oh and thanks for the clarification on the kernel stuff.

----------

## Drag0nFly

 *Anon-E-moose wrote:*   

>  *Hu wrote:*    *Drag0nFly wrote:*   Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this. Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended.  Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them.  Make them ethe and ethi (external/internal), for example. 
> 
> For me, I went to mac addr re-naming because the kernel wasn't consistent on which of my 2 8169 interfaces would be eth0 and eth1. Even when they were both driven by the same kernel module. As I stated earlier I've never had a problem since I've started using the mac addr, but it's a server that stays up 24x7, so it's bounced less that a 5-10 times a year, which cuts down on the chances of conflict.  
> 
> Oh and thanks for the clarification on the kernel stuff.

 

Yep, sounds like you're in exactly the same boat as me then. I came to rely on this renaming due to the problem of having the NICs reversed. Actually, I spent a significant amount of time preparing all the other stuff on the machine - migrating firewall, mail (spam), crypto setup and numerous other packages only to find that the one thing which had never before been an issue nixed the effort completely due to the udev changes. 

Well, there's always something no matter how well-prepared you think you are.  :Wink: 

----------

## Drag0nFly

Just to follow up on my original issue and in case any others are in the same or similar situation:

I was finally able to test this properly (the box on which I am running it is my main server, gateway and firewall – which is also running a number of other services), so any downtime is always extremely inconvenient. In any case, I've tested it in various configs and kernels now, using the same eudev version (3.2.5), compiled with '--enable-rule-generator' (USE=rule-generator) and found that the network interface renaming works in a variety of different configurations;

- Using 2x on-board RTL8168d/8111d NICs (eth0+eth1) using the r8169 driver

- Using the same on-board RTL NICs + a USB NIC in addition (using ax88179_178a module; renamed to eth1), existing on-board NIC renamed to eth2

- Using only 1x on-board Realtek NIC (second BIOS-disabled) + USB ax88179 NIC

No matter how these are switched around I have not been able to cause it to fail by running into the race condition. (This is on an Atom-powered digital signage system which boots and initializes hardware pretty fast.)

```

[   16.855247] r8169 0000:02:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17

[   16.886636] r8169 0000:02:00.0 eth0: RTL8168d/8111d, 00:.., XID 283, IRQ 27

[   16.886644] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[   17.429855] ax88179_178a 1-4:1.0 eth1: register 'ax88179_178a' at usb-0000:00:1d.7-4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:...

[   17.429984] usbcore: registered new interface driver ax88179_178a

[   17.572977] gpio_ich gpio_ich.1.auto: GPIO from 462 to 511

[   17.584738] iTCO_vendor_support: vendor-support=0

[   17.631256] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

[   17.631338] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x0860)

[   17.634402] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[   17.652220] intel_rng: FWH not detected

[   17.701952] leds_ss4200: no LED devices found

[   17.995873] r8169 0000:02:00.0 eth126: renamed from eth0

[   18.007701] udevd[649]: renamed network interface eth0 to eth126

[   18.069504] ax88179_178a 1-4:1.0 eth125: renamed from eth1

[   18.084622] udevd[654]: renamed network interface eth1 to eth125

[   18.084698] ax88179_178a 1-4:1.0 eth0: renamed from eth125

[   18.098928] udevd[654]: renamed network interface eth125 to eth0

[   18.110211] r8169 0000:02:00.0 eth1: renamed from eth126

[   18.111470] udevd[649]: renamed network interface eth126 to eth1

```

Thanks to @Anon-E-moose for suggesting the rule-generator flag. (I also dove into the source-trees and diffed this until I backtracked this thread so could have saved some time.. :Wink: 

I would include more examples of the bootup with additional kernel-named, and subsequently eudev-renamed eth[x] devices, but syslog-ng has also decided in its wisdom *not* to log dmesg output any longer to /var/log/everything.log with the 3.6.x branch unless one is using systemd... (yay!) Now to find a fix for that as well.

----------

## mgnut57

Just to follow up, as the original poster.

I just rebooted for the first time since the thread started. Naturally in the intervening time, there have been many updates to world, but also I booted into a new kernel. 

Everything worked as it was supposed to. My interfaces were renamed as configured and I did not have an interface called "eth0". Of course this broke many other configurations, which had to be changed from "eth0" to "internet0". "ifconfig -a" still shows the "ip_vti0" interface:

```
ip_vti0: flags=128<NOARP>  mtu 1480

        tunnel   txqueuelen 1000  (IPIP Tunnel)

        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
```

This was consistent across both a reboot and a cold start.

----------

