While working with default partitioning plan ie. Guided partitioning, we might end up facing lots of issues. It creates / partition under LVM volume which makes it hard to recover the Operating system and other data stored in it as we couldn’t get into rescue mode. The reason behind this is, rescue mode fails to identify the root partition without identifying the LVM partition first.
Here is an Excellent How-To which helped me mount and recover some valuable documents on LVM partition with the help of an another system which had the similar partitioning plan. (I have tested this on CentOS and it rocks)
Scenario: You have a hard disk from one Linux computer, and you want the data off of it. So you attach it to another Linux machine. But, all hell breaks loose because both hard disks have the same Fedora default Logical Volume Management (LVM) configuration, same volume names, etc. so you can’t mount them both at the same time. What to do?
This how-to documents one possible method which worked for us, but may not necessarily be the best. For example purposes, it assumes that, to begin with, both host’s LVM groups are named “VolGroup00″, and that our approach is to rename the host’s boot disk, leaving the secondary attached drive (the one we want to recover) untouched.
boot disk’s volume groups (and the booting-related cleanup that follows), whereas renaming the second disk would be fewer steps (if you don’t anticipate trying to use it as-is in another machine). –>
- With the secondary, to-be-recovered drive NOT attached, boot the Fedora Core installer disk into rescue mode (“linux rescue”). When offered the chance to auto-detect and mount drives, select “skip.”
- At the root shell, type:
lvm
and you will be in the Logical Volume Management shell. Then:
vgscan
The output will look something like this:
Reading all physical volumes. This may take a while... Found volume group "VolGroup00" using metadata type lvm2
Now:
vgrename VolGroup00 VolGroup99
We have now renamed the boot device’s volume group to something other than VolGroup00. Exit lvm.
- Make a mountpoint with the same hierarchy as your newly-named group, and mount the logical volume containing your / partition:
mkdir -p /mnt/VolGroup99/LogVol00 mount -t ext3 /dev/VolGroup99/LogVol00 /mnt/VolGroup99/LogVol00
- Now, note that if your initial install created a separate /boot partition (which it probably did, for Fedora default install), then you will need to mount that as well, in the old-fashioned way:
mkdir /mnt/hda1 mount /dev/hda1 /mnt/hda1
Note that this assumes the usual, a single IDE hard disk. If you’re unsure of which partition contains /boot, run
fdisk /dev/hda p (for print)
The first, and smallest, partition with the asterisk in the Boot column is the one. Note the device name and mount that as noted above. E.g. if your disk is SCSI, it will probably be /dev/sda1.
- Now make the requisite edits to /etc/fstab and /etc/grub.conf. In fstab, find the lines:
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1 ... /dev/VolGroup00/LogVol01 swap swap defaults 0 0
and change them to:
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1 ... /dev/VolGroup99/LogVol01 swap swap defaults 0 0
NOTE: “Joe” writes: “in Step 5, I think you meant:
... and change them to: /dev/VolGroup99 ... ^^ this was 00
He is probably right…I no longer remember! Govern yourself accordingly.
Then in /boot/grub/grub.conf, fine the line:
kernel /vmlinuz-2.6.19-1.2911.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet acpi=off
and change it to
kernel /vmlinuz-2.6.19-1.2911.fc6 ro root=/dev/VolGroup99/LogVol00 rhgb quiet acpi=off
Of course, your vmlinuz version and other kernel arguments may differ.
- Delete or rename the lvm config’s cache file:
rm /etc/lvm/.cache
- Now, fix initrd. This is the ugliest part of the process, but it looks more complicated than it is. Basically, the initrd image (init RAM disk) that Fedora creates at the time of initial install, contains hard-coded references to your logical volume group(s). So you need to edit those, and it’s multiple steps because the initrd is a disk image in gzipped archive format. Soooo….thanks to someguy’s howto [url]:
cd /mnt/hda1 mkdir newinit cd newinit gunzip -c ../initrd-2.6.9-1.724_FC3.img | cpio -idmv # or whatever initrd version file you have
Once that finishes, you’ve got an unpacked version of the initrd. Edit the “init” file, which is a nash script (NOT a normal bash shell script, so don’t get cute with bash stuff). Find all instances of “VolGroup00″ and change them to “VolGroup99″. Save and exit.Then, repackage up a new image. First rename the original one out of the way to save it so you can restore it later if need be. Then, still within the “newinit” directory, do:
find . | cpio --quiet -c -o > ../newinitrd cd .. # You are now in /boot, aka /mnt/hda1 gzip -9 < newinitrd > initrd-2.6.9-1.724_FC3.img # or whatever it was called before...EXACTLY
- Type
sync unmount /mnt/hda1 unmount /mnt/VolGroup99/LogVol00 sync
Exit the shell to reboot. If all goes well…your system should boot up normally.
- Now (whew!), you can finally (try to) mount that secondary hard disk. Attach it (reboot if necessary) and do:
lvm (to enter lvm shell) vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup99" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2
Remember, 99 is your newly-renamed, main, boot drive. VolGroup00 is the secondary, to-be-recovered drive.Still in the lvm shell, type:
vgchange --available y 2 logical volume(s) in volume group "VolGroup99" now active 2 logical volume(s) in volume group "VolGroup00" now active
Exit lvm and do:
mkdir -p /mnt/VolGroup00/LogVol00 mount -t ext3 /dev/VolGroup00/LogVol00 /mnt/VolGroup00/LogVol00
and your secondary disk’s contents should now be available under that mountpoint.
NOTE: “Joe” writes: “to get /dev/VolGroup99/LogVol00 to appear, I had to do a vgscan and vgchange -ay after the vgrename. I guess I probably could have skipped the vgscan, but it made me feel good to see that the rename succeeded.”
Source: https://www.whoopis.com/howtos/linux_lvm_recovery.html