From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Sun, 22 Nov 2015 13:52:34 +0100 (CET) Date: Sun, 22 Nov 2015 13:52:33 +0100 From: Arno Wagner Message-ID: <20151122125233.GA4802@tansi.org> References: <20151121184914.GA28647@tansi.org> <5651B1CF.7090306@sapo.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5651B1CF.7090306@sapo.pt> Subject: Re: [dm-crypt] Open raid1 with luks encryption after a raid re-create List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luis Alexandre Cc: dm-crypt@saout.de 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. Regards, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier