Network interfaces suddently renamed after reboot.

[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, 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]

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]

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.

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/ ... 06066.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]

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]

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

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. I figured there had to be somebody out there.

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"?

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?

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.

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:

Code: Select all

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

Code: Select all

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

Code: Select all

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

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.

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]

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.

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]

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.

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.

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 )

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:

Code: Select all

[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);)

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

Code: Select all

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

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:

Code: Select all

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.

Code: Select all

$ 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]

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]

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:

Code: Select all

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.

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]

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.

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

Code: Select all

$ 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]

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.

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

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]

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]

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.

Code: Select all

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]

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.

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

Code: Select all

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.

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.