[dm-crypt] Strange kind of corruption on a dm-crypt device
arno at wagner.name
Sat May 14 19:15:18 CEST 2011
On Sat, May 14, 2011 at 06:58:54PM +0300, Oren Held wrote:
> Uh; sorry for the messed message.. will re-paste with clean formatting.
> I'm using dm-crypt for 2 years now and it's rather stable. I'm not using
> luks but only 'cryptsetup create' method. Suddenly this morning, after an
> unclean shutdown, I've encountered a strange problem:
> When I use 'cryptsetup create homes /dev/mapper/myvg-homes' and enter the
> passphrase, instead of creating a new dm device with a proper ext4 fs as
> it used to, I get a bad device. But not *totally* bad.
This means it is not a dm-crypt problem, but rather ordinary
> Fsck/mount fail to find the superblock. Also no backup superblocks are
> available. I did try the 'mkfs -n' for finding the backup superblocks, for
> fsck -b, but none of them works.
Are you sure you did this right? Superblocks are not written
in normal operation.
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.12 (17-May-2010)
> fsck.ext4: Superblock invalid, trying backup blocks...
> fsck.ext4: The ext2 superblock is corrupt while trying to open
> The superblock could not be read or does not describe a correct ext2
> filesystem. If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
> e2fsck -b 8193 <device>
Have you tried e2fsck -b <alternate superblock locations> ?
You need to specify the right blocksize to mke2fs for this
to work, as the location of the backup superblocks is
block size dependent:
"For filesystems with 1k blocksizes, a backup superblock can be found at
block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k
blocksizes, at block 32768."
Same for backup superblocks farther on.
> Why is this case strange? because when I read the device with my naked eye
> (or with 'strings' command) I can see lots of plain, *unencrypted* file
> content. so it seems like some kind of a limbo, decryption worked, but not
> so well...
That is not really possible. Either you get decryption or you do
not. The only exception is that sometimes with the same cipher
but wrong mode or IV schema you could get partial decryption.
> I'm using Debian unstable (kernel 2.6.38-2), which just got the upgrade
> package for cryptsetup 1.3.0 yesterday. I'm not sure if my problem has to do
> with the upgrade, but the timing makes me wonder. I did try downgrading to
> 1.2.0 and to 2.6.37, but it didn't help.
Very likely this is the upgrade.
With very old cryptsetup, the defaults for the IV were different, and you
get some decryption. You need to specify the cipher mode manually. Try
this (cryptsetup 1.0.x defaults):
cryptsetup create -c aes-cbc-plain -s 256 -h ripemd160 <name> <dev>
See Also Section 8 of the FAQ. Note that the defaults changed
when cryptsetup went to version 1.1.x. Also it is possible
that the Debian folks have different defaults, which is
also possible since 1.1.x.
Since you get some decryption, the password hash (-h) and
the cipher (aes) must be correct. The other common choices
are different IV (essiv) or different mode (xts).
> Any suggestion on how to progress? anybody experienced something similar
> recently? I'm still not sure if it's a real bug in cryptsetup/dm/kernel, or
> something broken specifically in my place.
May also something broken in Debian. What are the defaults compiled
into cryptsetup in Debian (cryptsetup --help, right at the bottom)?
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