[dm-crypt] Corrupt LUKS-Header
arno at wagner.name
Mon Nov 14 20:33:04 CET 2011
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
> 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
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:
> 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 at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at 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
More information about the dm-crypt