Looks like this could solve the problem of network interfaces renaming themselves after reboots. Hooray!
On other distributions, "udev" accomplishes the same thing.
The only point when interface naming is arbitrary is at installation time, then it stays the same forever.
Not only this will add confusion by introducing a bunch of new names for network interfaces, it will also break applications that rely on them being called "ethX".
It will also make it impossible to manually assign names to interfaces. For instance, if you have a configuration that uses an embedded interface and you want to add another interface on a card, you can manually assign the same "ethX" name to it, but not if the names depend on the physical characteristics of the hardware.
But that's because PCI bus walk order doesn't change across reboots.
pci=bfsort
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).
I once had a server (in the pre-udev era) that would occasionally shuffle its network devices after reboots. I don't remember how I fixed it but I do remember the short phase of amusement, followed by a longer phase of frustration.
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.
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.
> 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).
As long as you don't reinstall your OS, or lose your data, your config files are there. Cold starting hardware does not delete data.
Are you trolling?
Alright, figured it out. When you talk about coldstaring you really mean restarting the machine, as in pressing the reset button for example. When I talk about coldstarting I mean starting with a bare hardware box and installing an OS on it.
> Are you trolling?
Actually I thought you were. Sorry for the misunderstanding.
[EDIT: I won't edit my previous posts, otherwise your posts won't make sense, let others laugh at my bad English (it is a 3rd language so I don't mind)]
Ability to rename: http://lists.us.dell.com/pipermail/linux-poweredge/2010-Nove...
Why the eth prefix can't be used: http://lists.us.dell.com/pipermail/linux-desktops/2011-Febru...
More background: http://domsch.com/blog/?p=455
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.
While udev is more universal, iftab felt elegant and unixy.