[dm-crypt] yet another header reconstruction question

Sven Eschenberg sven at whgl.uni-frankfurt.de
Thu Feb 18 11:26:10 CET 2016


Florian,

While at it (resending in plain text) make sure to include the output of 
lsblk if possible. This should give us an idea of the layout as 
currently being used.

Regards

-Sven


Am 18.02.2016 um 10:34 schrieb Michael Kjörling:
> On 18 Feb 2016 09:51 +0100, from florian.dotzer at web.de (Florian Dotzer):
>> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>
>
> Please resend as not HTML.
>
>>  @Michael , Arno , Sven :<br/>
>> <br/>
>> Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))<br/>
>> I *can* login as root to the QNAP box - but I am not a shell guru .<br/>
>> I hope I will be able to unlock my LUKS Copntainer without losing my Data .<br/>
>> <br/>
>> I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,<br/>
>> e.g. I clicked a Button named "Add hard drive" in the RAID Management Section ,<br/>
>> selected the newly added disk, and waited for the desaster to complete<br/>
>> <br/>
>> (german slang : mausi klickibunti ) .<br/>
>> <br/>
>> Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )<br/>
>> <br/>
>> Michael wrote :<br/>
>> > What was the exact device layout?<br/>
>> > Physical storage then MD RAID<br/>
>> Yes. I have the box not at my desk here. Sorry.<br/>
>> <br/>
>> > then LUKS<br/>
>> At least I found a corrupted LUKSHeader there in /dev/md0<br/>
>> <br/>
>> > then some file system,<br/>
>> I hope so , thats where my data lives .<br/>
>> <br/>
>> YESS Sir<br/>
>> <br/>
>> > or physical storage then LUKS then MD RAID<br/>
>> >then some file system, or some other arrangement?<br/>
>> No<br/>
>> <br/>
>> >What was the exact command used to "add a disk"?<br/>
>> QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .<br/>
>> <br/>
>>  From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,<br/>
>> I see the RAID created with mdadm as built dirctly on the disk partitions sd[d|e|f|g|h|c]3<br/>
>> <br/>
>> where /dev/sdc is the disk I added .<br/>
>> the raid itself is up with all disks , (all disks 'U' ) , valid / valid superblock<br/>
>> I can get and read data from the block device /dev/md0<br/>
>> as you have seen in my last email.<br/>
>>  <br/>
>> <br/>
>> <br/>
>> @ Arno :<br/>
>> <br/>
>> > What did you do?<br/>
>> > Did you pipe the output from mdadm into /dev/md0?<br/>
>> No.<br/>
>> > If so, there might be a chance to recover this.<br/>
>> <br/>
>> > First, make that header backup now, if you have not already.<br/>
>> <br/>
>> I have at least the first 64 MB of /dev/md0 extracted with dd if=/dev/md0 of=of=file_with_first_64_MB_of_md0 bs=1024 count=65535<br/>
>> The hex Dump was extracted from this .<br/>
>> I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?<br/>
>> <br/>
>> > The data that is missing depends on the QNAP device.<br/>
>> SS839 PRO<br/>
>> > Defaults can be changed on compile.<br/>
>> I only have binaries , no sources , no compiler<br/>
>> > Easiest option is<br/>
>> > likely to make a new LUKS container on it and try what<br/>
>> > is in there. You should be able to use the loop-device<br/>
>> > procedure from FAQ Item 2.6 from the commandline for<br/>
>> > that. If those values do not work, next option is to<br/>
>> > have the QNAP create a LUKS container on a new disk<br/>
>> > and see what it does.<br/>
>> <br/>
>> I'll try it that weekend or next when I have time to do it .<br/>
>> <br/>
>> <br/>
>> @Sven :<br/>
>> <br/>
>> >btw: I agree, if just the short output of mdadm was written to the disk<br/>
>> >chances are quite good for recovery.<br/>
>> <br/>
>> I hope so. I tried dd on files to replace the first 512 bytes of a file , but<br/>
>> the target file was completely replaced with this command :<br/>
>> <br/>
>> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1<br/>
>> <br/>
>> Now I dont know if dd's behaviour is different on block device level ,<br/>
>> or is there another better way to replace / correct the first bytes of /dev/md0 ?<br/>
>> <br/>
>> <br/>
>> Greetings , Florian<br/>
>>  </div></div></body></html>
>


More information about the dm-crypt mailing list