Re: yet another header reconstruction question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Am 16.02.2016 um 16:01 schrieb Arno Wagner:
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.

Looks alot like he did (if he did it himself manually). If so, maybe he can also provide the actual command from the shell history? It could help analyzing what happened.

btw: I agree, if just the short output of mdadm was written to the disk chances are quite good for recovery.


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


Regards

-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux