[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Network Card Naming Issue



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 tmr com>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]