From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sapo.pt (relay3.ptmail.sapo.pt [212.55.154.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 22 Nov 2015 16:12:06 +0100 (CET) Received: from unknown (HELO [192.168.1.76]) (l-alexandre@sapo.pt@[89.114.112.47]) (envelope-sender ) by mta-auth01 (qmail-ptmail-1.0.0) with SMTP for ; 22 Nov 2015 15:05:23 -0000 References: <20151121184914.GA28647@tansi.org> <5651B1CF.7090306@sapo.pt> <20151122125233.GA4802@tansi.org> From: =?UTF-8?Q?Lu=c3=ads_Alexandre?= Message-ID: <5651D9B3.6000500@sapo.pt> Date: Sun, 22 Nov 2015 15:05:23 +0000 MIME-Version: 1.0 In-Reply-To: <20151122125233.GA4802@tansi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: dm-crypt@saout.de 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 >