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@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
