LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 07-03-2013, 05:07 PM   #1
ehsdav
LQ Newbie
 
Registered: Jul 2013
Posts: 6

Rep: Reputation: Disabled
recover lost luks partition


Hi
by very LITTLE(you can't consider) mistake i damaged my 128GB sdd hard partition table.
i wanted to flash bootable iso to usb flash with dd command
"dd if=/somewhere/somelinux.iso of=/dev/sdb bs=1Mb"
but i wrote "of=/dev/sda" (my working opensuse linux :-) or :-( ) not "/dev/sdb" and hit enter
i canceled the process but about 600MB seems copied
at that time nothing seems bad but after restarting my linux not run.
ok
before that i had

1-swap partition about 4GB
2-root fx4 partition about 80GB or 40GB
3-encrypted partition about 40GB or 80GB
4-encrypted partition about 5GB

it seems my heads sector/track cylinders are mistake
now "fdisk -l" of live linux of hirenboot shows
64 heads
32 sector/track
122104 cylinders

output of "fdisk -l" of my friend with excact spec of ssd hard (but ubuntu) was

255 heads
63 sector/track
15566 cylinders

and these values are testdisk defaults when wants to recover my hard.

but i run testdisk and set the size of heads=64 and sector/track=32 and cylinders=122104

P FAT16...........0...9...5......9...17...4.....18688 [GENTOO]
P NTFS.........1234..41...9...1237...42...8......6176 [MINI XP]
P ext4.........2054..63..31..43014...63..30..83886080
P Linux LUKS..43015...0...1..43016...63..32......4096
P Linux LUKS.116746...0...1.116747...63..32......4096

second partition is fake. it is virtual hard of my virtualbox i think.

IS THIS CORRECT OR I SHOUL NOT SET SET heads sector/track cylinders?
how can i grab partiton with my custom value for recover test.
for example i think
P Linux LUKS...43015...0...1.116746...63..32...?
P Linux LUKS..116747...0...1.122104...63..32...?

better i say how should i recover my files?
Thanx lot

Last edited by ehsdav; 07-08-2013 at 06:05 PM. Reason: dont remember
 
Old 07-05-2013, 09:42 AM   #2
David Trest
Member
 
Registered: Jul 2013
Distribution: CentOS/RHEL, Backtrack, many more.
Posts: 58

Rep: Reputation: Disabled
You can't recover them. dd does a bit-by-bit copy. So it will overwrite the first bits as defined in the device. Since you did /dev/sda rather than a partition, it will also end up destroying your partition table too.

You can *try* and mount the system with a LiveCD and look in lost+found, but if you got past 600MB before canceling, it's a good bet that the disk won't appear properly formatted. If you manage to carve up /dev/sda exactly as it was before with fdisk, you might be able to recover some files, but I wouldn't hold out for much.

I'm a little surprised, does the distro's installation instructions say to target the root device, or a partition?
 
Old 07-06-2013, 01:18 PM   #3
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,779

Rep: Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212
Quote:
Originally Posted by David Trest View Post
You can't recover them.
Really???

As long as those partitions were physically located in the same sequence as the entries in the partition table, the LUKS partitions in question start at an offset of about 84GB, which is far beyond the ~600MB you believe you overwrote. As long as you can, by any means, create two partitions that start at the correct locations, you should find the LUKS volumes totally intact. Don't worry too much about the CHS geometry. That is pretty much meaningless, except insofar as partitioning tools will, if told to do so, create partitions that start on "cylinder" boundaries. As long as you have partitions that start at the correct LBA addresses, they will work just fine.
 
Old 07-06-2013, 01:32 PM   #4
David Trest
Member
 
Registered: Jul 2013
Distribution: CentOS/RHEL, Backtrack, many more.
Posts: 58

Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
Really???

As long as those partitions were physically located in the same sequence as the entries in the partition table, the LUKS partitions in question start at an offset of about 84GB, which is far beyond the ~600MB you believe you overwrote. As long as you can, by any means, create two partitions that start at the correct locations, you should find the LUKS volumes totally intact. Don't worry too much about the CHS geometry. That is pretty much meaningless, except insofar as partitioning tools will, if told to do so, create partitions that start on "cylinder" boundaries. As long as you have partitions that start at the correct LBA addresses, they will work just fine.
Yes. I also said as such. In order to even be able to see the correct partitions you'd need to recreate them EXACTLY as they were in fdisk, which is on a cylinder-by-cylinder basis. Unless you have that information, your data is as good as gone. This is also assuming that the data that was overwritten doesn't contain any LUKS headers or LVM metadata.

This is all assuming, of course, that the first 500-600MB of the disk was *only* the boot partition.
 
Old 07-07-2013, 01:48 PM   #5
ehsdav
LQ Newbie
 
Registered: Jul 2013
Posts: 6

Original Poster
Rep: Reputation: Disabled
hi
thank for reply
i was little sick.
i said at that time i did't see anything bad before boot. first encrypted partition was mounted and i was working on it.all files i worked was good an not corrupted.
i think if i can create partition table with excactly specified cylinders or extract it from all hard it can be recover.
P Linux LUKS...43015...0...1.116746...63..32...
P Linux LUKS..116747...0...1.122104...63..32...
according to
http://www.linuxquestions.org/questi...on-4175435883/
but i dont understand exactly what should i do.
 
Old 07-07-2013, 05:59 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
Start by running
Code:
testdisk /debug /log /dev/sda
: proceed > Intel > Analyse > Vista? (No) > Enter > Quit; Quit; Quit, then rename "testdisk.log" to "testdisk.txt" and attach it as plain text file.
 
Old 07-08-2013, 03:41 AM   #7
ehsdav
LQ Newbie
 
Registered: Jul 2013
Posts: 6

Original Poster
Rep: Reputation: Disabled
thanks
but first which one i correct?

64 heads
32 sector/track
122104 cylinders

or

255 heads
63 sector/track
15566 cylinders
 
Old 07-08-2013, 07:01 AM   #8
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,779

Rep: Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212
Neither one bears much relationship to the physical formatting on the disk, where the actual number of sectors per track is variable (more sectors on the physically longer outer tracks). Personally, I'd use the 64H 32S 122104C geometry since it leaves a bit less of the disk space in the incomplete final "cylinder," but it really doesn't matter.
 
Old 07-08-2013, 06:01 PM   #9
ehsdav
LQ Newbie
 
Registered: Jul 2013
Posts: 6

Original Poster
Rep: Reputation: Disabled
Using locale 'LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8'.


Mon Jul 8 23:23:01 2013
Command line: TestDisk /debug /log /dev/sda

TestDisk 6.12, Data Recovery Utility, May 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.0.4-pmagic (#1 SMP Sat Sep 3 17:11:11 CDT 2011) i686
Compiler: GCC 4.5
Compilation date: 2011-05-15T12:36:01
ext2fs lib: 1.41.14, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none
Hard disk list
Disk /dev/sda - 128 GB / 119 GiB - CHS 15566 255 63, sector size=512 - ATA ADATA SX900

Partition table type (auto): None
Disk /dev/sda - 128 GB / 119 GiB - ATA ADATA SX900
Partition table type: Intel

Analyse Disk /dev/sda - 128 GB / 119 GiB - CHS 15566 255 63
Geometry from i386 MBR: head=64 sector=32
check_part_i386 failed for partition type 17
get_geometry_from_list_part_aux head=255 nbr=1
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=1
Current partition structure:
Invalid NTFS or EXFAT boot
1 * hid. HPFS/NTFS 0 0 1 498 213 35 8013824
1 * hid. HPFS/NTFS 0 0 1 498 213 35 8013824

Bad sector count.
Computes LBA from CHS for Disk /dev/sda - 128 GB / 119 GiB - CHS 15567 255 63
Allow partial last cylinder : Yes
search_vista_part: 1

search_part()
Disk /dev/sda - 128 GB / 119 GiB - CHS 15567 255 63

recover_EXT2: s_block_group_nr=0/304, s_mnt_count=64/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8176
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 9963520
recover_EXT2: part_size 79708160
Linux 522 10 1 5483 163 56 79708160
EXT4 Large file Sparse superblock, 40 GB / 38 GiB

Linux 5483 163 57 5483 228 57 4096
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

Linux 14883 6 36 14883 71 36 4096
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
Warning: the current number of heads per cylinder is 255 but the correct value may be 128.

Results
* Linux 522 10 1 5483 163 56 79708160
EXT4 Large file Sparse superblock, 40 GB / 38 GiB
P Linux 5483 163 57 5483 228 57 4096
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB
P Linux 14883 6 36 14883 71 36 4096
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

interface_write()
1 * Linux 522 10 1 5483 163 56 79708160
2 P Linux 5483 163 57 5483 228 57 4096
3 P Linux 14883 6 36 14883 71 36 4096
simulate write!

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

TestDisk exited normally.

Last edited by ehsdav; 07-08-2013 at 06:27 PM.
 
Old 07-08-2013, 07:48 PM   #10
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
First of all note an overwritten partition table does not constitute data loss (it's "only" an index at the start of the disk). Secondly with Testdisks output you now have evidence that your LUKS partitions still exist. Now all that remains is having Testdisk rewrite it with the partitions it found. Whatever precedes the LUKS partitions, any error wrt the OS trying to mount it, doesn't matter. Once you've got Testdisk write the partition table you should be able to 'cryptsetup luksOpen /dev/sda1 recovery; mkdir /recovery; mount /dev/sda1 /recovery'.
 
1 members found this post helpful.
Old 07-09-2013, 04:50 AM   #11
ehsdav
LQ Newbie
 
Registered: Jul 2013
Posts: 6

Original Poster
Rep: Reputation: Disabled
thanks all it finally recovered.
i overwrite the partition table but it does not worked first (because of disk size error).

but according to this:
http://www.linuxquestions.org/questi...on-4175435883/
i change the size and it worked.
here the steps for later usage but i hope no one need it
1-first running the testdisk (according to your helps) and overwriting partition tables and exiting testdisk.
it used 255 head, 63 sector/track , 15566 cylenders , total 250069680 sector (consider its value H)
2-running fdisk /dev/sda -l
it shows all my partition with START SECTOR and END SECTOR and BLOCK SIZE of them:
sda1 which is ext4 and it was recovered before easily.
sda2 luks with CORRECT START SECTOR (consider its value A) but FALSE END SECTOR.
sda3 luks with CORRECT START SECTOR (consider its value B) but FALSE END SECTOR.
3-running fdisk /dev/sda
deleting partition sda2 (d -> p -> 2 )
recreating sda2 with correct size (n -> p -> 2 -> start sector A -> end sector (B-1))
deleting partition sda3 (d -> p -> 3 )
recreating sda3 with correct size (n -> p -> 3 -> start sector B -> end sector (H-1))

thank all and best regards

Last edited by ehsdav; 07-10-2013 at 05:14 AM. Reason: note error
 
1 members found this post helpful.
  


Reply



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 On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] recover from deleted luks encryption partition unixedway Linux - General 12 01-16-2017 06:33 AM
Recover encrypted LUKS partition itinlopez Linux - General 3 11-30-2008 02:20 AM
Need to recover lost partition table business_kid Linux - General 4 03-24-2008 10:42 AM
Partition Table Lost...how to recover rhb327 Slackware 5 07-08-2007 08:17 PM
Recover a lost partition!!!!! Caveman Linux - Newbie 4 09-26-2003 01:10 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 08:19 AM.

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
Open Source Consulting | Domain Registration