@Michael , Arno , Sven :
Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))
I *can* login as root to the QNAP box - but I am not a shell guru .
I hope I will be able to unlock my LUKS Copntainer without losing my Data .
I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,
e.g. I clicked a Button named "Add hard drive" in the RAID Management Section ,
selected the newly added disk, and waited for the desaster to complete
(german slang : mausi klickibunti ) .
Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )
Michael wrote :
> What was the exact device layout?
> Physical storage then MD RAID
Yes. I have the box not at my desk here. Sorry.
> then LUKS
At least I found a corrupted LUKSHeader there in /dev/md0
> then some file system,
I hope so , thats where my data lives .
YESS Sir
> or physical storage then LUKS then MD RAID
>then some file system, or some other arrangement?
No
>What was the exact command used to "add a disk"?
QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .
>From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,
I see the RAID created with mdadm as built dirctly on the disk partitions sd[d|e|f|g|h|c]3
where /dev/sdc is the disk I added .
the raid itself is up with all disks , (all disks 'U' ) , valid / valid superblock
I can get and read data from the block device /dev/md0
as you have seen in my last email.
@ Arno :
> What did you do?
> Did you pipe the output from mdadm into /dev/md0?
No.
> If so, there might be a chance to recover this.
> First, make that header backup now, if you have not already.
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
The hex Dump was extracted from this .
I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?
> The data that is missing depends on the QNAP device.
SS839 PRO
> Defaults can be changed on compile.
I only have binaries , no sources , no compiler
> 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.
I'll try it that weekend or next when I have time to do it .
@Sven :
>btw: I agree, if just the short output of mdadm was written to the disk
>chances are quite good for recovery.
I hope so. I tried dd on files to replace the first 512 bytes of a file , but
the target file was completely replaced with this command :
dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1
Now I dont know if dd's behaviour is different on block device level ,
or is there another better way to replace / correct the first bytes of /dev/md0 ?
Greetings , Florian
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
