“Fedora developer, Matt Domsch, has announced that Fedora 15 is breaking the conventional ethX naming scheme used for Ethernet devices by adopting a new scheme called Consistent Network Device Naming.”
“Fedora developer, Matt Domsch, has announced that Fedora 15 is breaking the conventional ethX naming scheme used for Ethernet devices by adopting a new scheme called Consistent Network Device Naming.”
I read the fine article but I can’t see how this approach is superior to the currently available method of binding a MAC to an interface name. What’s wrong with that?
As far as I understand, with these new fancy parallel startup algorithms (systemd, upstart) which we have implemented in linux distros, it can’t be guaranteed anymore that ethX will always be associated to the same NIC as a vanilla setting.
Sure, you can as a sysadmin force a specific MAC address to be associated to an interface name, by tweaking some config file somewhere. But the goal of this consistent naming thingie is to make this process transparent. The sysadmin has nothing to do, the OS itself guarantees that ethX will always refer to the same hardware.
Having met the pain of having my disk drive’s block device name changing from one distro to another, I can understand the motivation behind this.
Edited 2011-01-25 18:31 UTC
But most systems already do this automatically. Check out your /etc/udev/rules.d/70-persistent-net.rules
It seems to me that Fedora has come up with a more complicated solution to an already-solved problem. A minor, but needless additional fragmentation of Linux user space consistency.
Looking at the naming scheme, it will fail with something as simple as changing the direction that PCI buses are enumerated by the BIOS.
Boot with “Descending” selected in the BIOS, and the top PCI slot on a desktop is bus 0. Boot with “Ascending” selected in the BIOS, and the top PCI slot is now bus 4.
Thus, your PCI NIC will change from pci0#0 to pci4#0.
Yeah, that’s consistent.
Ok, seriosuly – how often does that really happen? If you’re changing the order in which PCI devices are enumerated, such a bug resulting from that would be labelled YOUROWNSTUPIDFAULT.
Also, I would point out that the scheme presented by fedora would also be vulnerable to that; it relies on the enumeration provided by the BIOS.
Further, how difficult is to sudo rm /etc/udev/rules.d/70-persistent-net.rules ? And, the current system allows sysadmins to force a device to a particular ethX name; one can override the system and make a device eth1 instead of eth0. Fedora’s system seems ot provide no such flexibility.
BIOS updates from Tyan have a tendency to toggle the default value of this item. We’ve been bitten by it several times.
Same with Debian kernel upgrades that toggle the order PCI buses are enumerated. We’ve also been bitten by this several times.
Neither of those are “OUROWNSTUPIDFAULT”.
Yeah, I mentioned that in another post. And sent a question to the original blogger about it, to see how it works in that situation.
It’s one extra (manual) step in our restore process. Not too ornerous, but still a pain.
We do that a lot, to work around the brokeness.
Then indeed this doesn’t seem very relevant. Don’t know why they do it this way in this case.
Hrm, weird, my reply to your post showed up as a reply to the parent of your post.
And my reply to the parent showed up as a reply to you.
Because it breaks in many weird, spectacular ways. The first thing we do on our Linux machines is remove the horrible udev hacks to lock the interface name to the MAC address.
There’s nothing worse than restoring a server from backups to new hardware, and having “eth0” come up as “eth8” because eth0 through eth4 are locked to the MAC of the old machine. And then spending 15-20 minutes hacking around udev to get the names set correctly. And then another 15-20 minutes to get ifupdown to allow us to reuse eth0-eth4 since it locked them as “non-existent”. It’s a pain!!
Although, at least that’s better than when a kernel update (minor update, 2.6.X to 2.6.X+1) changes the direction that PCI buses are enumerated, so the numbering changes (eth0 is now eth4). Usually, locking the name to the MAC prevents this, but not always, since the PCI ID/slot/whatnot changes.
One of things that really irritates me about Linux is the whole ethX naming scheme. Give me non-generic interface names anyday.
Anything that makes it more sensible and easier to use is welcomed! Too bad this proposal is neither.
Edited 2011-01-25 18:39 UTC
I’m under the impression the threading of this topic is borked.
Anyway, I do not agree with your evaluation of the situation. Just delete persistent-net.rules and reboot. Don’t muck about with ifup/down.
I really beg to differ. With generic interface names I can move scripts and daemon configurations around with minimal fuzz. Your first NIC died and you want your third NIC to take over? Just rename the stupid thing to eth0 — one edit in one file and you are done. I can’t think of a non-generic interface naming scheme that can do that. Pure bliss
Better to read the original explanation:
https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNamin…
and the links therein. Note that describing Matt as a ‘Fedora developer’ is a bit incomplete; Matt works for Dell, and it’s Dell that’s mostly behind this change, but it’s something that’s been under discussion in the kernel networking group for a long time. Fedora is just the first distribution to land this change, it will likely hit most of the others quite quickly.
There’s a good overview of previous proposals at http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Implementati… – from which you can tell this is something that’s been on the table for a while.
I think BSD got this one right: just use the driver’s name and add a number at the end. Perhaps this too would need persistence rules though. If only the .config format were a bit closer to BSD’s and provided a way to hardwire a device name-bus address pair…
/boot/loader.conf can be used for this, using the format specified in /boot/device.hints. Don’t use the hints file, though, as that can be deleted/replaced as part of an installworld/mergemaster run.
Pretty much anything can be wired down to a specific target, on a specific device, on a specific bus using that.
> /boot/loader.conf can be used for this
I guess you’re talking recent FreeBSD here. The last release I used was 4.11, if I’m not mistaken. However, on NetBSD 1.4Z (that’s what I run here), you do it in ye goode olde way.
I’d love to see a new human readable and writable .config format for Linux.
/boot/loader.conf and /boot/device.hints came with FreeBSD 5.0, so you just missed it.