On Thu, Mar 5, 2009 at 10:23 PM, Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > This is the second time this has happened to me. The first time was > after a hardware upgrade on the computer I'm using right now, however, > it was an F8 system so instead of preupgrade I decided a fresh install > was in order, no big deal. > > This time it's with my Myth Box running F10 and if I don't fix this > quickly the wife is going to kill me. Why does a hardware change (new > MB) cause this problem? Shouldn't it be able to find the volume group > regardless? > > In my previous situation a livecd could find the volume group but the > installed system could not and I suspect the same will happen this > time but I am creating a livecd just to be sure. > > Any troubleshooting ideas? > > Thanks, > Richard > > Old System: > AMD Sempron 64 3100+ > Cheap nForce3 MB > > New(er) system: > AMD Athlon X2 5200+ > Gigabyte AMD 770 chipset. MB Ok, the initrd was the culprit as both Mikkel and I suspected even though I still don't know why the initrd I copied from my working system which had identical hardware specs didn't work. If you ever need to rebuild an initrd from a broken system using a rescue disk or livecd/usb system there are a couple of things you need to do before you can successfully build an initrd from a chroot environment. The plain chroot environment does not map things like /dev /sys /proc which mkinitrd depends on. I'm not sure if every one of these steps is absolutely needed but it worked for me. Also, I'm going to break the steps down a lot for those that find their way here from google. 1. Boot livecd/usb system (rescue boot from an install CD/DVD should work as well). 2. Open terminal or console and run "su" for root. 3. Mount your root partition or logical volume (in my case VolGroup00/LogVol00) 3a. cd /mnt 3b. mkdir sysimage 3c. mount /dev/VolGroup00/LogVol00 ./sysroot 4. Mount your boot partition: (In my case /dev/sdb1) 4a. mount /dev/sdb1 ./sysroot/boot All the above I already knew, here is where it got interesting (and frustrating getting to this point): 5. Mount w/ bind the /dev from your rescue system to your problem system 5a. mount --bind /dev ./sysroot/dev 6. Go into the chroot environment 6a. chroot sysroot 7. Mount /proc and /sys 7a. mount /proc 7b. mount /sys 8. Now we should be ready to run mkinitrd 8a. cd /boot 8b. mkinitrd -v -f initrd-$(kver).img $(kver) # where $(kver) is the full kernel name (i.e. 2.6.27.19-170.2.35.fc10_x86_64) or something like that Make sure you update grub.conf if you use an initrd name that's not already setup in it. Some other thoughts about hardware upgrades: Both machines I upgraded the ethernet changed to "eth1" but I'm not sure where to get rid of the old settings but it's working so I may leave it alone. Maybe there could be some sort of hardware upgrade helper to help with this process? It could install itself on your system as a rescue image to help walk you though the process like preupgrade but for hardware. Richard -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
