Re: [dm-crypt] Corrupt LUKS-Header

[Arno Wagner <arno@wagner.name>]

On Mon, Nov 14, 2011 at 08:03:26PM +0100, Nicolai Voget wrote:
> Hi there,
> 
> on my home server I've got a RAID 5 consisting of 3 hard drives that
> contains a dm-crypt partition with ext4.
> Today, one of the 3 drives passed out and afterwards I got some
> ext4-errors in dmesg.
> 
> Unfortunately I'm not home right now, nor for the next 4 days, so I
> can't replace the harddrive, although I even think it's not necessary,
> because it was just the USB-controller that passed out. Nevertheless, I
> wanted to run some e2fsck on the partition to check whether there are
> some errors or what dmesg was talking about.
> Stupid me, I forgot that the partition was decrypted, so I ran the
> e2fsck directly on the md0-RAID. Of course I got some errors, but didn't
> really think about it, so e2fsck did some error correction, but
> eventually it seemed weird, so I interrupted it. (I've attached the
> output, e2fsck showed me, maybe it helps)
> 
> Of course, the LUKS-device won't mount any more for the LUKS header
> seems to be overriden. Fortunately, the drive that passed out of the
> RAID earlier (sda) has been the first device of the raid, thus holding
> the first 64k (that is, until 0x10000) of LUKS-data (starting with "LUKS
> ??? aes ???" and so on). Unfortunately, the modification by e2fsck went on
> to the second 64k of data, too. But by comparing the (original) data on
> sda with that on md0, I can say that anything from 192k upwards
> (0x30000) seems to be fine again.
> 
> Is there any chance of getting the missing data back? As far as I know,
> there are some methods to get the data, that has been stored in a block,
> although it has already been overridden. By the fact that I have one of

No. Not for modern HDDs. At least nobody admits to being able to
do this and there are some rather strong indicators it is 
fundamentally impossible.

> the drives unaltered, it should be possible, to judge which combinations
> of data for the other two drives can be possible, because the must xor
> to the data of the first drive, isn???t it?
> 
> I would be extremely thankful if anyone could help me out on this.

If your LUKS container is still mapped, then you can get the
master key. This is your _only_ chance, unless you have a header
backup. 

See FAQ section "6. Backup and Data Recovery"
item "How do I recover the master key from a mapped LUKS container?"

The FAQ is here: 
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

Arno





> Regards,
> Nicolai

> e2fsck /dev/md0
> e2fsck 1.41.12 (17-May-2010)
> e2fsck: Superblock invalid, trying backup blocks...
> Superblock has an invalid journal (inode 8).
> Clear<y>? yes
> 
> *** ext3 journal has been deleted - filesystem is now ext2 only ***
> 
> /dev/md0 was not cleanly unmounted, check forced.
> Resize inode not valid.  Recreate<y>? yes
> 
> e2fsck: Illegal triply indirect block found while reading bad blocks inode
> This doesn't bode well, but we'll try to go on...
> Pass 1: Checking inodes, blocks, and sizes
> Bad block inode has illegal block(s).  Clear<y>? yes
> 
> Illegal block #0 (1944878064) in bad block inode.  CLEARED.
> Illegal block #1 (1576054459) in bad block inode.  CLEARED.
> Illegal block #2 (2603946801) in bad block inode.  CLEARED.
> Illegal block #3 (3721147353) in bad block inode.  CLEARED.
> Illegal block #4 (843436927) in bad block inode.  CLEARED.
> Illegal block #5 (2785300981) in bad block inode.  CLEARED.
> Illegal block #6 (2792029489) in bad block inode.  CLEARED.
> Illegal block #7 (2223358637) in bad block inode.  CLEARED.
> Illegal block #8 (1903446826) in bad block inode.  CLEARED.
> Illegal block #9 (2220861675) in bad block inode.  CLEARED.
> Illegal block #10 (3344075755) in bad block inode.  CLEARED.
> Illegal block #11 (3784337891) in bad block inode.  CLEARED.
> Illegal indirect block (4030283823) in bad block inode.  CLEARED.
> Illegal double indirect block (3050192542) in bad block inode.  CLEARED.
> Illegal triple indirect block (3271645712) in bad block inode.  CLEARED.
> Root inode is not a directory.  Clear<y>? yes
> 
> Inode 3 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> 
> Reserved inode 4 (<The ACL data inode>) has invalid mode.  Clear<y>? yes
> 
> Inode 4 has compression flag set on filesystem without compression support.  Clear<y>? yes
> 
> Inode 4, i_size is 11409684805389471492, should be 0.  Fix<y>? yes
> 
> Inode 4, i_blocks is 25110402, should be 0.  Fix<y>? 
> 
> Recreate journal<y>? cancelled!
> 
> /dev/md0: e2fsck canceled.
> 
> /dev/md0: ***** FILE SYSTEM WAS MODIFIED *****

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


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier