[dm-crypt] Open raid1 with luks encryption after a raid re-create

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sun Nov 22 23:30:23 CET 2015


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 at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


More information about the dm-crypt mailing list