Network Card Naming Issue

[Phil Meyer]

Manish Kathuria wrote:
> Hi,
>
> I have experienced a strange issue in Fedora 9 while replacing
> ethernet cards. Whenever a network card is replaced in Fedora 9, many
> times the new NIC takes a new logical interface name instead of taking
> the original interface name. For example, if a network card eth0 is
> removed from a Fedora 9 system and is replaced by another network
> card, the new card appears as eth1 or eth2 instead of eth0. This
> happens even if the cards are having the same chipset (and therefore
> the driver). What could be the reason for this behaviour ?  It leads
> to a number of problems like modification in scripts, etc. I have
> never observed this in the earlier distributions.
>
> Thanks,
>   

Other posters have given good answers as to how the newer 
kudzu/anaconda/udev/hal combo works, but perhaps a bit of reasoning is 
in order.

Consider for a moment, if you will, Solaris 2.3 on large hardware, 
capable of housing up to 64 disk controllers. 
Assume that cards are in slots 1, 5, and 9.
Assume that all drives on all controllers are part of software based 
RAID volumes.
Assume a new card is inserted into slot 2 while the machine is down, and 
new hard drives are attached to the new controller.

On next boot, all hard drives were reordered based upon controller card 
number.  All RAID volumes are now corrupt and will not mount, and are 
not recoverable.

This was a disaster for SUN, who quickly came up with a remedy.  All 
hardware would be cataloged and the catalog would be preserved upon 
rebooting.  Any new devices, would be given a new device number, 
regardless of whether a matching device is still present in the system.

By doing this, any new controller detected would not affect existing 
controllers or disc ordering.

At first, it was annoying, because failed controllers could not be 
replaced without hardship.

Eventually, the solution became reasonable, and was certainly better 
that the alternative, especially when considering software based RAID.

Now jump forward to modern days and the Linux kernel, and kernel 
supported hardware device drivers.

The same issues were in effect for Linux, as what was happening to early 
Solaris 2.X releases.  A method MUST exist to remember old hardware.

Right now, the key hardware components are remembered by udev.  As this 
new method matures, it will become easier to maintain/remove hardware.  
But think of the alternative!  The old way might be ok for single drive, 
single interface systems, but not otherwise.

There are many of us who remember the 'bad old days' when this issue was 
capable of destroying months of work!

Good Luck!