Luis,
Looking at the lsblk output you sent:
sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 931,5G 0 part
└─md127 9:127 0 931,4G 0 raid1
sdc 8:32 0 931,5G 0 disk
└─sdc1 8:33 0 931,5G 0 part
└─md127 9:127 0 931,4G 0 raid1
mdadm complaint about the partition table on /dev/sdb and you had sdb1
which covered basically the whole drive. Assuming this was the original
md raid component - did you find the LUKS header somewhere on sdb?
I am asking this, because mdadm placed it's metadata 4k from the start
of /sdb after your command meaning it is located behind the
MBR(partition table) and most certainly before the Partition starts.
At least the output of mdstat suggests that sdb is component zero and
thus was chosen as source.
Originally your mdadm metadata (assuming it was v1.2) was 4k from the
start of sdb1 and thus the LUKS header would be located somewhere behind
that, if you had LUKS on top of mdraid. Depending on the parameters the
md header is quite big as it might include an intent bitmap etc. . It
would be interesting though to see if there's an md metadata area 4k
from the start of sdb1.
Now to your question, once you know the offset of the header:
1.)Setup a loop device from your image (You can use an offset into the
image where your loop device starts with sector 0) see --offset in
losetup man page.
Inspect loopdevice if the LUKS Header now is on sector 0
2.)Try a cryptsetup luksopen in readonly mode
3.)If you got this far, inspect the contents of the mapping
Regards
-Sven
P.S.: Once you verified everything works, you can still create an image
of the physical raid component hdd and skip into the drive to the right
offset. This image would then hopefully include the contents of your
original md array...
Am 22.11.2015 um 16:05 schrieb Luís Alexandre:
On 22-11-2015 12:52, Arno Wagner wrote:
CC'ing to the list, as it serves as a sort-of archive of
how to solve problems as well and there are several clueful
and helpful people in it that may spot more things than I do.
On Sun, Nov 22, 2015 at 13:15:11 CET, Luis Alexandre wrote:
[...]
It can sync in the wrong direction. And second, unfortunately,
superblock format 1.2 is a dirty hack designed by incompetents.
It places the RAID header 4k from the start of the device. For
LUKS, this kills the first keyslow of misaligned. Unfortunately,
this is also the default. No, that has not happened here or you
would get the header.
Since the original raid was already 1.2 format, the location would
already be the 4k from the start of the device. So where was LUKS
info placed in terms of distance from the start of the device?
Right at the start. That is why using superblock 0.90 or 1.0
with LUKS is a good diea as it becomes exceptionally unlikely
that the MD-header damages the LUKS header.
Thanks for any help you can provide.
Ok, first stop writing to the disks. Second, make a full, binary backup
of each disk. And third, try whether either disk works individually
as degraded array.
1-Done.
2-Done. Dumped the first 2MB of each disk.
Make that 1GB at least to be sure to capture the LUKS header
in it if it is still anywhere.
3-They appear as raid disks but again I cannot open the encryption.
If neither gives you a LUKS header, you can still search on the raw
disks by looking for the LUKS signature. If that also fails, you are
out of luck and all your data is gone.
The LUKS signature is simply 'LUKS'?
Not quite. FAQ Item 6.12
(https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions)
gives you a brief version, the LUKS on-disk spec gives everything.
I grepped like this:
grep LUKS header_sdb_backup.dmp
is it the correct way to do it?
Did not find any match...
Ok, lets repeat that with the full disks and including the full signature
hd /dev/sdx | grep "0 4c 55 4b 53 ba be 00 01"
with x one of your RAID disks. Do this for both. May take a while.
This gives you the alignment as well. The "hd" start of a good
luks header and container (header starts at offset 0) looks like
this:
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
|LUKS....aes.....|
Only the first 6 bytes are fixed. Bytes 6 and 7 are the version
of which there currently is onlyy "0001". This will always be
aligned to a 512 byte boundary. Doing it this way has the
advantage that you get the offset as well.
found it in one of the disks:
08100000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
|LUKS....aes.....|
Can you tell me how should I proceed now?
(the other is still being searched: the first one took a few seconds,
this one is now over 1 hour search)
Many thanks,
Luis
Regards,
Arno
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
