All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luís Alexandre" <l-alexandre@sapo.pt>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Open raid1 with luks encryption after a raid re-create
Date: Sun, 22 Nov 2015 15:05:23 +0000	[thread overview]
Message-ID: <5651D9B3.6000500@sapo.pt> (raw)
In-Reply-To: <20151122125233.GA4802@tansi.org>



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
>

  reply	other threads:[~2015-11-22 15:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-21 16:29 [dm-crypt] Open raid1 with luks encryption after a raid re-create Luis Alexandre
2015-11-21 18:49 ` Arno Wagner
     [not found]   ` <5651B1CF.7090306@sapo.pt>
2015-11-22 12:52     ` Arno Wagner
2015-11-22 15:05       ` Luís Alexandre [this message]
2015-11-22 18:15         ` Arno Wagner
2015-11-22 22:30         ` Sven Eschenberg
2015-11-23  3:35           ` Arno Wagner
2015-11-23  3:56             ` Sven Eschenberg
2015-11-23  6:26               ` Arno Wagner
2015-11-24 11:15                 ` Luis Alexandre
2015-11-24 12:52                   ` Arno Wagner
2015-11-25 11:49                   ` Sven Eschenberg
2015-11-21 19:05 ` Sven Eschenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5651D9B3.6000500@sapo.pt \
    --to=l-alexandre@sapo.pt \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.