Good point, however, the problem is only half-solved.

If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p <dev> and replug cables.

We have solved the problem by providing a consistent algorithm of sorting all the devices in a udev callback. We have a known set of hardware so we know which cards are add-ons (our machines have 4+ eth ports) and which ones are built-ins. So it works out, however, it would be nice to generalize it somehow.

> Network interfaces should not rename themselves after reboots.

But that's because PCI bus walk order doesn't change across reboots.

There are a lot of other solutions to that. The Ububuntu one I favored in the 8.x era was /etc/iftab, it's a shame they retired it in favor of udev.

While udev is more universal, iftab felt elegant and unixy.

Why not give an argument to the kernel to create the new devices as "fooX" (foo being a supplied parameter) - and let udev userland deal with the renaming to "ethY" as it pleases ?

While this novelty certainly may appeal to the folks who are used to alphabet soup in the network adapters list, and I too think that the adapters that distinguish between the T568A and T568B cable layout have a degree of coolness in them by creating an extra value in being able to distinguish between the straight and crossover cables - overall it seems like a step back to me.

I would plug in the interfaces into a switch - and all I care is to find the same MAC address as I see on the switchports - not which bus they attach to.

Well it depends. There is a kernel parameter that forces a consistent walk order:

   pci=bfsort

It forces breadth-first device sorting.

But otherwise I understand that devices are detected in parallel and whichever ones return first are designated eth0, eth1 etc.

We had this problem on some machine that have 4+ eth0 devices. We use RHEL|CentOS 5.x (see in the post above how we solved the problem).

Moving a PCI card to another slot should also not rename the device. With a typical current udev setup, device names are persistent based on MAC address. With this proposal, either the name will change if the bus topology changes, or bus location based names will be _wrong_. As usual the fedora/desktop trolls are breaking perfectly good things for no apparent reason at all.

> If the machine is coldstarted then previous devices could be randomly reshufled.

The detection order would change, but the ifcfg file (RH) or udev rules (SuSE and others) would not change, so your NICs will stay the same these days.

It's not that it self-perpetuates, it's that nearly every other Unix does it that way, and thus there's an expectation that ifconfig, if it exists, has similar functionality on all platforms.

If you're going to deprecate a command, make running the old one either:

1. Not exist, and thus have the shell throw an "command not found" error

2. Print a useful message like "Use <newcommand> instead"

3. Work, but do #2 as well.

The current situation is like leaving a pair of rusty pliers out in the open, and hiding the brand new socket set when the goal is tightening a bunch of bolts.

I used ifconfig until about halfway through last year when someone pointed 'ip' out to me. I kept using ifconfig right up until the point I found that ip didn't require root rights...

True - I'm just grasping as straws to come up with an excuse as to why this has gone on for so long.

That is the the problem I am trying to convey -- the machines are coldstarted often and MAC addresses are reshufled on every first boot. If your cable to the management network is connected to left socket on the motherboard, that left socket needs to be eth0 on every coldstart. Sometimes it is not. "Yes" after the first boot when ifcfg files has been written it will be stable, but that mean someone has to go and either hand-edit ifcfg files or run ethtool -p eth0 and replug the cables.

> Subsequent cold starts only read the files

No they don't. Thare no files to read. You just wrote above in your commetn that the first time OS boots ifcfg are generated. So after a machine is coldstarted there are no ifcfg files! They are generated once per coldstart and saved. Then during each restart those files are read and everything is fine.

Now, I was saying, you can have a provisioning scheme where during coldstart, in your kickstart file you can fetch and write stable ifcfg files to prevent machines from creating their own. What we do instead is install a custom RPM with a udev script where an algorithm sorts the network interfaces in a stable way (since we only deal with a known and limited set of motherboards and network cards).

No probs. Most places I've worked at use 'provision' or 'bare metal' for an os install plus mop up work, starting cold as a way to differentiate from warm booting, appreciate different places may have different systems though. Thanks for being classy about it :-)