Need help to recovery Partition Table - Luks Formatted dirve

7hr08ik · 01-27-2014, 03:43 AM

Hey guys,

Finally got some time to actually get these drives sorted...But im a bit confused with @rknickols steps

I opened up hexedit and searched for 4c554b53babe (which i assume is the generic LUKS header)

It was found at offset 0x4400 which /512 comes to 0.859375. So im kinda stuck

Edit: I have NO experience with hexedit at all

7hr08ik · 01-27-2014, 04:13 AM

OK, figured it out....Sector 34

And i've discovered that i did manage to convert to GPT. But gdisk is saying i've got a corrupt GPT and working MBR?!?!

I've rebuilt the GPT and created the partition, so now to reboot and cross my fingers

7hr08ik · 01-27-2014, 04:30 AM

OK, because the HDD is 3TB i can't use fdisk so i have to use gdisk

But when i write the new partition table gdisk gives me the following

Code:

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}: 34
Information: Moved requested sector from 34 to 2048 in
order to align on 2048-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}: 
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sde.
Unable to save backup partition table! Perhaps the 'e' option on the experts'
menu will resolve this problem.
Warning! An error was reported when writing the partition table! This error
MIGHT be harmless, or the disk might be damaged! Checking it is advisable.

Command (? for help):

And i have tried the 'e' option aswell. Im lost, from what i can tell the header is still available. I can find it in hexedit. But i just cant get the partition table remade.

And when i get the option for File System, should i use the default or 8e00 for Linux LVM? Im pretty sure its LVM

rknichols · 01-27-2014, 08:48 AM

Well, gdisk seems to have protected you from destroying your LUKS header (Frankly, I'm amazed.), so I guess you can press on.

In gdisk, you need to go into "expert" mode ("x" command) and change the sector alignment value (lower case "l" command) to 2. Then use the "m" command to return to the main menu, and it should now accept "34" as a starting sector.

I should add that eventually you will probably want to realign your partitions. Your 3GB drives are probably "Advanced format", with 4KB physical sectors. ("fdisk -l" will tell you the logical any physical sector sizes.) Leaving the partitions misaligned at LBA addresses that are not a multiple of 8 will severely impact write performance on such drives -- by a factor of 10 or worse. But, let's leave that until you have recovered your data and backed it up, and also dealt with the bad sectors on your drives.

7hr08ik · 01-28-2014, 02:15 AM

Hey dude, Sorry if im pestering. It feels like im so close.

I realise that even if i get the partition sorted its gonna be broken still... As i can only recover 1 of the drives my plan is to recover this one and copy the data over to the other drive a re-partition the drive completely.

Anyway.... I followed your advice with the expert mode. Removed the current GPT and rebuilt a new one. Then i gave me an error saying its moved the alignment to 2048 and i should use expert mode and 'l' to fix it???

Code:

kun7@HAL-9000:~$ sudo gdisk /dev/sde
[sudo] password for kun7: 
GPT fdisk (gdisk) version 0.8.7

Warning! Read error 5; strange behavior now likely!
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2
Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Command (? for help): x

Expert command (? for help): l
Enter the sector alignment value (1-65536, default = 2048): 2

Expert command (? for help): m

Command (? for help): ?
b	back up GPT data to a file
c	change a partition's name
d	delete a partition
i	show detailed information on a partition
l	list known partition types
n	add a new partition
o	create a new empty GUID partition table (GPT)
p	print the partition table
q	quit without saving changes
r	recovery and transformation options (experts only)
s	sort partitions
t	change a partition's type code
v	verify disk
w	write table to disk and exit
x	extra functionality (experts only)
?	print this menu

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}: 34
Information: Moved requested sector from 34 to 2048 in
order to align on 2048-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}: 
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sde.
Unable to save backup partition table! Perhaps the 'e' option on the experts'
menu will resolve this problem.
Warning! An error was reported when writing the partition table! This error
MIGHT be harmless, or the disk might be damaged! Checking it is advisable.

Command (? for help):

rknichols · 01-28-2014, 08:04 AM

Please stop writing known incorrect partition tables to the drive. Doing that is even more foolish than your original mistake. It risks overwriting the LUKS header, which would be fatal for your data. The normal recommendation for any data recovery situation is to copy the entire drive to a new one and work only on the copy. You have to be very careful if you are working on the original with no backup.

I don't know why gdisk is behaving that way. It doesn't do that for me, but I don't have a disk like yours. You'll need to contact gdisk support for an answer.

goumba · 01-28-2014, 09:05 AM

Ok, I have been following this, and as I just rescued a GPT myself, I'm wondering: if the OP was converting to GPT that means he had an MBR, is that not so? So why are we working with gdisk? Restore the partition using fdisk or testdisk (testdiskm, will, in my experience, guess the partition table based on found filesystems), recover the data, then realign the partitions. I don't know why the OP is even worring about the performance hit caused by partitions out of alignment when s/he's trying to recover data.

rknichols · 01-28-2014, 10:29 AM

It is not certain just how the drives were originally partitioned. The OP said each had one partition extending over the whole drive. These are 3TB drives, and that would be beyond the 2TB limit for fdisk and a legacy DOS MBR.

goumba · 01-28-2014, 10:51 AM

Hmmm... I would have thought a utility intended to convert to GPT would have warned if it already was, but I guess I took too much for granted.

However, I stand by my statement that the OP should not be playing with alignment right now as that's only going to make things worse.

rodsbooks links were posted earlier in this thread and that's what I used without any issue at all to fix my GPT (user error with dd

although something funny went on from the os' end). If the OP still hasn't looked at the, s/he should.

rknichols · 01-28-2014, 03:21 PM

Quote:

Originally Posted by goumba

However, I stand by my statement that the OP should not be playing with alignment right now as that's only going to make things worse.

You are seriously misreading what is going on here. The only person who has mentioned performance and changing the alignment is me, and that was together with the comment, "But, let's leave that until you have recovered your data and backed it up." The effort right now is just to get a partition table that agrees with where the partition actually exists on the disk. gdisk from rodsbooks is indeed what has been tried, and it is for some reason being uncooperative.

goumba · 01-28-2014, 05:05 PM

Quote:

Originally Posted by rknichols

The only person who has mentioned performance and changing the alignment is me, and that was together with the comment, "But, let's leave that until you have recovered your data and backed it up." The effort right now is just to get a partition table that agrees with where the partition actually exists on the disk. gdisk from rodsbooks is indeed what has been tried, and it is for some reason being uncooperative.

Indeed I somehow missed your "leave this for later". And I missed your reference to rodsbooks.

When I borked my GPT, I had used gdisk's recovery menu ("r") and the rebuilt main table from backup ("c") option. I doubt if this is still an option at this point, the error about writing the backup as it is..

Quote:

The normal recommendation for any data recovery situation is to copy the entire drive to a new one and work only on the copy.

On that, rodsbooks notes that the backup drive has to be the exact size of the original, or it may be necessary to work on the original (keeping the backup safe, of course). I mention that just in case the OP decides to backup and try.