My server is double-homed, with eth0 and eth1. Obviously it matters which is named first, and which is named second. In fact, this happened a few years ago with a kernel upgrade, and I spend a bit of time then learning about ARP and that layer, at that time. I swapped network connectors, so that eth0 continuted to point inside, and eth1 pointed outside.

I used udevadm and find that in "the new regime" my cards are still correctly sequential. If I let it change, eth0 becomes enp2s10 and eth1 becomes enp2s11. So it sounds to me as if I can do nothing, and after the next reboot my network will be OK.

Is that a correct estimation?_________________.sigs waste space and bandwidth

Yes, except that you will need to change all references to eth0 and eth1 (in any configs, scripts, firewall rules, etc).

Ssuominen: I've been flipping back and forth between udev and eudev testing, and FYI, about an hour ago I emerged udev and got no 80-net-name-slot.rules dummy file in etc/udev. I had removed my /etc/udev directory, and did an emerge --noconfmem udev to confirm this.

Maybe it was just me, but I'd hats to see you get inundated by a thousand "what happened to my network" questions. I assume that dummy file is still supposed to be installed by default, for the time being?_________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

Yes, except that you will need to change all references to eth0 and eth1 (in any configs, scripts, firewall rules, etc).

Ssuominen: I've been flipping back and forth between udev and eudev testing, and FYI, about an hour ago I emerged udev and got no 80-net-name-slot.rules dummy file in etc/udev. I had removed my /etc/udev directory, and did an emerge --noconfmem udev to confirm this.

Maybe it was just me, but I'd hats to see you get inundated by a thousand "what happened to my network" questions. I assume that dummy file is still supposed to be installed by default, for the time being?

If udev isn't installed then udev-197-r4 and 9999 will not copy the file in place. These versions/revisions of udev will stay in ~arch for time being.
The stable udev-197-r3 always copies the file if it isn't there already.

That's the current main difference of -r3 and -r4. When -r4 or higher is about to be stabilized, it will then be converted to be like -r3 is now.
I suspect udev-197-r4 (or 198) to be next stabilization target after 197-r3 stabilization is done. Then -r4 gets bumped to -r5 and -r5 will
be like current -r4.

To clarify:

New users of ~arch udev -> New networking scheme
Old users upgrading in ~arch -> The file is copied into place if not already there
New users of stable -> The file always gets put in place, if it isn't already there

So if you `emerge -C eudev` and `emerge -1 udev` then it will think you are a new user and you get the new networking scheme.

I have a 3 interface router, but it's stable branch (and has the dummy file). I'm trying to figure out how to handle the renaming, since there are many references to the interface names. I think I can prepare by using variables in place of hard coded interface names in many places. Or I can add a rules file to rename them to logical names.

Actually, now that I think about it, the firewall rules already use logical names (variables); maybe there aren't as many references as I thought._________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

Yes, except that you will need to change all references to eth0 and eth1 (in any configs, scripts, firewall rules, etc).

Well for this round I was hoping to not allow the rename to happen. I don't know exactly where I have used eth0 and eth1, besides the net config and firewall. But since the new collating sequence is the same as the old collating sequence, I was asking if the names would still come out in the same order.

In essence, do I have to do anything at all besides reboot.

I don't think that this naming thing is all done. I think the first time Linus reboots his system and finds it broken, because a 30+ year old naming convention has been ignored, he's not going to be happy, and very loudly._________________.sigs waste space and bandwidth

I'm kind of irritated by the whole "early userspace" thing. It smacks of kludge to me. Also, a lot of the freedesktop.org stuff seems narrow-minded in terms of use cases, and it seems to lack modularity (too many things that try to be the center of the world, cascading networks of unnecessary dependencies, not enough planning and too much thrashing, etc.). Woe is me. _________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

I'm kind of irritated by the whole "early userspace" thing. It smacks of kludge to me. Also, a lot of the freedesktop.org stuff seems narrow-minded in terms of use cases, and it seems to lack modularity (too many things that try to be the center of the world, cascading networks of unnecessary dependencies, not enough planning and too much thrashing, etc.). Woe is me.

I'll partly agree with you. I've complained here and other places that freedesktop.org looks like people trying to bring the Windows "Just Works (TM)" philosophy to Linux. In other words, the Just Works, except when it doesn't, and when that happens, the ability to hack your way to a working solution is gone - you need expert help. I remember the old days of hacking xf86config - a bit of a pain, but with some reading of the documents I managed, and was able to learn just enough to get my systems working and displaying. In the Just Works age, it's easier to get your system working - most of the time. But if it doesn't work, the fixes are harder, perhaps impossible, to just puzzle out, and far more esoteric.

As for early userspace, I think it has always been with us, it's just worse now. In the old days, the root partition was early userspace, with /bin, /sbin, /lib, etc. The stuff on root had enough capability to then mount /usr, /home, etc in more complex ways, like on nfs or RAID. Now people are wanting root itself to be on more sophisticated hardware, beyond the ability of the kernel itself to handle, hence the new early userspace and initramfs or initrd. That's all that's really happening, along with the desire to become more modular, etc._________________.sigs waste space and bandwidth

Quick note... I just rebooted my dual-homed server, and eth0 and eth1 both came back correctly. Because the "new way" was going to enumerate them in the same sequence, I had some hope that this would happen. At the same time, someone else reported eth0 and eth1 turning into eth1 and eth2, so there was a little fear, there. I left the commented "80-net-name-slot.rules" file in place, to prevent the new naming convention from kicking in. I also had an old "70-persistent-net.rules", so I don't know if it continued to name the network devices, or if they naturally came out as they did._________________.sigs waste space and bandwidth

Even so, I'm not sure why the initscript is giving the error message "ERROR: ethtmp failed to start". What am I doing wrong?

Use the latest script from https://bugs.gentoo.org/show_bug.cgi?id=453494 because it was improved in a way it's less error prone. You still have to edit it for others than eth*
The copy you were using failed if the value that is now {0..9999} in the script didn't match the amount of interfaces to rename, like with three NICs it would be {0..2}, as in 0, 1 and 2.
Delete the old copy.

I have left the contents of /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules the same as listed in my previous post. Using the new version of the initscript in Gentoo Bugzilla Bug Report No. 453494 as a template I have now created an initscript /etc/init.d/rename_ethX containing:

As there is no apparent difference in interface naming, is the initscript serving any useful purpose? Is it not sufficient just to rely on /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules?_________________Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.Fitzcarraldo's blog

As there is no apparent difference in interface naming, is the initscript serving any useful purpose? Is it not sufficient just to rely on /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules?

If you remove the init script and 70-persistent-net.rules and 80-net-name-slot.rules from /etc and switch to the new networking name scheme for hardware interfaces
As they would be predicatable names, you wouldn't need to rename them anymore

As I have already switched by removing all scripts from /etc/udev/rules.d, I was not amused to find that the udev-197-r4 ebuild happily puts the 80-net-name-slot.rules file back in there. Maybe the ebuild could be made a bit smarter in the future.

I migrated my dual-homed machine, keeping both the old "70-persistent-net.rules" and the comments of the new "80-net-name-slot.rules" files. My network interfaces kept their good old eth0 and eth1 names. No problems whatsoever.

I did have problems a few years ago, when a new kernel swapped the network interface names. After learning about ARP and such, I simply swapped the cables rather than any sort of manual or scripted interface renaming. I believe that adapting to the "natural" order is what saved me now. I also checked with the suggested udevadm command, and while my network interfaces would get new names under the new regime, their collation sequence was the same. (The one formerly ending in "0" still ended in "0", same for the one ending in "1".)_________________.sigs waste space and bandwidth

Does a 70-persistent-net-names file actually work anymore? If you've kept the 'natural' kernel-assigned names, they may only come up misnamed once in a blue moon.

Isn't the udev interface naming happening in the 80-series now? If that's the case, wouldn't it just overwrite anything done by 70-persistent-net-names.rules (assuming that rules file even still works)?

Can we get the 70-persistent-net-naming to work like it used to by moving to after the new udev predictable names are assigned?

If this can't be done easily within udev, do we need some simple syntax in openrc's netscripts config (conf.d/net) enabling users to easily rename udev-named interfaces to what they want? Or is it better to just force people to get used to these new names, and adapt to them?_________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

You're getting to my beef with most everything I've seen connected to "freedesktop.org". Practically everything I've seen come from there seems to be "Don't look behind the curtain, we'll take care of you." (AKA - "Just Works (TM") From my perspective, Linux is all about "looking behind the curtain." I know that the information on freedesktop.org stuff is available, but from what I've seen, it's got a whole different learning curve from the good-old stuff. For instance, from what I've been able to gather, systemd may actually be very well designed, modular, and all of that. But from the outside it looks like this big opaque blob, and none of the modularity is apparent. As another instance, I've seen *kit problems that are fixed by some "magic string", and in hindsight the magic string would obviously fix the problem. But I never would have figured out that string if I hadn't seen someone else post it. It's opaque._________________.sigs waste space and bandwidth

I know what you're saying, and I largely agree. Modularity is part of what has come to be known as the UNIX philosophy (i.e., do one thing and do it well). That kind of abstraction makes it easy for people to create what they want from the "Lego Blocks".

On the other hand, people naturally resist change, and I often have to tell myself to approach such things with an open mind as potential opportunities. Sometimes we forget that what we are comfortable with today was once bizarre and confusing too.

I'd just like to see rational, civil, positive discussion leading to sensible outcomes._________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

As there is no apparent difference in interface naming, is the initscript serving any useful purpose? Is it not sufficient just to rely on /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules?

If you remove the init script and 70-persistent-net.rules and 80-net-name-slot.rules from /etc and switch to the new networking name scheme for hardware interfaces
As they would be predicatable names, you wouldn't need to rename them anymore

But I don't need to rename them using an initscript at the moment, hence my question. If I leave in place /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules but don't have any initscript, I don't see any change in the interface naming:

Scenario 1
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/80-net-name-slot.rules
No initscript
Result: wired interface of my laptop is named "eth0", wireless interface of my laptop is named "wlan0".

There are 2 internal network interfaces on my motherboard (this is a Supermicro server board). Initialy they was named enp1s0 and enp2s0.
..
Then I install a video card, and interfaces got renamed to enp2s0 and enp3s0.
..
So predictable network names are not really predictable? :) Qote from the URL:
"With this new scheme you now get:
...
- Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place
..."

(He's a proponent of the new scheme, as you can see in comments 6 and 7 and thereabouts.)

It seems to me that it'd be simpler just to have kernel names, and renaming by MAC if you have more than one device of a type like eth0, eth1..

Naming according to hardware bus id is bound to go wrong, as devices come and go, and is just another layer of cleverness that doesn't actually help. Just let the user decide what names to use, and whether to at all, via configuration, with the stated prohibition on renaming to kernel names like ethN or wlanN (which can easily be checked in the config, or give an error message at runtime.)

Simpler, and much more efficient, as well as transparent and easy to understand.

Good point. The new system does offer several alternative naming schemes, though; bus-based happens to be the default.

Yes, but it's clearly a bad default. To my mind the approach is a waste of time, which a little thinking beforehand would have spotted.

While I think they could have gone for the above approach at the beginning (again, with a a little thinking beforehand), and saved everyone a lot of hassle, it's a bit late now, given the amount of initscripts that are using multiple ethN, so I'd favour a minimal kernel mapping file at this point.

But in any event, if they're going to change and cause pain, they should change to a scheme that makes sense, and lose the idiot-box code that is just that: idiotic.

Even if they did just write it. As usual, they're being clever around a flawed basis, and causing more pain while claiming to help and we have to spend ages debating their idiotic approach and dealing with the end-user fallout, instead of them simply learning how to do things right the first time: by thinking a little beforehand, and not assuming their first idea is the best approach.

They should start questioning themselves and their own ideas: if they did that half as much as they questioned the traditional Unix discipline and craft, their work would be a whole lot better.

They should start questioning themselves and their own ideas: if they did that half as much as they questioned the traditional Unix discipline and craft, their work would be a whole lot better.

No mod points. Darn!

Don't you just wish there were some way to have a simple table with 2 entries per network device, a MAC and a device name. Do it the "udev" way with all sorts of syntactic sugar around it, do it in the 2-pass process, where the first time udev runs it generates the rule for subsequent boots.

But there are 2 main pieces of information that really matter, the MAC and the device name, and the former is truly stable. If your network device came in a box, maybe there was even a sticker on it with the MAC printed in which case it was even predictable._________________.sigs waste space and bandwidth

Don't you just wish there were some way to have a simple table with 2 entries per network device, a MAC and a device name. Do it the "udev" way with all sorts of syntactic sugar around it, do it in the 2-pass process, where the first time udev runs it generates the rule for subsequent boots.

But there are 2 main pieces of information that really matter, the MAC and the device name, and the former is truly stable. If your network device came in a box, maybe there was even a sticker on it with the MAC printed in which case it was even predictable.

Totally agree. This isn't an issue for me since I don't run any servers. As I said in the other thread, if the change were coming in now, it would be better done as above, to avoid kernel races and not require the kernel to do anything at all. But given the amount of legacy configuration that is out there, and the attendant nightmare of changing from eth0-7 for example, if you've already setup a load of production servers with the same base pattern, I think a better solution would be what you stated:
"a configuration parameter to kernel bootline, with a filename of simple: ifname XX:XX:XX.. MAC address mappings (and ignore lines starting with '#'). The minimal kernel-logic required would be a compile-time option, and would enable 'renaming' or rather 'reservation' within the kernel namespace."

That way, it's a compile-time option for distributors and end-users like us who build kernels from source. Even when compiled in, it's not going to slow anything down, since it only ever does anything when an interface comes up, and is an opt-in configuration: for the admin or end-user, checked at boot-time, where it belongs. So an admin with multiple ethN could just fire and forget by MAC address. The only time you'd need to change anything, would be when you add or remove a NIC, which isn't that often (and is when you're ready to deal with changes.) And since it's fire and forget, you can use it for standard installs of virtual machines, where you can control the MAC address.

And none of it would be required, if your machine always brought cards up in the same order (which you can ensure or test reliably with a VM), or you were a normal desktop user. eth0 and wlan0 could still be a sane default for configurations: after all if you're doing something different, you're going to be editing network configuration in any case (or using something like puppet or a vcs like git.)

Granted MAC spoofing is possible, but it's not at the level of the kernel bringing up the NIC.

From there on, other machines on the LAN are usually going by IP, though you might want to change the MAC after the system is brought up, in a VM situation, iff it's relevant to what you're doing. And if it is, you'd rather worry about a much higher level of config, than what the latest fashion is, for deciding what card is called what. You want fire and forget simplicity from the base system, just like the rest of us users do: it's one of the reasons we love Gentoo, with configuration as close to upstream as possible (when it's sane.)

Ideally server admins would have been using the non-racy names since the beginning. But that's not what happened, and you cannot just disrupt all those users' systems, just because you feel like it. Especially not with a crap idea like using bus ids because they "never change."_________________

Good point. The new system does offer several alternative naming schemes, though; bus-based happens to be the default.

Yes, but it's clearly a bad default. To my mind the approach is a waste of time, which a little thinking beforehand would have spotted.

This was I point I kept making loudly in another thread. This scheme is asinine and dangerous, and it is not terribly predictable. It means, among other things, that if you move your NIC to another slot, you have not only to edit scripts which refer to the interface name, but also rename the init script.

Code:

mv /etc/init.d/net.enp0s1 /etc/init.d/net.enp0s2

They're promoting instability in place of stability!

steveL wrote:

While I think they could have gone for the above approach at the beginning (again, with a a little thinking beforehand), and saved everyone a lot of hassle, it's a bit late now, given the amount of initscripts that are using multiple ethN, so I'd favour a minimal kernel mapping file at this point.

I always had to wonder if certain Microsoft decisions (like their practice of using shortened file names in the registry instead of the real names, thereby making it impossible to use simple tools for backups) were based on short-sightedness or whether they were part of a careful plan to foil open systems. Likewise, I wonder if this default naming interface scheme is actually a ploy to make people give up on other init systems and move over to that wise, beneficent systemd. Ah, systemd would know what your interfaces are and start them for you--so don't worry your little head.

steveL wrote:

But in any event, if they're going to change and cause pain, they should change to a scheme that makes sense, and lose the idiot-box code that is just that: idiotic.

Yes, they should change. Are they willing, though?

steveL wrote:

They should start questioning themselves and their own ideas: if they did that half as much as they questioned the traditional Unix discipline and craft, their work would be a whole lot better.

The root cause of all this is the "early userspace" concept, which may have been a bad idea after all. It created an egg to be loaded before the chicken, but now the fucking egg has hatched and it's trying to grown into another whole chicken itself._________________

patrix_neo wrote:

The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.

The root cause of all this is the "early userspace" concept, which may have been a bad idea after all. It created an egg to be loaded before the chicken, but now the fucking egg has hatched and it's trying to grown into another whole chicken itself.

BoneKracker ... hehe, I've been promoting the idea of an infinite regress of initrds for some months now, we're a young church but our weekly infinite meetings are a blast, with our system you really can encrypt the *whole* shebang, universe and all! Boot times are horrrrrendous, but we're ironing out the minor details ... keep watching this space :)