I would be very happy about a feedback regarding a disastrous step on setting up my LUKS encrypted RAID Level 1 today.
After a mainboard breakdown I was forced to change the system. Out of stupidity I just thought setting up again the mainboard-integrated
RAID would be usable of setting up the same RAID hard disks again. But wrong: MBR is lost now for both hard disks at the same time, yeah.
I have undone this step immediately but partition information were of course lost already.
What are general information about the hard disks:
There are two partitions. Output of testdisk was for one of the hard disks:
----------------------------------------------------
Partition table type (auto): Intel
/dev/sdb: Device Configuration Overlay (DCO) present.
Disk /dev/sdb - 750 GB / 698 GiB - ATA WDC WD7500AACS-0
Partition table type: Intel
Interface Advanced
New options :
Dump : No
Cylinder boundary : Yes
Allow partial last cylinder : No
Expert mode : No
A new copy of MBR Ask the user for vista mode
Allow partial last cylinder : No
search_vista_part: 0
search_part()
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63
Linux Swap 87 1 1 99 254 41 208760
SWAP2 version 1, 106 MB / 101 MiB
Linux 100 0 1 100 32 40 2056
LUKS 1 (Data size unknown), 1052 KB / 1028 KiB
Linux 45000 0 1 45000 32 40 2056
LUKS
search_part()
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63
block_group_nr 3
recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/5589, s_mnt_count=0/21, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 183143645
recover_EXT2: part_size 1465149160
Linux 0 0 1 91201 80 55 1465149160
EXT3 Large file Sparse superblock Backup superblock, 750 GB / 698 GiB
Partition not added.
Linux Swap 87 1 1 99 254 41 208760
SWAP2 version 1, 106 MB / 101 MiB
Linux 100 0 1 100 32 40 2056
LUKS 1 (Data size unknown), 1052 KB / 1028 KiB
block_group_nr 3
recover_EXT2: "e2fsck -b 98304 -B 4096 SIGHUP detected! TestDisk has been killed.
_group_nr=3/2751, s_mnt_count=0/28, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 90164812
recover_EXT2: part_size 721318496
Linux 100 0 1 44999 254 59 721318496
EXT3 Large file Sparse superblock Backup superblock, 369 GB / 343 GiB
Linux 45000 0 1 45000 32 40 2056
LUKS 1 (Data size unknown), 1052 KB / 1028 KiB
get_geometry_from_list_part_aux head=255 nbr=6
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=255 nbr=6
Results
L Linux Swap 87 1 1 99 254 63 208782
SWAP2 version 1, 106 MB / 101 MiB
Linux 100 0 1 100 254 63 16065
LUKS 1 (Data size unknown), 8225 KB / 8032 KiB
Linux 100 0 1 44999 254 63 721318500
EXT3 Large file Sparse superblock Backup superblock, 369 GB / 343 GiB
* Linux 45000 0 1 45000 254 63 16065
LUKS 1 (Data size unknown), 8225 KB / 8032 KiB
interface_write()
1 E extended 87 0 1 99 254 63 208845
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended LBA 0 1 1 44999 254 63 722924937
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended 87 0 1 99 254 63 208845
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended LBA 0 1 1 44999 254 63 722924937
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended 87 0 1 99 254 63 208845
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended LBA 0 1 1 44999 254 63 722924937
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended 87 0 1 99 254 63 208845
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
interface_write()
1 E extended LBA 0 1 1 44999 254 63 722924937
2 * Linux 45000 0 1 45000 254 63 16065
5 L Linux Swap 87 1 1 99 254 63 208782
write!
write_mbr_i386: starting...
write_all_log_i386: starting...
write_all_log_i386: CHS: 0/1/1,lba=63
You will have to reboot for the change to take effect.
A new copy of MBR code has been written.
You have to reboot for the change to take effect.
TestDisk exited normally.
----------------------------------------------------
I suppose that LUKS partition headers are still available since running testdisk at least recovered partly the partitions.
And output of testdisk informs about the LUKS partition headers. But luksDump was until now only successful for the partition header in sdb2 in sector 100.
See output below:
----------------------------------------------------
LUKS header information for /dev/sdb2
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: 0e 88 8d 6a 08 53 35 35 2e aa fa b9 3c b5 6c 91 c6 0a ed b6
MK salt: 96 72 0a 5a 8f ec 6f ba 17 d2 f0 2f 34 55 7c 74
c1 30 3e b5 b1 a9 48 5f d7 af 65 ed 12 6b f3 03
MK iterations: 10
UUID: 983ca94c-5c97-4bd2-af44-17b85933f487
Key Slot 0: ENABLED
Iterations: 245476
Salt: 2b 2f c9 05 de f2 37 9e d6 7c bd f8 f1 51 63 46
38 8a 58 39 53 4a 16 6b e3 6f 3c a9 63 93 8a b9
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
----------------------------------------------------
But opening this with luksOpen to /dev/mapper and the following mounting did result only into the low base directories already
followed by input/output error statements. I suppose that sectors of the found data partition is still not found correctly.
And I failed trying to cd into the subdirectories.
---
What I need or think what I need - please suggest better next steps if known! - from you:
1. Is it possible to recover MBR information after the BIOS has overwritten it?
Since I did not set up the RAID any further until now I just rewrote the MBR suggested by testdisk today on one of the mirrored disks.
Is there any tool which can be used to recover MBR information on the other not yet touched hard disk doing this like i.e. photorec for common other file types?
2. Since luksDump failed for the second partition header information on sector 45000: is there something like the program "strings" useful to be used to find these information?
I would like to grep the whole 750GB disk for it.
3. How are partition headers in their structure? All the time only one block? Readable by any other console tools except luksDump thus I could grep the whole disk for example to see why second header information was not recovered in sector 45000. Is the LUKS partition header usually in front of an encrypted data partition or behind?
4. When I got all informations about the partitions sizes and locations of their beginnings and end: what are usable tools for the easy manual creation of the MBR?
5. Do you see any other possibilities to grep for the partitions limits except done by testdisk already? Maybe something more fitting for LUKS encrypted partitions/disks?!?
Thanks in advance for your help and kindly regards,
Thore
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
