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! -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
