Re: Massive Failure

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

 



Can you use losetup on the header file then cryptsetup luksDump /dev/loopX?

On Thu, Aug 7, 2008 at 6:07 PM, Clayton Shepard <cws@xxxxxxxx> wrote:
> Due to a combination of hardware failure, ignorance, and stupidity I have
> managed to really make a mess of a 7 drive mdadm (raid5) -> lvm -> luks ->
> ext3 setup.  So here is the basic setup:
>
> 1.  sudo badblocks -c 16384 -s -w -t random -v /dev/sd (on all 7 drives)
> 2.  sudo mdadm --create --verbose /dev/md0 --level=5 --chunk=256 --force
> --raid-devices=7  /dev/sd[a,b,c,d,e,f,g]
> 3.  pvcreate /dev/md0
> 4.  vgcreate lg /dev/md0 -s 256M
> 5.  lvcreate -l22356 -nlv lg
> 6.  cryptsetup --verify-passphrase --verbose --hash=sha256
> --cipher=aes-cbc-essiv:sha256 --key-size=128 luksFormat /dev/lg/lv
> 7.  cryptsetup luksOpen /dev/lg/lv encrypted
> 8.  mkfs.ext3 -j -m 3 -O dir_index,filetype,sparse_super,large_file
> /dev/mapper/encrypted
>
>
> So long story short, the hardrives were swapped around and one point which
> cause blkid.tab to go crazy and remap the drives to different letters.  All
> but one of the mdadm superblocks were erased, but I believe the array was
> clean before this happened.  By using basically the same command first used
> to create the array mdadm detected that it was already a raid array and
> recreated it - unfortunately it thought that the last drive (sdh at this
> time) was dirty, and thus began rebuilding it.  Unfortunately commands 3-7
> were also reissued, which initially made me believe that the luks header was
> destroyed (according to this thread:
> http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2005-12/msg00045.html).
> After some time with dd and a hex editor I have found three luks headers on
> the drives - two of which are the new header; however it is my hope that the
> other one is the original luks header.
>
> I now believe that mdadm did not correctly recreate the raid array,
> primarily because that luks header was not wiped out and the array was
> created with the drives in a different order.    I do not believe that the
> drive that was being rebuilt ever completed (this may be useful for
> rebuilding the raid array in the correct order?).
>
> At this point since there are so many ways that I could be SOL, I think the
> first step is just for me to verify that the luks header I recovered is the
> correct one.  Anyone have any advice on how to do this?  I already dd'd the
> first 4mb of each drive in to files, but I am not really sure how to
> proceed.  Will I have to trick cryptsetup in to thinking its a device?  Is
> there a way to simply decrypt all the data on these little chunks?  I will
> probably have a problem with data alignment due to the cryptsetup being
> applied after mdadm and lvm, both accross the chunks and on the individual
> chunks...  is there anyway to fix that?
>
> Are there any tools similar to R-Studio for linux?
>
> If this is in fact the correct key then I think that I may still be able to
> recover most of my data, as I do not believe much other than the various
> headers have been corrupted...
>
>
> Thanks for your help,
>
>
> -Clay
>

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[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