LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices


Reply
 
Search this Thread
Old 12-04-2013, 03:46 PM   #1
naguera
LQ Newbie
 
Registered: Dec 2013
Location: Italy
Distribution: Debian, Mint, CentOS, FreeBSD
Posts: 6

Rep: Reputation: Disabled
Question 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
 
Old 12-04-2013, 10:34 PM   #2
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,880

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
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.
 
Old 12-05-2013, 03:49 AM   #3
naguera
LQ Newbie
 
Registered: Dec 2013
Location: Italy
Distribution: Debian, Mint, CentOS, FreeBSD
Posts: 6

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
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.
 
Old 12-05-2013, 11:32 AM   #4
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,880

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
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.
 
1 members found this post helpful.
Old 12-06-2013, 07:46 AM   #5
naguera
LQ Newbie
 
Registered: Dec 2013
Location: Italy
Distribution: Debian, Mint, CentOS, FreeBSD
Posts: 6

Original Poster
Rep: Reputation: Disabled


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?

Last edited by naguera; 12-06-2013 at 07:49 AM.
 
Old 12-06-2013, 08:38 AM   #6
naguera
LQ Newbie
 
Registered: Dec 2013
Location: Italy
Distribution: Debian, Mint, CentOS, FreeBSD
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thumbs up

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...
 
Old 12-06-2013, 08:44 AM   #7
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,880

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
Quote:
Originally Posted by naguera View Post
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!).
 
1 members found this post helpful.
Old 12-06-2013, 09:09 AM   #8
naguera
LQ Newbie
 
Registered: Dec 2013
Location: Italy
Distribution: Debian, Mint, CentOS, FreeBSD
Posts: 6

Original Poster
Rep: Reputation: Disabled
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!
 
Old 12-06-2013, 09:31 AM   #9
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,880

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
recover lost luks partition ehsdav Linux - General 10 07-09-2013 04:50 AM
[SOLVED] recover from deleted luks encryption partition unixedway Linux - General 9 07-07-2013 01:49 PM
A pondering about Encrypting the Keycard for a LUKS/LVM partition. lumak Slackware 3 08-15-2010 02:15 PM
Recover LVM partition in Suse Linux Sarah_Student Linux - Software 1 05-10-2010 06:44 AM
Recover encrypted LUKS partition itinlopez Linux - General 3 11-30-2008 02:20 AM


All times are GMT -5. The time now is 10:56 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration