LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   Lvm luks partition recover (https://www.linuxquestions.org/questions/linux-hardware-18/lvm-luks-partition-recover-4175486881/)

naguera 12-04-2013 03:46 PM

Lvm luks partition recover
 
Hi there, this is my first post in this community and I hope to find any solution to my problem. In short, I'm not able to rescue/recover or mount my /home directory. What happend, I've installed Wheezy beta 2 if I'm not wrong a couple of months before it become stable, everything worked fine since now. My pc is equiped with a hybrid hdd 500gb + 32Gb ssd. When installed I decided to use encrypted LVM for the whole disk (hdd+ssd) and placed root+boot in the 32Gb ssd disk (/sda) and /home+swap in the 500Gb hard drive (/sdb). Everything has worked perfectly till 2 weeks ago when, while running on battery, the pc hybernate itself after some of inactivity time (this wasn't the first time and everytime I was able to start the pc, enter the passphrase and became running again with the previous session). This wasn't happend last time... after bios post (AHCI configured) I see a simple white cursor blinking on the top left corner. I tryed to remove battery and remove ram just to be sure it wasn't a "suspend on ram" issue but nothing. Running the live Wheezy (7.2) from dvd revealed many strange things (at last for me since I am noob on linux). I'm able to mount the lvm volume and read (whithout passphrase!) both Root and Boot partitions, so far I was happy but the whole 500Gb hard drive is shown as UNALLOCATED meaning that I cannot access any data inside it. I wasn't able to mount it in any way. After googling a while and tried some solutions I finally decided to ask your help. I really need to recover that data...

I found on this community two very similar issues (1st & 2nd) but to be honest I was not able so far to follow/test them since I am quite new on Linux and I'm afraid to lose everything if I follow my mind...

Steps taken so far following google and suggestions out there:

Code:

# fdisk -l /dev/sd?
 
Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0009ae15
 
  Device Boot      Start        End      Blocks  Id  System
 
Disk /dev/sdb: 32.0 GB, 32017047552 bytes, 62533296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Code:

# blkid   
/dev/sdb1: UUID="ha8wp9-wBzY-mjlm-gHut-gYIU-jQs7-7V71sR" TYPE="LVM2_member"
/dev/loop0: TYPE="squashfs"
/dev/sda: PTTYPE="dos"
/dev/sr0: UUID="2013-10-27-17-47-46-00" LABEL="sysrcd-3.8.1" TYPE="iso9660"
/dev/mapper/OS-BOOT: LABEL="BOOT" UUID="2efc42ae-23db-4a86-8f97-b2654ff52378" TYPE="ext4"
/dev/mapper/OS-ROOT: LABEL="ROOT" UUID="0d1ec7c2-a37a-49c7-91bd-6d90aa8d41c8" TYPE="ext4"

Code:

root@debian:~# cryptsetup luksOpen /dev/sda my500
Device /dev/sda is not a valid LUKS device.
root@debian:~# cryptsetup luksOpen /dev/sda1 my500
Enter passphrase for /dev/sda1:
Requested offset is beyond real size of device /dev/sda1.

Code:

root@debian:~# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=    2048, size=    4096, Id=83, bootable
/dev/sda2 : start=        0, size=        0, Id= 0
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

Code:

Tue Dec  3 13:14:57 2013
Command line: TestDisk /log /debug /dev/sda

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.2.0-4-amd64 (#1 SMP Debian 3.2.51-1) x86_64
Compiler: GCC 4.6
Compilation date: 2012-01-17T14:04:23
ext2fs lib: 1.42.5, ntfs lib: 10:0:0, reiserfs lib: none, ewf lib: none
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - ST500LT012-9WS142, S/N:S0V0GR60, FW:0001SDM1

Partition table type (auto): Intel
Disk /dev/sda - 500 GB / 465 GiB - ST500LT012-9WS142
Partition table type: Intel

Analyse Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63
Geometry from i386 MBR: head=98 sector=33
Current partition structure:
 1 * Linux                    0  32 33    0  97 33      4096
Computes LBA from CHS for Disk /dev/sda - 500 GB / 465 GiB - CHS 60802 255 63
Allow partial last cylinder : Yes
search_vista_part: 1

search_part()
Disk /dev/sda - 500 GB / 465 GiB - CHS 60802 255 63

    Linux                    0  32 33    0  97 33      4096
    LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

    Linux                1945  31  7  1945  96  7      4096
    LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

recover_EXT2: s_block_group_nr=0/239, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 7864064
recover_EXT2: part_size 62912512
    Linux                36160 141 14 40076 172 32  62912512
    EXT4 Large file Sparse superblock Recover, 32 GB / 29 GiB

Results
  * Linux                    0  32 33    0  97 33      4096
    LUKS 1 (Data size unknown), 2097 KB / 2048 KiB
  P Linux                1945  31  7  1945  96  7      4096
    LUKS 1 (Data size unknown), 2097 KB / 2048 KiB
  P Linux                36160 141 14 40076 172 32  62912512
    EXT4 Large file Sparse superblock Recover, 32 GB / 29 GiB

interface_write()
 1 * Linux                    0  32 33    0  97 33      4096
 2 P Linux                1945  31  7  1945  96  7      4096
 3 P Linux                36160 141 14 40076 172 32  62912512
simulate write!

write_mbr_i386: starting...
write_all_log_i386: starting...
No extended partition

TestDisk exited normally.

I would really appreciate any kind of suggestions on how to preceed further and... remember I am noob :-P
Thanks in advance

rknichols 12-04-2013 10:34 PM

Apparently the root and boot partitions were not encrypted since you were able to read them without a password. The results from testdisk are inconsistent with everything on sdb being encrypted. I'm seeing what look like 2 LUKS partitions (16GB and 280GB), an unencrypted ext4 partition (32GB), and about 160GB of unallocated space. The good news is that with access to the root partition you should be able to look in /etc/lvm/backup and find files there that detail the LVM layout on sdb. If you would post the relevant file (as an attachment if you can -- your low post count might not permit that), that information would help confirm the correct partitioning of sdb.

FYI, testdisk always reports the size of LUKS partitions as just the size of the LUKS header plus key material since it has no way to determine the size of the payload.

naguera 12-05-2013 03:49 AM

Quote:

Originally Posted by rknichols (Post 5075701)
The good news is that with access to the root partition you should be able to look in /etc/lvm/backup and find files there that detail the LVM layout on sdb.

A new hope :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D

Here is the content of sda

Code:

# # Generated by LVM2 version 2.02.95(2) (2012-03-06): Mon Oct 14 23:57:20 2013

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgcfgbackup'"

creation_host = "pc-name"        # Linux pc-name 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64
creation_time = 1381787840        # Mon Oct 14 23:57:20 2013

DATA {
        id = "Vj6zCI-TzO1-9rma-8dJT-Ba11-cWWe-uj9XJ0"
        seqno = 3
        format = "lvm2" # informational
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192                # 4 Megabytes
        max_lv = 0
        max_pv = 0
        metadata_copies = 0

        physical_volumes {

                pv0 {
                        id = "n1IQTm-7GlV-hyqh-o0Uc-OShS-tLl8-xJmpjK"
                        device = "/dev/dm-1"        # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 976764928        # 465,758 Gigabytes
                        pe_start = 2048
                        pe_count = 119233        # 465,754 Gigabytes
                }
        }

        logical_volumes {

                SWAP {
                        id = "g5Pu9d-L1tc-PDn8-5H1w-izOl-C1GP-1XWE2F"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_host = "pc-name"
                        creation_time = 1366017371        # 2013-04-15 11:16:11 +0200
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 3814        # 14,8984 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                }

                DATA {
                        id = "67EzJp-50Vw-OA50-EsKh-pp1o-6h5g-3E9bhc"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_host = "pc-name"
                        creation_time = 1366017378        # 2013-04-15 11:16:18 +0200
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 115419        # 450,855 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 3814
                                ]
                        }
                }
        }
}

I'll wait for your next invaluable suggestion!
Thanks again.

rknichols 12-05-2013 11:32 AM

Excellent! That is showing a single physical volume using essentially the entire disk, so there must in fact be just one encrypted partition. I would guess that the encrypted partition had never been filled with random data, and the other stuff that testdisk found was just left over from previous use of the drive.

For safety, you should save at least the first 10 megabytes or so of the drive on a file, perhaps on your old root partition:
Code:

mkdir -p /mnt/oldroot
mount /dev/sda1 /mnt/oldroot
dd if=/dev/sdb bs=1M count=10 of=/mnt/oldroot/sdb-head.img

That assumes that your old root partition was on /dev/sda1 -- adjust as necessary.

Then I would use fdisk to first delete the existing partitions, write out that empty partition table, and then run fdisk again in sector units mode (a recent version should default to that -- use the "u" command if yours does not) to create a single partition starting at sector 2048 (should be the default) and extending to the end of the disk (again, should be the default). You are affecting only the partition table and not messing with any extended partition, so this operation should be safe. Just be absolutely certain that you run fdisk on the whole drive, "fdisk /dev/sdb", and not on a partiton (/dev/sdb1). Do not use parted, gparted, or any other higher-level partitioning tool. Those will want to format the partition for you, and that would be fatal. You should then be able to unlock the encrypted partition and then access the LVM logical volumes within. You might need to run pvscan to pick up the LVM structure, though that might happen automatically when you unlock the partition.

The reason for running fdisk twice is so that the the partition creation will be from a clean start and not picking up any bogus geometry from the current partition table.

naguera 12-06-2013 07:46 AM

:banghead::banghead::banghead::banghead::banghead:

I followed everything carefully but there must be something wrong with the results... Everything gone fine, I was able then to enter the passphrase both using cryptsetup luksOpen and from the GUI (Caja and gnome-disk-utility) anyway I'm not able to mount the filesystem, Mate fm said "the unlocked device does not have a recognizable file system". Here are commands I issued and the results... please help me :(

Code:

lmdemate64 naguera # fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009ae15

  Device Boot      Start        End      Blocks  Id  System
/dev/sdb1            2048  976773167  488385560  83  Linux
lmdemate64 naguera # fdisk -l /dev/sdb1

Disk /dev/sdb1: 500.1 GB, 500106813440 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976771120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe8070000

Disk /dev/sdb1 doesn't contain a valid partition table

Code:

lmdemate64 naguera # cryptsetup luksOpen /dev/sdb1 restore
Inserire la passphrase per /dev/sdb1:
lmdemate64 naguera # pvscan -v
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
    Walking through all physical volumes
  PV /dev/mapper/restore  VG DATA  lvm2 [465,75 GiB / 0    free]
  Total: 1 [465,75 GiB] / in use: 1 [465,75 GiB] / in no VG: 0 [0  ]

Should I create also the original SWAP and DATA partitions inside /dev/sdb1?

naguera 12-06-2013 08:38 AM

I finally was able to enter the data partition :)... I'm so happy that I don't know how to explain :)...

Anyway, I got it work simply looking better into gnome-disk-utility, on the left menu, by default, I see "Devices" where usually I go when I have to do something like open a disk, mount or encrypt a volume (and format etc.), what I mess was above "Devices", I found another item I never noted before (noob) saying "Multi-Disk Devices" and immediately below "DATA - Logical Volume LVM2" and finally was there where I was able to mount definetively my lost lucks lvm partition LOL... I think I miss something at command line after cryptosetup luksOpen... don't really know, I have to study more..

I would like to say a BIG THANK YOU to rknichols, infact, without his help I would still be crying.

Anyway, I would be very happy to know exactly what I should have had to do into command line to have the same results of the GUI...

rknichols 12-06-2013 08:44 AM

Quote:

Originally Posted by naguera (Post 5076466)
Code:

lmdemate64 naguera # cryptsetup luksOpen /dev/sdb1 restore
Inserire la passphrase per /dev/sdb1:
lmdemate64 naguera # pvscan -v
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
    Walking through all physical volumes
  PV /dev/mapper/restore  VG DATA  lvm2 [465,75 GiB / 0    free]
  Total: 1 [465,75 GiB] / in use: 1 [465,75 GiB] / in no VG: 0 [0  ]

Should I create also the original SWAP and DATA partitions inside /dev/sdb1?

Good ${Deity}, NO!! That would destroy everything.

Your original volume groups and logical volumes should now be available. See what "lvs" reports. Here is an example (your names will be different):
Code:

# lvs
  LV    VG      Attr  LSize  Origin Snap%  Move Log Copy%  Convert
  lvol0 oldtapes -wi-a- 20.00g                                     
  lvol1 oldtapes -wi-a- 18.00g

For my case, both of those are file systems:
Code:

# blkid /dev/oldtapes/*
/dev/oldtapes/lvol0: LABEL="oldroot" UUID="9c65bbb3-56a3-4ef0-832d-a02c5e997f7e" TYPE="ext4"
/dev/oldtapes/lvol1: UUID="701c3034-00c2-4191-ad4a-27f1c0a350c7" TYPE="ext4"

You should see your DATA file system and your swap space (blkid won't report anything for swap space). You should be able to fsck and mount the DATA file system, e.g.:
Code:

# fsck -n -f /dev/oldtapes/lvol0
fsck from util-linux-ng 2.16.2
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
oldroot: 183504/1310720 files (0.1% non-contiguous), 1763525/5242880 blocks
# mount -r /dev/oldtapes/lvol0 /mnt/tmp
# ls /mnt/tmp
bin  boot  c  etc  lib  lost+found  media  mnt  root  sbin  selinux  srv  usr  var

For the first look, I recommend using the "-n" option to keep fsck from trying to repair anything and a read-only (-r) mount. Hopefully, everything will be fine, and you can now boot and run your system normally (and perhaps even make a backup!).

naguera 12-06-2013 09:09 AM

You was probably replying to my second-last post when I posted the latest btw I'm currently backing up data into a safe place (390Gb of family and corporate data), then I will try absolutely the command lvm and the mount again just to be sure to learn what you have just teached me... Thanks again, your help was really appreciate.

PS. I like very much your signature and so I just copied-paste into my Skype status... It is true, I'm backing up on daily basis at least 10TB of corporate data (I'm an IT man working on MS environment), but most of the time you realize the importance of things only after you've lost, this does not justify what I have failed to do, but from now on I'll stay definitely much more careful! :)

rknichols 12-06-2013 09:31 AM

With encryption in particular, it is very easy for a single mistake or glitch to result in permanent and unrecoverable loss of all data. Besides backup, I recommend looking at the "luksHeaderBackup" function of the cryptsetup command. Don't be too concerned about the warning about protecting this file. Remember that anyone who has ever had access to the physical encrypted device has also had an opportunity to copy that header.


All times are GMT -5. The time now is 12:39 PM.