LVM data recovery needed - Quantal Quetzal toasted my partition table

[AssureTech]

I am currently running CentOS 6.x on my primary workstation. I want to replace CentOS with Ubuntu after I found that Ubuntu has better driver support and software repositories.

I booted up my workstation with the latest Ubuntu 12.10 Live to test and see if Ubuntu will recognize my CentOS encrypted luks container and determine whether or not I can replace CentOS with Ubuntu. My system root and home partitions are logical volumes stored in a luks container that was originally created with Red Hat's Partitioning Tool.

I discovered that Ubuntu's Partitioning Tool does not recognize Red Hat's encrypted luks container and will not allow Ubuntu to be installed onto an existing logical volume. Instead of recognizing Red Hat's partition scheme, Ubuntu's Partitioning Tool tried to recalculate the luks container as "free space". I clicked "revert", but to no avail - the Ubuntu installer had already trashed my partition table. I then clicked "quit" to exit out of the Advanced Partitioning Tool window.

I tried to open the luks container, but Ubuntu's Partitioning Tool resized the container to below the Payload Offset's boundary and therefore the encryption failed. I then used fdisk to recreate the partition table that the luks container is held in, starting at the same cylinder, but with the full size of the original container. I can now successfully use "cryptsetup luksOpen /dev/sda2 crypt" to open the luks container, but my logical volumes have vanished (/dev/mapper/crypt is detected as "unknown"). All my critical data stored on my home partition is unavailable.

Can someone who is knowledgeable about the ins and outs of Quantal Quetzal's Advanced Partitioning Tool please inform me as to exactly what this partition tool did when it recalculated my luks container as free space and why the "revert" option does not function correctly. It appears this is a serious bug in Quantal Quetzal's Partitioning Tool.

I need someone who is knowledgeable with LVM to walk me through the steps of recovering my logical volumes.

Thanks for any help with this matter.

[AssureTech]

I tried to recover the LVM backup file headers with
dd if=/dev/mapper/crypt bs=512 count=255 skip=1 of=./lvm.recovery but to no avail. I scanned across the entire mounted device with

strings /dev/mapper/crypt | grep "# Generated by LVM" -A 2048 > output.txt and it did not turn up any LVM references. What gives?? What happened to my LVM data? Nothing was written to the disk. When using Ubuntu's Advanced Partitioning Tool, I could not revert the changes, but I did not go ahead with the install, so the only thing that would have happened is rewriting the partition table. What happened to the LVM backup headers?

I also tried
dmsetup create restore-lv --table "0 97656250 linear /dev/mapper/crypt 384" to find the position of the original logical volume (50GB for root and the rest was allocated as home). Then I used

dumpe2fs -h /dev/mapper/restore-lv but all I get is


dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/restore-lv
Couldn't find valid filesystem superblock.

Can someone please let me know what software Ubuntu's Partitioning Tool is using? Is this based on GParted? If so, I will ask this question in the GParted forum.

[darkod]

I can't answer all your questions, but just to remind you that if doing this from ubuntu live mode, it doesn't include the lvm2 package in it. You have to install it into live mode first (and repeat that every time you reboot unless you have usb with persistance):

sudo apt-get install lvm2

You activate all VGs and LVs with:

sudo vgchange -ay

Apart from your encryption, that's the only way I know to manipulate LVM from ubuntu live mode. Maybe that't the missing link. The LVs are not available immediately in /dev/mapper/... without adding the package and activating them.
Also for reference, you can use them as /dev/VGname/LVname without the mapper in between. Otherwise it should be something like /dev/mapper/VGname-LVname. I find the first easier to manage.

[darkod]

Are you sure the fdisk procedure was the correct one? I would usually recommend testdisk to recover partitions/table because it scans the disk and shows you what it finds. It doesn't rely on your entering the data manually hoping it's correct.

[AssureTech]

This is the current partition structure after fixing with fdisk:


Partition Start End Size in sectors
1 * Linux 0 32 33 63 221 30 1024000
2 P Linux 63 221 31 60801 80 63 975747120


This is what testdisk shows:


Partition Start End Size in sectors
>* Linux 0 32 33 63 221 30 1024000
P Linux 63 221 31 64 31 31 4096


This is why the encryption initially failed because I originally used testdisk to write a new partition table and it ends on the 4096 Payload Offset boundary. As soon as I used fdisk to recreate the partition table, I was able to access the luks encrypted container.

I have yet to recover the LVM backup headers to restore the logical volumes. Commands such as sudo vgchange -ay do no good since the LVM metadata is gone.

[AssureTech]

Can someone who is knowledgeable about the ins and outs of Quantal Quetzal's Advanced Partitioning Tool please inform me as to exactly what this partition tool did when it recalculated my luks container as free space and why the "revert" option does not function correctly. It appears this is a serious bug in Quantal Quetzal's Partitioning Tool.

This appears to be an undocumented bug in Ubuntu's Partitioning Tool. I am filing a bug report with launchpad to resolve this.