Windows (or more specifically, the Acer eRecovery tool) messed up my boot partition on my dual boot system (Windows 7 and Fedora 18). I have a Windows partition (sda1, sda2 and sda3) and LVM encrypted partitions (sda4), which include a home, boot (unencrypted), swap and root partition. (There is also a separate data partition that is also encrypted and was on sda5)

When I typed "ls", the answer was:
grub rescue> ls
(hd0) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1)

When I typed lvdisplay, vgdisplay, or lvscan, the answer was: No volumes groups found.

Because I could not find or mount the encrypted LVM partitions anymore, I then started testdisk.

Before using testdisk, fdisk showed this output:

fdisk -l
Device --- Boot ---Start--- End--- Blocks--- Id ---System
/dev/sda1 ---2040 ---31459327--- 15728640 ---27--- Hidden--- NTFS ---WinRE *Windows*
/dev/sda2 ---*--- 31459328 ---31664127 ---102400--- 7--- HPFS/NTFS/exFAT *Windows Acer eRecovery*
/dev/sda3 ---31664128--- 502896639--- 235616256 ---7 ---HPFS/NTFS/exFAT *Windows main partition*
/dev/sda4 ---502896640 ---1465149167 ---401126264--- 5--- Extended *I believe the LVM partitions should be here*
/dev/sda5 ---614004736 ---1465147391--- 425571328 ---83 (this is just a data partition, no Operating System)

I then used testdisk, which showed this partition table:

fdisk -l
Device ---Boot ---Start--- End--- Blocks--- Id--- System
/dev/sda1 ---2040 ---31459327 ---15728640 ---27--- Hidden NTFS WinRE
/dev/sda2--- *--- 31459328 ---31664127 ---102400--- 7--- HPFS/NTFS/exFAT
/dev/sda3--- 31664128--- 502896639--- 235616256 ---7 ---HPFS/NTFS/exFAT
/dev/sda4--- 502898760 ---1465160129 ---481130685 ---f W95 Ext'd (LBA)
/dev/sda5 ---502900736 ---503924735--- 512000--- 83--- Linux
/dev/sda6 ---503926784 ---503930879 ---2048 ---83--- Linux
/dev/sda7--- 614004736--- 614008831 ---2048 ---83 ---Linux

(Testdisk seemed to have moved the sda5 data partition to sda7 and to put the sda 4 extended partition to sda4, sda5 and sda6.)

I then wrote this partition table to the MBR with testdisk.

As a result, I seem to have lost my original sda5 data partition, which I cannot open/decrypt anymore.
When I now run cryptsetup luksOpen on sda6 and on sda7, I can enter the password for the root partition of Fedora 18 at sda6 and the password for the data partition (which was before on sda5) on sda7. But I get the error message:Requested offset is beyond real size of device" and I cannot open the encrypted partitions.

Testdisk also showed this:

Disk /dev/sda 750 GB 698 GiB CHS 91202 255 63
The harddisk (750GB/698 GiB ) seems too small. (<2878GB/2680 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection....

The following partitions can't be recovered:
Partition Start End Size in sectors
FAT16 <32M 241432 55 6 349921 45 32 1742875182
FAT32 LBA 264128 56 24 32533 15 8 954338727

Continue
892 GB
488 GB

HPFS NTFS 0 32 33 1958 64 26 31457280 PQSERVICE
HPFS NTFS 1958 64 27 1971 0 13 204800 SYSTEM RESERVED
HPFS NTFS 1971 0 14 31303 221 22 471232512 ACER
LINUX 31367 252 54 31368 62 54 4096 (this could be the Fedora livecd)
LINUX 38220 6 59 38220 71 59 4096 (this could be the Fedora livecd)

Current Partition structure
Partition Start End Size in sectors
1 * HPFS NTFS 0 32 33 1958 64 26 31457280 PQSERVICE
2 P HPFS NTFS 1958 64 27 1971 0 13 204800 SYSTEM RESERVED
3 P HPFS NTFS 1971 0 14 31303 221 22 471232512 ACER
4 E extended LBA 31304 0 1 91201 254 63 962261370
5 L Linux 31304 31 24 31367 220 21 1024000
X extended 31367 251 1 31368 62 54 4212
6 L Linux 31367 252 54 31368 62 54 4096
X extended 8220 5 1 38220 71 59 4217
7 L Linux 38220 6 59 38220 71 59 4096

Now my questions are:
1. Is it possible to revert the changes that testdisk did to the partition table, so I can at least open again the data partition (the original sda5 partition)?
2. Is it possible with testdisk that I recover the encrypted LVM partitions?

To both questions: No.

Nevertheless, don't write anything else onto this disk!

How did you encrypt the LVM partitions? And have the encrypted LVM partitions (partially) been overwritten, too?

1 members found this post helpful.

The setup of the encrypted LVM partitions was done automatically by the Fedora 18 installer.

The Acer eRecovery tool overwrote the MBR partition, I'm not sure if it also did damage to the other partitions in the short time before I shutdown the computer. I should not have done anything like this as I only clicked on exit, but since I was not able to mount or find anything, maybe it did.

So I cannot revert the changes testdisk did, even if I have the output from fdisk above?

You can make the partitioning look like it did, but nothing can recover the sectors that testdisk overwrote when you told it to write out the new partitioning. The problem occurs only with extended partitions, and is due to the Extended Boot Record (aka secondary partition table) that precedes each logical drive in the extended partition. When testdisk wrote those EBRs ahead of what it believed were your logical drives, whatever data was previously in those sectors was permanently lost. If that happened to be some of the key data for one of your LUKS encrypted partitions, that partition is now unrecoverable.

1 members found this post helpful.

Well, as far as I know Fedora first creates a LUKS container and the LVM within this LUKS container. If this is the case, then there is a chance to get your data back, if the partitions themselves have not been overwritten.

The problem is there is no software that does it automagically.

1 members found this post helpful.

Do you know how it could be done? I tried to mount and "cryptsetup luksOpen" most of what I saw under /dev/*.

As I wrote above, "cryptsetup luksOpen" seems at least to recognize the password for sda6 and sda7, but there is an error that the "Requested offset is beyond real size of device". And the LVM commands I tried said that no volume groups were found.

I have added some more output about this here http://pastebin.com/C3vuUZE8

Using testdisk, I could access the boot partition. The relevant configuration files were overwritten, but I think "vmlinux" and other files could still be seen.

Could I use testdisk to write a new partition table, so that I can at least recover the original encrypted partition sda5, which is not a LVM volume?

If cryptsetup recognizes the password, then you have the correct starting points. You just adjust the endpoints to make sda6 and sda7 as large as possible. Make sda6 end at sector 614004735, which is just before the start of sda7. Make sda7 extend to sector 1465149167, which is the end of the disk.

1 members found this post helpful.

Wow, thanks. I have recovered the data partition (originally partition sda5, or sda7 in your last post).

Now I still need to recover the LVM partitions, if it is at all possible.

When I try to add another partition (for the encrypted LVM volumes) with fdisk, I get the error: Value out of range.

I'm trying to add this partition
/dev/sdaX ---502,896,640 ---614,004,735 ---401,126,264---

At the moment, my partition table looks like this
sda1 2048------ 31459327 ------15728640 7
sda2 31459328 ------31664127 ------102400 7
sda3 31664128 ------502,896,639 ------235616256 7
sda4 502,898,760 ------1465160129------ 481130685 f W95 Extednd LBA
sda5 502,900,736 ------503924735------ 512000 83
sda6 503926784 ------503930879 ------2048 83 linux
sda7 614004736------ 1465149167 ------ 425572216 83 linux

I deleted the other partitions in the partition table and then created the partition for the extended encrypted LVM partition.

/dev/sda4 ---502,896,640 (I also tried 502900736 and 503926784) ---614,004,735 ---401,126,264--- 5--

But when trying to run cryptsetup on it, it tells me it's not a valid LUKS device.

Do you know what could be wrong?

Of course not. 502896640 is nothing like the correct starting point. 502900736 is close, but now you are trying to create a primary partition (sda4) to access the area that was formerly a logical drive (sda5). The actual start of data for a logical drive is offset to allow space for the Extended Boot Record I mentioned previously plus padding to align the start of data correctly. It looks like your disk was previously partitioned with 1-Megabyte (2048 sectors) alignment, so try 502902784 (502900736+2048).

I hope you are not still trying this on your original disk with no backup copy. You are really playing with fire here, and could very easily lose your encrypted data permanently.

[EDIT] But how was your LVM set up? Is this partition an encrypted container with an LVM physical volume within it? Or, was this an LVM physical volume with one or more encrypted logical volumes in it? If the latter, then after creating the partition with the correct starting point, you would need to get LVM to recognize the physical volume. If you make the partition type 8E (Linux LVM), the kernel should pick up the volume automatically. Otherwise, you might need to run pvscan, which will scan all disks for LVM physical volumes.

1 members found this post helpful.

I am not sure how the LVM was set up, Fedora was doing the setup automtically. Cyberpatrol wrote above: "Well, as far as I know Fedora first creates a LUKS container and the LVM within this LUKS container. If this is the case, then there is a chance to get your data back, if the partitions themselves have not been overwritten."

I am using fdisk to create and delete the partitions. Should I be creating an extended or primary partition with fdisk?

I'm doing this on the original disk. I risk losing three weeks of my home folder data, which is annoying but maybe also a lesson (to make more frequent backups), and backing up the whole HDD (750 GB) so that it can be reused is not so straightforward.

Do you know if the end-of-partition number (-614,004,735 -) is correct, or should I also try other values?

It's safer to work with primary partitions, since that way the only writes are to the primary partition table in the MBR.

As long as the partition is at least of sufficient size to hold the LVM / LUKS structures, the exact endpoint doesn't matter.

1 members found this post helpful.