predictable network interface names

[dbishop]

@py-ro:

I beg to differ. Replacing a NIC involves more than just plugging it in. There's the obvious issue of breaking down the hardware to install or replace the NIC. And with the new naming scheme you have to put the new card in the same slot. And if you've availed yourself of the MAC naming which seems to be in the new scheme very prominently, well, then, oops.

This is not xenophobia. There are real fundamental logic flaws in all this:

Logic Flaw #1. If you add a NIC, all bets are off since the new card may be earlier in the PCI slot numbering scheme than desirable. This is what has happened to me. You may find that default behaviour is seriously altered and things don't work -- exactly the disaster scenario you said this prevents.

Logic Flaw #2: If you add a new card, you have to add the new driver (unless you've built them ALL preemptively into the kernel, just in case, like Windows does...). So it's never just plug-and-play.

Logic Flaw #3: Writing one line to a list of two or three other udev-rules is inferior to rewriting iptables rules, routing tables, and whatnot to override default behaviour and preserve the ideal that interface numbers derived from the hardware bus (somewhat random itself) is better than a fixed algorithm that numbers them.

Logic Flaw #4: That if the interface name remains the same, nothing can happen that will make a working configuration fail if new hardware is added or old hardware is changed. Anyone who thinks that should immediately one giant step back from their keyboards. They are not qualified.

I have three or four more, but I am tired now. Absent a sane way to order the interface-up sequence in net.whatever, I am going back to my aptly-named sysinit-level runscript called fixudevnightmare and go back to calling everything eth*. This is udev megalomania just ridiculous.

[dbishop]

@py-ro:

Sorry, but can't you just define the order/dependencies in /etc/rc.conf?

Ah perfect! If this is so, please advise how! That's all I was asking!

[Anon-E-moose]

One can copy udev-171-* to the local portage tree (include virtual/udev-171) and
mask anything beyond it.
*Needs to be put in the local portage tree as it is slated for removal by the gentoo devs *

A/o right now, I have udev-171-r6 installed and it is working fine with kernel 3.8.5

Note: Yes, I'm aware that udev-171* might stop working in the future,
but I have no guarantees that udev-19*/udev-20* won't do the same.

[miket]

One can copy udev-171-* to the local portage tree (include virtual/udev-171) and
mask anything beyond it.
*Needs to be put in the local portage tree as it is slated for removal by the gentoo devs *

A/o right now, I have udev-171-r6 installed and it is working fine with kernel 3.8.5

Note: Yes, I'm aware that udev-171* might stop working in the future,
but I have no guarantees that udev-19*/udev-20* won't do the same.

That's the place to be until/unless someone "helpfully" pulls it from the tree.

Then we'd be up a tree.

[py-ro]

@py-ro:

Logic Flaw #1. If you add a NIC, all bets are off since the new card may be earlier in the PCI slot numbering scheme than desirable. This is what has happened to me. You may find that default behaviour is seriously altered and things don't work -- exactly the disaster scenario you said this prevents.

K, give you that.

Logic Flaw #2: If you add a new card, you have to add the new driver (unless you've built them ALL preemptively into the kernel, just in case, like Windows does...). So it's never just plug-and-play.

In most cases you will use a specific set of cards and won't mix too much chips up, atleast we don't do this. We keep a stock of two kinds of cards.

Logic Flaw #3: Writing one line to a list of two or three other udev-rules is inferior to rewriting iptables rules, routing tables, and whatnot to override default behaviour and preserve the ideal that interface numbers derived from the hardware bus (somewhat random itself) is better than a fixed algorithm that numbers them.

There was no fixed algorithm to number them, the new mechanism is not perfect, but less random then the oldone IMHO.

Logic Flaw #4: That if the interface name remains the same, nothing can happen that will make a working configuration fail if new hardware is added or old hardware is changed. Anyone who thinks that should immediately one giant step back from their keyboards. They are not qualified.

Sure you can break any system by changes, intended or not, but in most cases you won't do too much changes on a production system, atleast you should not, same reason as mentionend.

I have three or four more, but I am tired now. Absent a sane way to order the interface-up sequence in net.whatever, I am going back to my aptly-named sysinit-level runscript called fixudevnightmare and go back to calling everything eth*. This is udev megalomania just ridiculous.

We were naming our Interfaces by function with our own naming scheme way before and nobody prevents anybody to ommit the change or do his own thinggy.

EDIT: Fixed quoting

[miket]

We were naming our Interfaces by function with our own naming scheme way before and nobody prevents anybody to ommit the change or do his own thinggy.

Ah, that's the sane way to use names other than eth0; the new "predictable" pattern is in fact unpredictable. Your organization has gone with a predictable pattern. Good for you. You didn't need new udev to do it.

[dbishop]

@py-ro:

My original post here included this:

I was thinking the answer would be in something like RC_NEED=... (or some such) put some where that provoked the Gentoo start scripts to call the new names in a specific order.

Clearly, I have been asking this all along. Many, many innocent database bytes could have been spared if we didn't get mired in udev-mania. *sigh*

@Anon-E-moose
I also wrote this a little later on:

As I have read all these threads several times (and had even masked >udev171 until just recently in silent protest) it is clear to me that something like 70-persistent-net.rules is really the only way.

It's bizarre how simple the question I asked really was, and that all this is because I have been trying to "go along to get along" with all the new udev naming nonsense. It is clear that the new 'persistent names' idea was ill-conceived, poorly designed, even more poorly pushed out, and then in the end achieves none of its original design goals. Rather, it's wreaked havoc.

Here's a clue: Changing hardware necessitates changing software, since software is the final customization of the hardware. It is definitional. Writing tons of complicated preemption code that expects to anticipate every imaginable permutation and change so that the "idiot end user" is relieved of the burden of thinking is both foolishness and recklessness. Anyone software engineer who believes otherwise should change careers. It is hubris and elitist at its most off-putting level.

Maybe we should just call it "Obamacare for Linux".

[dbishop]

@py-ro:

I have no desire to keep bickering. I really would prefer if you know what I should put in rc.conf, please just tell me. Or tell me where to go look to figure it out myself.

But, because I can't resist the fun:

First, my machine that this happened to was/is a production machine. I didn't change a thing nor did I want to. The new udev and the kooky persistent naming thing broke it, not any change I made. I have simply been cleaning up the mess it made.

Second, you are a little off-center when you write that everyone should use two NIC types. Which two? Your two? Are you kidding? I guess we'd better tell the hardware guys we only need two from now on, thanks.

Third, while it is true, I could never predict what would be eth0, eth1, etc until each machine started for the first time, they never ever changed. therefore it was not difficult using udev rules to make them whatever I wanted them to be, and they never changed either. So saying that there was no one fixed algorithm, you are wrong. Every combination of hardware gave consistent and repeatable numbering. And then it never changed unless I changed the hardware, and in that case making it back into exactly what I wanted was equally simple and straightforward. I don't know what all the persistent-name zealots are drinking, but this was clearly much more predictable and much more controllable that this new mess.

Fourth, what could be more ironic than a system that calls itself "persistent naming" than one that presents you three, or four, or five to choose from? And as I wrote earlier, one of the choices is based on mac addresses! Do you have only two mac addresses to choose from too? You are killin' me...

Fifth -- I could not care less what interfaces are named (in theory). My issue is that the cards are not being named in an order that brings them up in a way allows me to use default routing algorithms. With things this "new better way" is forcing me to write a ton of routing rules in post-up patches. It has nothing to do with calling them by names that tickle me. Subverting this issue is allowing everyone to trot out all these strawman arguments and misdirect for whatever reason. I am really just trying to control which interface comes up first, second and third in the boot process. It used to be easy, now it's a nightmare.

I don't know how to be more clear or more logical.


I could go on, but I have a machine to fix...

[miket]

With apologies to Johnny Cash.

Code: Select all

I see the train a-coming
It's coming round the bend
Hey! It's on the same track I'm on
Don't tell me it's the end!

I'm cruising to disaster
On this udev-using line.
I'm gonna get myself of this track
While I still have the time.

[Anon-E-moose]

Calling the new way predictable is somewhat true, calling it persistent isn't.

If I change slots or in the case of usb adapters, a port, then the name changes, maybe predictable, but certainly not persistent.

The old way ala 171 was to use the mac addr, not necessarily predictable but persistent,
if I changed slot or usb port it would still see the mac addr.

Under 171 I could have named my device don0, don1, etc.
The same as I can now. So no real benefit in the new way over the old.

Under the old way, if I only had one card, then I got eth0 and it worked without the need to ask why or try and change my firewall rules,
and other scripts that depend (by default) on eth0.

Yes under the old way, if I changed cards because the one I had died, then I had to modify the rules, as the mac addr changed
the same thing holds true under the new one (supposedly putting a new/different card) in the same slot yields the same name,
but AFAIK that's anecdotal, not tested.

So the end result is tons of brouhaha, many threads started, and much angst over something that should never have been an issue.
End result lots of pain, hardly any gain.

JMHO

[mv]

You would have to convince Linus, probably several other kernel developers, Sievers and Poettering. Good luck

Poettering, at least, is not a kernel developer. Thank God.

It was meant as an enumeration: You have to convince four (groups of) people who are usually very hard to convince. In theory, this might be possible, in practice your suggestion is already doomed.

[Aiken]

Keep in mind this also affects usb networking gear. One thing that had been nice about usb was plug a device into a free port and start using it. With the new naming scheme depending on what is being done things like hostapd, wicd and firewall scripts could be broken multiple times a day. The annoying bit is having to take extra steps to get back the old and (for me) predictable behaviour.

[depontius]

Having watched and been annoyed by this whole thing since it started, something finally crystallized in my mind a few moments ago...

The only truly stable thing about network devices is the MAC - period.

I hadn't realized until seeing other entries here that the PCI ID of one card could change based on other cards being plugged in, and hadn't thought through that scenario for USB, but there it's more obvious.

Given that, calling anything "persistent and predictable network device names" based on anything but the MAC is just plain wrong, and never had a chance of being right, at least not until those screws on the case are replaced by a lock and the USB ports expoxied.

[mv]

The only truly stable thing about network devices is the MAC - period

And this is not stable, either: I remember many angry comments in the beginning of udev when people expected eth0/wlan0 to remain when they had only one device and exchanged this device by another (with another MAC, of course). In a sense, these people were right: If there is only one device, connected in the same way as previously, why should it have another number?
I am afraid that there is not universal solution which works in all use cases... simply the idea of persistency and hotplug capability contradict each other.
This is why I consider the net*/wnet* solution the best: You can adapt it to your needs by writing your own rules. E.g. if you know that you will never have anything else than your eth0 in a pci slot, you can just hard-encode that eth* from pci should be named net0, and if you know that you will never have more than one wlan in an usb port you can hard-code that wlan* from usb should be names wnet0.

[depontius]

Until you replace the network card, the MAC is stable. What others have been saying is that with the current default, changing other hardware can cause the network device name to change. I agree that using the MAC changing the network card would change the device name, but at least changing the sound card won't.

[dmpogo]

Until you replace the network card, the MAC is stable. What others have been saying is that with the current default, changing other hardware can cause the network device name to change. I agree that using the MAC changing the network card would change the device name, but at least changing the sound card won't.

But, for this discussion, MAC has an opposite problem - it is TOO specific. That is, there is no chance that your script will work on another, even identical, machine without modification, if it is based on MAC address (*) Basing network interface name on MAC essentially equates the two - imagine firewall rules with hardcoded MAC - that's what you'll get. In essence you are hardcoding manufacturers serial numbers. And the point of network interface names is actaully to provide some level of abstraction from being purely hardware descriptors.

(*) it make me shiver to think of a class of 100 identical desktops where one would need to adjust scripts for every single one.

[depontius]

On another thread I suggested that, wrapped in udev syntactic sugar, we needed a mapping of network MACs to device names, done kind of like the "good old way", or at least what I remembered as the good old way for /dev/dvd and /dev/cdrom - I never got that involved with networking - until udev-200. The first boot with a new piece of hardware would add a line to a different rule giving persistent names.

With that kind of sceme we could have our eth0, eth1, wlan0, etc, and as long as that card remained, it would get its name - in spite of any other plugging and unplugging.

[miket]

But, for this discussion, MAC has an opposite problem - it is TOO specific. That is, there is no chance that your script will work on another, even identical, machine without modification, if it is based on MAC address (*) Basing network interface name on MAC essentially equates the two - imagine firewall rules with hardcoded MAC - that's what you'll get. In essence you are hardcoding manufacturers serial numbers. And the point of network interface names is actaully to provide some level of abstraction from being purely hardware descriptors.

(*) it make me shiver to think of a class of 100 identical desktops where one would need to adjust scripts for every single one.

Actually, this is where basing things on the PCI address makes more sense: rather than trigger the udev rule on the specific MAC address, one could go simply with device class and PCI slot--or even a small range of slots. This would have trouble, of course, if there are multiple NIC's of the class which have different roles: you might be back to MAC addresses, or you could go in the direction of making a rule like "LAN-facing NIC's go into slot 0 or 1 and WAN-facing NIC's go into slot 2 or 3".

This makes life *much* happier if you are provisioning bunches of hosts.

Don't mistake this for any advocacy for names of the insane pattern enpXxsYY. The target names ought to be of patterns like lan0, wan0, or, drum-roll, eth0. That makes things much better for other software in the system, including init scripts.

[gentoo_newguy]

Hi guys im really stuck reading through this it just makes no sense to me .

is there a simple way to have my network devices back to how they were

i have tried net.ifnames=o on the command line and that is not working.

wpa_supplicant is giving me some weird error when trying to start

lots of ioctil[siociwpmksa] invalid arguments going on

any ideas what this is ??

[mv]

With that kind of sceme we could have our eth0, eth1, wlan0, etc, and as long as that card remained, it would get its name

No, it wouldn't, at least not reliably: udev would have to rename eth* to another eth* (depending on the previous rules and on the order in which the kernel initializes the drivers) - which is what udev did before but which is subject to a race condition: While udev is renaming the kernel could want to add the same device. If you want it in such a way, but reliably, you would still need to rename to e.g. net* which is not in danger to interfere with kernel names.
That being said, if you want to keep the automatic persistent-* generation you can have it if you switch to eudev instead of udev.

[khayyam]

is there a simple way to have my network devices back to how they were

gentoo_newguy ... yes, don't use udev use the eudev package. By *default* eudev keeps the old naming convention, and allows you to use the new naming schema if you so wish. Otherwise, read all the threads, news items, upgrade guides, etc, symlink what-have-you to /dev/null, write some udev rule ... take your pick.

i have tried net.ifnames=o on the command line and that is not working.

I imagine this should be a "0" (zero, naught) and not an "o" (ohhhwww), and when you say "command line" you do mean passed to the kernel (ie, via grub, or you bootloader)?

wpa_supplicant is giving me some weird error when trying to start lots of ioctil[siociwpmksa] invalid arguments going on, any ideas what this is??

Sounds as though wpa_supplicant is passed a interface name as a parameter that it can't translate into an actual device.

best ... khay

[gentoo_newguy]

Solved the ioctil[siociwpmksa] invalid arguments by switching my wifi switch on and off

how do i switch from udev to eudev ?

Afriad i didnt mean passed to the bootloader im guessing thats where it needs to be ? and yes u were correct i was trying a 0 and not o

This is so confusing

[John R. Graham]

I'm actually going to try this tonight. Since virtual/udev is satisfied by any of udev, systemd, and eudev, it should be approximately as simple as this:

• Keyword eudev.
• Unmerge udev. Don't reboot until you...
• Emerge --oneshot eudev.

- John

[gentoo_newguy]

After hours of playing i have finally fixed this problem .

Adding the net.ifnames=0 to the kernel command line changes the devices back to normal

I did a

Code: Select all

 rc-update add net.wlan0 default 

but i have to manual type dhcpcd wlan0 to get an ip hwo can i start this automatically ?

[khayyam]

how do i switch from udev to eudev?

gentoo_newguy ... John's pretty much covered it above. By default the "rule-generator" useflag is set and this will provide an init "udev-postmount" you then add this to the default runlevel.

Code: Select all

# rc-update add udev-postmount default

Thats about all there is to it ... all the information is provided in the einfo from the package merge, so you'd then restart udev and/or reboot. Your interfaces should then be eth0/wlan0 on boot.

best ... khay