Re: Hardware upgrade -> Volume Group "VolGroup00" not found. [SOLVED]

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

 



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

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux