Re: Network Card Naming Issue
On Fri, 21 Nov 2008 22:46:10 -0700 Phil Meyer [EMAIL PROTECTED] wrote: For administrators and serious tinkerers, understanding what is being used is the first step. Yea. I could have saved many hours of confusion if the udev persistent rule generation also sent mail to root saying I've just written this new hardware identifier to /etc/udev/70-persistent-cd.rules I would have gotten the mail, said I wonder what the heck that gibberish is?, then when I noticed the /dev/sr1 versus /dev/sr0 problem shortly after that, I would have said Hey, maybe that gibberish mail I just got has something to do with this. :-). -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
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 [EMAIL PROTECTED] 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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
Bill Davidsen wrote: 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. You do need to be able to move parts around as well as replace old parts in an existing system. And you need to be able to do image copies of drives. What happens if you put disks with duplicate labels (for years they wouldn't boot...) or uuids into the same machine? What if you put disks that previously used to be the same-numbered md? device from 2 different machines into the same box? It has been a while since I tried that, but it wasn't pretty. What if you want to replace your current eth0 with a different card and shift the use of the existing one to a different subnet? And all of this gets in the way when you need to restore your backups onto a similar but different box. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
Bill Davidsen wrote: 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. You do need to be able to move parts around as well as replace old parts in an existing system. And you need to be able to do image copies of drives. What happens if you put disks with duplicate labels (for years they wouldn't boot...) or uuids into the same machine? What if you put disks that previously used to be the same-numbered md? device from 2 different machines into the same box? It has been a while since I tried that, but it wasn't pretty. The md device number seems not to be an issue. If I put it 2 sets of drives that used to be md2 in former machines, which set will become md2 and what happens to the other one? Using a non-unique UUID on a system is the same level as swapping two hard drives and using the physical device name to determine how they're used, if you make an effort to shoot yourself in the foot you will wind up with a hole in your shoe. Deliberately creating a condition where the information used to tell hardware apart is ambiguous is dubious practice at best. Making a unix-like system that can't deal with dd-copied disks is shooting everyone in both feet. What if you want to replace your current eth0 with a different card and shift the use of the existing one to a different subnet? Have the info in one place, sysconfig, not sysconfig and hal keeping their own idea of reality. Being able to set this in one place is good, assuming that two places will always match is unrealistic. People screw up, restores happen, one place is right or wrong, but never maybe. And all of this gets in the way when you need to restore your backups onto a similar but different box. If you make physical backups of drives that is the least of the problems. The disk part will work as long as the replacement motherboard has the same controller type - and you don't put 2 copies of the same disk in it at once. But your network won't come up, so it's no fun when you have someone replacing stuff remotely and you expect it access it again. The UUID isn't backed up using by-file backup, so conventional backups by tape or rsync aren't a problem. You always have a problem, you are just moving it around. Now you have a machine that won't boot, and if it did boot, would have fstab entries pointing at uuids or labels that don't exist. Finding that two drive made a few months apart, with the same part number, are actually slightly in size is painful reality, the only things I backup with a physical backup are VM images, and usually not those either. The problem of mismatched identifiers is always going to exist, depending on which part you swap, and the motherboard, nics, conrollers, and disks are all equally candidates. We just need something besides andaconda that knows how to glue the pieces together. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
Les Mikesell wrote: The problem of mismatched identifiers is always going to exist, depending on which part you swap, and the motherboard, nics, conrollers, and disks are all equally candidates. We just need something besides andaconda that knows how to glue the pieces together. I worried about the Solaris catalog method when it was implemented, but it was a site finer than the AIX ODB, which had to match the equivalent text config files. Edit one of those by hand to get it out of sink with the ODB and AIX could crumble. The further notion of a 'registry' has long been proven less than useless in its implementations. The current Linux method of creating persistent udev entries for the hardware it sees, is much more like the SUN catalog than the ODB or registry approach, but I agree that the job is not done yet. For administrators and serious tinkerers, understanding what is being used is the first step. That is what we are trying to accomplish here. Suggestions and possible solutions would probably go to the lkml, but I am short on those. However, my observations lead me to hope that we are headed in the right direction. If I could have my wishes, I would push for LVM support in grub, automatic LVM evaluation by anaconda (are these drives in a LVM?), and better kernel errors when a LVM cannot be put together properly on boot -- give us some kind of (legible) clue. Software based raid, including LVM, ZFS, and even GFS have great potential into the foreseeable future. Linux as a kernel and platform need better support for these. UUIDs are not enough to resolve issues with RAID devices. . -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
Tom Horsley wrote: On Wed, 19 Nov 2008 19:05:54 -0600 Mikkel L. Ellertson [EMAIL PROTECTED] wrote: Take a look at /etc/udev/rules.d/70-persistent-net.rules Yep. It happens to other hardware as well. I replaced a dead DVD drive and spent quite a while tracking down why it came up as /dev/sr1 instead of /dev/sr0 (similar persistent .rules file with different name). Yup - to see the list, you can run: ls /etc/udev/rules.d/??-persistent-*.rules Maybe we need to update the program to check if the old hardware has been removed when adding entries to the persistent rules... Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
Mikkel L. Ellertson wrote: Tom Horsley wrote: On Wed, 19 Nov 2008 19:05:54 -0600 Mikkel L. Ellertson [EMAIL PROTECTED] wrote: Take a look at /etc/udev/rules.d/70-persistent-net.rules Yep. It happens to other hardware as well. I replaced a dead DVD drive and spent quite a while tracking down why it came up as /dev/sr1 instead of /dev/sr0 (similar persistent .rules file with different name). Yup - to see the list, you can run: ls /etc/udev/rules.d/??-persistent-*.rules Maybe we need to update the program to check if the old hardware has been removed when adding entries to the persistent rules... An updated version of kudzu? Who woulda thought? :-) -- - Rick Stevens, Systems Engineer [EMAIL PROTECTED] - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Never try to outstubborn a cat. - -- -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Network Card Naming Issue
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, -- Manish -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
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. Take a look at /etc/udev/rules.d/70-persistent-net.rules Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
On Thu, 2008-11-20 at 06:15 +0530, Manish Kathuria wrote: 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. Do you have an eth0 configuration file that has a HWADDR= line in it, with the MAC of your old ethernet card after the equals sign? If so, then it's holding eth0 for that card, even if that card isn't still in the box. Remove the line, or set it to the MAC of your new card. See: /etc/sysconfig/networking/devices/ifcfg-eth0 -- [EMAIL PROTECTED] ~]$ uname -r 2.6.27.5-37.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Network Card Naming Issue
On Wed, 19 Nov 2008 19:05:54 -0600 Mikkel L. Ellertson [EMAIL PROTECTED] wrote: Take a look at /etc/udev/rules.d/70-persistent-net.rules Yep. It happens to other hardware as well. I replaced a dead DVD drive and spent quite a while tracking down why it came up as /dev/sr1 instead of /dev/sr0 (similar persistent .rules file with different name). -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
