Linked by Hadrien Grasland on Tue 25th Jan 2011 14:23 UTC, submitted by Debjit
Fedora Core "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."
Order by: Score:
Why?
by B. Janssen on Tue 25th Jan 2011 18:03 UTC
B. Janssen
Member since:
2006-10-11

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?

Reply Score: 3

RE: Why?
by Neolander on Tue 25th Jan 2011 18:27 UTC in reply to "Why?"
Neolander Member since:
2010-03-08

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

Reply Score: 1

RE[2]: Why?
by rexstuff on Tue 25th Jan 2011 18:35 UTC in reply to "RE: Why?"
rexstuff Member since:
2007-04-06

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.

Reply Score: 2

RE[3]: Why?
by phoenix on Tue 25th Jan 2011 18:38 UTC in reply to "RE[2]: Why?"
phoenix Member since:
2005-07-11

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.

Reply Score: 3

RE[4]: Why?
by rexstuff on Tue 25th Jan 2011 21:00 UTC in reply to "RE[3]: Why?"
rexstuff Member since:
2007-04-06

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.

Reply Score: 2

RE[5]: Why?
by phoenix on Tue 25th Jan 2011 21:04 UTC in reply to "RE[4]: Why?"
phoenix Member since:
2005-07-11

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.


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

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.


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.

Further, how difficult is to sudo rm /etc/udev/rules.d/70-persistent-net.rules?


It's one extra (manual) step in our restore process. Not too ornerous, but still a pain.

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.


We do that a lot, to work around the brokeness.

Reply Score: 2

RE[3]: Why?
by Neolander on Tue 25th Jan 2011 19:22 UTC in reply to "RE[2]: Why?"
Neolander Member since:
2010-03-08

Then indeed this doesn't seem very relevant. Don't know why they do it this way in this case.

Reply Score: 1

RE[3]: Why?
by phoenix on Tue 25th Jan 2011 21:06 UTC in reply to "RE[2]: Why?"
phoenix Member since:
2005-07-11

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.

Reply Score: 2

RE: Why?
by phoenix on Tue 25th Jan 2011 18:35 UTC in reply to "Why?"
phoenix Member since:
2005-07-11

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

Reply Score: 4

RE[2]: Why?
by B. Janssen on Thu 27th Jan 2011 21:52 UTC in reply to "RE: Why?"
B. Janssen Member since:
2006-10-11

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.

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


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

Reply Score: 2

RE: Why?
by AdamW on Wed 26th Jan 2011 19:23 UTC in reply to "Why?"
AdamW Member since:
2005-07-06

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.

Reply Score: 2

-
by foregam on Wed 26th Jan 2011 15:44 UTC
foregam
Member since:
2010-11-17

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

Reply Score: 1

RE: -
by phoenix on Wed 26th Jan 2011 16:30 UTC in reply to "-"
phoenix Member since:
2005-07-11

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

Reply Score: 2

RE[2]: Off-topic
by foregam on Thu 27th Jan 2011 00:29 UTC in reply to "RE: -"
foregam Member since:
2010-11-17

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

Reply Score: 1

RE[3]: Off-topic
by phoenix on Thu 27th Jan 2011 02:35 UTC in reply to "RE[2]: Off-topic"
phoenix Member since:
2005-07-11

/boot/loader.conf and /boot/device.hints came with FreeBSD 5.0, so you just missed it. ;)

Reply Score: 2