predictable network interface names

[steveL]

[Anon-E-moose]

[mv]

[steveL]

[Anon-E-moose]

[oliv3r]

So what about USB devices, while less likely used, do they get re-enumerated? I can quite imagine they can.

I believe we can conclude quite safely, that this fix is just as broken as how it was. And the only reliable way now is to use the MAC address in udev rules.

So who will bring this up with upstream? Let them know that their 'one way to rule them all' is just as flawed as the rest. I guess they can always argue, the previous method was 99% 'workable' and this is 99.1% 'workable' this is still better then what we had.

Even though it causes haywire everywhere and more trouble then its worth.

OT:
I must say I quite liked the Virtual Machine using identical MAC addresses, I'm surprised that identical MAC addresses wouldn't clash on the KVM layer. I mean, normally, you want unique MAC address on a LAN level, because otherwise switches get confused. So KVM does the switching here, does that care about clashing MAC addresses? If i'm not mistaken, KVM creates on vlan interface on the host per guest and that gets internally connected to VM. So should be okay still, right?

[Aiken]

[steveL]

[oliv3r]

Since there hasn't been a reply in a while, I will re-iterate (or repeat) one thing.

This whole predictable name thing is stupid and broken.


A little example. Onboard LAN0, disabled in bios. PCI-E LAN1; used. Everything fine.

Enable onboard LAN0.

Guess what happens.

The PCI bus gets re-enumerated. Guess what is all messed up? Right. What was enp3s0 is now enp4s0. *G*. I guess it is not predictable at all and does make it harder for all.

I guess the most resiliant way, is rename by MAC. As it has always been. What does this new behaviour bring? Absolutly. NOTHING. As it simply does not work.

[SamuliSuominen]

[oliv3r]

So it 'almost' works. Well so far, it's little benefit.

* It doesn't work with USB as one would hope (unless you always use the same USB port)
* It doesn't work reliably with PCI, if PCI bus can be enumerated (Which is out of our control).

I really tried to use this new system, I really did. I moved over my servers (one fails, it has a quad port card that it refuses to rename), on my desktop it messed up and having 1 usb NIC makes things interesting to say the least.

So for me, as someone who didn't really like the MAC way, I will switch to the MAC way. And least that works as one would expect.

[Anon-E-moose]

[Dr Croubie]

Hi all, I'm another victim of the perpetual mess that is udev. I've read through the past few pages and I just can't seem to make sense of anything.
So here's what I've got (firstly, i've only got 1 inbuilt network, on-motherboard so it ain't ever changing):

> dmesg | grep udev
systemd-udevd[839] renamed network interface eth0 to enp4s0

in /etc/init.d:
net.enp4s0 -> net.lo

in /etc/conf.d/net:
config_enp4s0="192.168.8.128
config_enp4s0="default via etc

in /etc/conf.d/network everything is commented out

in /etc/conf.d/netmount everything is commented out except the line:
rc_need="net.enp4s0"
(it started off just saying plain "net" so i changed it to "net.enp4s0", neither work)

/etc/udev/rules.d/ was an empty directory, I've tried it as a symlink to /dev/null, neither work.

> rc-update
net.enp4s0 | boot
net.lo | boot

and finally:
> grep -i eth0 /etc/* (and /etc/*/* etc)
all turn out no more references to "eth0" that aren't commented out.


Now, system boots at least. But I get:
ERROR: cannot start netmount as net.eth0 would not start
ERROR: cannot start sshd as net.eth0 would not start
both on boot and when just typing 'rc'.

And:
> ping 192.168.8.1
connect: Network is unreachable

> ifconfig
lo: flags etc
and no reference to net.eth0 or net.enp4s0 or anything.



Seems every time I upgrade anything to do with udev it takes me a few hours to get a working system again. thnkfully I'm just a desktop and not a webserver or I'd be boned about now.
Can someone please explain what files have to say what? I've never written a udev rule, so if that's the answer then please walk me through it.

Option 1, I keep using 'net.enp4s0' and update every reference to use that. What other references are there that are not in /etc/*, because there's none there.

Option 2, I stop/kill/uninstall udev or whatever I have to do to just keep using eth0 like I've used for the last 15 years. Something somewhere said about 'just type something on the kernel command line'. Does that mean every time I boot I have to press a key in Grub and do something manually, or how do I do it automatically (and gracefully, not kludgy)? The news item says something about "you can't use eth* you have to use free namespace like net*", so if I can't use net.eth0 and have to rename everything anyway, then I may as well use net.enp4s0.

Either way I don't care, whichever is easiest. anything to get my network going again (which I seem to write every time udev upstream changes its mind on something)

[Dr Croubie]

ps, I also just tried re-creating eth0 as much as I had before:
> rc-update
net.enp4s0 | boot default
net.eth0 | boot default

/etc/init.d
net.enp4s0 -> net.lo
net.eth0 -> net.lo

That also does nothing. So I can't even fool the system into trying to access a deice that doesn't exist.




Further testing, I rebooted to Grub, pressed 'c' for a command line, and:

grub> net.ifnames=0
Error 27: Unrecognized command.

So how is that meant to work again?

[Jaglover]

For last method, put it in kernel command line, like this

[mv]

[John R. Graham]

[depontius]

Having been in corporate America for over thirty years, I've learned of and can recognize "institutionalized bad decisions." Those situations where enough people have bought into a bad decision, with enough skin, that they can't back down. Then more reasons start to materialize after the fact to justify that decision, and those reasons start looking trumped up, too.

IMHO, this was a bad decision, and we've begun the trumping-up phase. It's an institutionalized bad decision. The old way wasn't a decision, it just kind of happened, historical accident.

Here's what it comes down to - the old way only ever crossed me once, on a dual-homed machine, when something changed and my network cards swapped. I don't remember why they were swapped, but had it been due to a change in pci enumeration, the new way would have crossed me just as surely. If you have any sort of USB networking hardware old or new way would be equally unreliable.

Basically the new scheme has not significantly improved things, and has broken a whole heck of a lot of legacy.

Oh, and one other thing - the new scheme is NOT predictable. Until you plug that device in, you don't really know what it's going to be named. The only predictability is after-the-fact, and the fact is that enumeration-based names can get tweaked by other hardware getting plugged/unplugged that happens to be earlier in the enumeration sequence.
_________________
.sigs waste space and bandwidth

[broken_chaos]

I accept it being called "predictable" in cases where changing the physical port changes the device name -- not ideal, no, but predictable (as long as it goes back to the previous name when moved to the previous port). I'd not accept it being "predictable" in cases where enabling/disabling or adding/removing a completely unrelated piece of hardware results in a new name, though. One might be able to rules-lawyer an explanation as to how it's 'technically' predictable, but that's a pretty big cop-out if the piece of hardware that was renamed was never moved or touched. Perhaps the use cases of the new scheme's designers just never had to add or remove hardware before...

Also, perhaps I'm missing something, but it seems like the best solution would have been the simplest -- keep on using "persistent" rather than "predictable" names. Meaning keep the old rules generator intact, and just use a new, non-kernel, namespace. You would have undoubtedly had a bit of grumbling, but getting used to "en0" and "wl0" instead of "eth0" and "wlan0" (for example) seems like a much better solution than "enp3s48" and friends. Unless I'm completely missing something about how the old rules generator was broken, of course. That's actually the sort of solution I'd love to see pop up in something like eudev, since there is that awkward race condition with the reuse of kernel namespaces.

[mv]

[Aiken]

[broken_chaos]

[depontius]

Could someone please explain the naming race condition to me.

Have the kernel devs said that this race condition can't be fixed?
_________________
.sigs waste space and bandwidth

[broken_chaos]

[mv]