lvm2 recovery of failing hard drive image


I have an old IDE based laptop which has just stopped booting, running openSUSE-12.2 (32 bit). The harddrive seems
to have developed a bad sector and the boot sequence hangs at the point where is says something like “doing fast boot, creating devices with udev” (which never was particuarly fast). There are some recent files that are not sync’d, so I’d to try and recover the data.

Running smartctl (after the event), reported imminent hard drive failure. I’ve pulled the harddrive and taken a full image of the disc’s three partitions /boot, Windows and LVM2 - I would infrequently boot to Windows (proprietary accounting package) and ironically that partition boots fine, so I could carry on working by nx’ing into my desktop at work.

I used dd_rescue (what a great tool) to make the image of the lvm2 partition, and it reported a 2.5KiB continuous error, so I guess it is just one bad sector in 192GiB. I’ve also backed up that image :-). The lvm2 partition had the root filesystem, swap and an encrypted home directory.

I’ve mounted the lvm2 image on my 64bit 12.2 desktop, by doing:

modprobe -r loop && modprobe loop max_part=63

losetup /dev/loop0 sde3.rhp

lvm pvscan

PV /dev/md1 VG system lvm2 [931.33 GiB / 303.33 GiB free]
PV /dev/loop0 VG system lvm2 [192.80 GiB / 25.85 GiB free]

But at this point I see a problem, the volume group has the same (default) name as one of my groups on my desktop - which I don’t want to hose in the process of trying to recover. Can anyone suggest a safe way to proceed? I’m not to familiar with managing lvm as I’ve been lazy and left yast do it - I was expecting to be able to fsck the LV’s and mount the crypto home partition and then read/rsync the data off. I suppose I could work on the raw disc from a Rescue CD, but I’d prefer to get comfortable with the image, just in case I trigger any further dud sectors.


Use vgs to display VG UUID (e.g. “vgs -v”) and use vgrname to rename group based on UUID. From man page:

       Changes the name of the Volume Group with UUID
       Zvlifi-Ep3t-e0Ng-U42h-o0ye-KHu1-nl7Ns4 to VolGroup00_tmp:

       vgrename Zvlifi-Ep3t-e0Ng-U42h-o0ye-KHu1-nl7Ns4 VolGroup00_tmp

Thanks for the pointer, it was plain sailing form there.

In case anyone else is flayling about with this in the future, after the vgsrename, it was a simple matter of checking the filesystem image and then mounting. In my case:

losetup /dev/loop0 sde3.rhp

lvm pvscan

vgs -v

vgrename eGkbx0-eLZD-wBSg-3f9y-L6vE-9Ibx-XdMRXJ laptop_system

vgchange -ay

lvs #to see the LV’s of root, swap, home, and encrypter home/user1

fsck /dev/laptop_system/root #fix the issues here

mount /dev/mapper/laptop_system/root /tmp/failing_hdd

cat /tmp/failing_hdd/etc/crypttab

cryptsetup luksOpen /dev/laptop_system/user1 cr_user1

mount /dev/mapper/cr_user1 /tmp/failing_hdd/home/user1

I was then able to confirm that there were hardly any files out of sync, but I can sleep much easier being certain that I hadn’t lost anything important.