[dm-crypt] raid5 (/dev/md0) w. luks broken - can't decrypt

Arno Wagner arno at wagner.name
Fri Jan 21 13:46:17 CET 2011

On Thu, Jan 20, 2011 at 08:10:58PM +0100, Stygge wrote:
> Hi ...
> My google-fu does not seem to be sufficient for this :-(
> I have a 2.9 TB raid5 consisting of 4 700GB sata disks with no spares.
> The raid failed a few days ago claiming that 2 of the 4 disks were
> 'failed spare'.

> After fiddling a bit I re-booted the machine the raid came up nicely,
> but my passphrase isn't recognised any more.
> 'cryptsetup -v luksDump /dev/md0' seems to indicate that the luks
> header is readable and that Key Slot 0 is ENABLED
> All attempts to luksOpen the devide result in "No key available with
> this passphrase."

This likely means that the keyslot got damaged. A single changed
bit is enought to make it unreadable. This is a security-feature.
> I'm at my wits end - can anyone help with some insights please? :-)

The LUKS header and key-slot header neatly fit into a single
typical RAID stripe. If the disk they end up on is intact,
they would be intact.

The keyslots themselves do not fit. In principle,
if there are no bad sectors in the keyslot-0 area, the 
keyslot should still be intact, but there is some reason 
the RAID manager kicked two disks and it seems your 
keyslot now _is_ corrupt. 

In fact I am a bit surprised. A failed RAID array should
not come up again by itself without manual intervention,
even if the disks work fine again.

Ok, first an emergency backup to not make things worse:
Do a LUKS header backup as described in the FAQ 

Then check the RAID status (cat /proc/mdstat).

Can you post the RAID info (or send it directly to me?
Command is mdadm -D /dev/md<nr>

You can also run a RAID consistency check, which is
a bit tricky. The procedure is to read
/sys/block/md<nr>/md/mismatch_cnt to make sure it
is zero, then echo 'check' into 
/sys/block/md<nr>/md/mismatch_cnt, wait until
the ckeck is finished (as visible in /proc/mdstat)
and check the mismatch_cnt again. If it is >0,
then your RAID is in an inconsistent state.
This test should not make changes to the disks.

If the RAID did not assemble again properly,
manual intervention and assembly may be necessary
in order to unlock and safe the data.

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 mailing list