Network Card Naming Issue

[Bill Davidsen]

Phil Meyer wrote:
> 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.
> 
Actually, no. The method is to use UUID and totally ignore hardware names. 
That's what current /etc/fstab and /etc/mdadm.conf do these days.

> 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!
> 
The hal stuff was written by people who were wedded to matching the same device 
to the same name. Putting MAC address, UUID, or serial number in as the key is 
far more reliable, and allows people to to have a single place to specify the 
match. Having to beat up sysconfig and hal to change a failed device is not 
conducive to good system administration.

Your points are well taken, but I consider hal keeping it's own ideas instead of 
using sysconfig to be a bug, not a feature.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot