From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (mail.tansi.org [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Tue, 16 Feb 2016 16:01:51 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-36-72.dclient.hispeed.ch [77.57.36.72]) by v6.tansi.org (Postfix) with ESMTPA id 30AAC20DC530 for ; Tue, 16 Feb 2016 16:01:51 +0100 (CET) Date: Tue, 16 Feb 2016 16:01:50 +0100 From: Arno Wagner Message-ID: <20160216150150.GA3667@tansi.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] yet another header reconstruction question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Tue, Feb 16, 2016 at 12:32:06 CET, Florian Dotzer wrote: > sent again as text. sorry for HTML input. hopefully it is more readable now . fine now. > Dear Readers of the List . > > I had a encrypted RAID 5 on my QNAP Device in /dev/md0. > > It worked without any problems for about 6 years . > But space went low and desaster began. > After adding a disk , mdadm had overwritten the > header (block device /dev/md0 ) like this : > > 6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65 mdadm: added /de > 76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00 v/sdc3.......... > 00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69 ........cbc-plai > 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... > 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 ........sha1.... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20 ............... > bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a What did you do? Did you pipe the output from mdadm into /dev/md0? If so, there might be a chance to recover this. > According to the documentation on-disk-format , > magic (LUKS 0xba 0xbe ) , version and cipher name > seem to be overwritten. > > I'd like to know the possible versions ( 00 01 ? ) and cipher names > (aes ?) in order to be able to reconstruct the header (fingers crossed ) First, make that header backup now, if you have not already. The data that is missing depends on the QNAP device. Defaults can be changed on compile. Easiest option is likely to make a new LUKS container on it and try what is in there. You should be able to use the loop-device procedure from FAQ Item 2.6 from the commandline for that. If those values do not work, next option is to have the QNAP create a LUKS container on a new disk and see what it does. 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