[dm-crypt] Can't mount my LUKS crypted disk after kernel update / reboot

Philipp Durrer philipp at nexus-informatik.ch
Sun Dec 16 19:11:22 CET 2012


2012/12/16 Milan Broz <gmazyland at gmail.com>

> On 12/16/2012 10:24 AM, Javier Juan Martínez Cabezón wrote:
> >
> > I think I answer too fast before, sorry.
> >
> > Did strings answer something known in the device?
> >
> > Are you sure that this is true?   aes-xts-essiv:sha256
> > Which cipher did you use with cryptsetup 1.1?
>
> Please do not confuse it even more, this is LUKS, not plain device
> where default cipher changed.
>
>
cipher is definitly aes-xts-essiv:sha256 since luksFormat command was the
following:
cryptsetup -c "aes-xts-essiv:sha256" -s 512 luksFormat /dev/md126
/keystore/tempstuff1


> So it is LUKS and if there was no header rewrite, parameters are correct,
> (there was no reformat and cipher parameter is in LUKS header).
>
> If it is properly unlocked, master key is correct as well.
>
> So I guess there were no LUKS format and dmcrypt had no obvious problems
> in this kernel, I would say, the problem is not in this layer.
>
> cryptsetup userspace should not be problem, to verify it
> run dmsetup table --showkeys and compare output with old/new version
> - if it is same there is definitely no problem in
> userspace / LUKS
>

dmsetup table --showkeys
truecrypt1_1: 0 204288 crypt serpent-xts-plain64
6194df1a929675daf3792880da3f36f79b819e7f4e42267e6f25deedd172a231a7bcfc84c0853c5413666fbadf93ea096f98cdf1944080859d3a88b6cd99c209
256 7:0 256
truecrypt2: 0 10485248 crypt twofish-xts-plain64
36fee68d56029b9dfbe969a76f10c7f9db17ab4305e974e6affd128f1a57b58ccaa0e12bf13ee5e27f67e991222dd0c6ad8bfea9ab9b3ea053d90f8d50d81879
256 253:3 0
truecrypt1_0: 0 204288 crypt twofish-xts-plain64
e3200b4f4e95e99222cdcbcd70c75bf8ed14ae7993c4f00446437ba96939feb8ea9fa9d2724fb865bc05740253604e9024e82e8a392e2274150488f69cff23d6
256 253:0 0
truecrypt1: 0 204288 crypt aes-xts-plain64
db606af9d8f18fa7d78750765272d79c86eb1958aef7c835c6b6927aaef8f2bf1d5e964c6b0d6e0e32d812fac0d952245be1630b108a7d90310190509d78660b
256 253:1 0
truecrypt2_0: 0 10485248 crypt aes-xts-plain64
e574ef4dc7c75fbf56bb2f3520414c371fda1f4df8b54ceab2adf0409518df81537b6e7d7edbd46db493f00bd5cd2657d42f12e7f36f4addf9e83de0a9bd7f72
256 7:1 256
stuff: 0 11664377856 crypt aes-xts-essiv:sha256
4c8bab80fd627b8f5bbff24d3f458d5555b19c340352c5f14f980227b157089b8d466ba555873ce8edb8dc101c96c8c0f96a1f79c2124076589c11a4f7453a7b
0 9:126 4096


>
> So IMHO the problem is in MD layer, ext4, or in some unexpected device
> rewrite during update or so.
>

that's what I think aswell


>
> - check syslog, mainly time before/after upgrade.
> Maybe it was broken already there.
>

Just found something in dmesg from first reboot:
[    2.267200] md/raid0:md126: looking at sda5
[    2.267205] md/raid0:md126:   comparing sda5(5832190976) with
sda5(5832190976)
[    2.267210] md/raid0:md126:   END
[    2.267213] md/raid0:md126:   ==> UNIQUE
[    2.267215] md/raid0:md126: 1 zones
[    2.267218] md/raid0:md126: looking at sdb5
[    2.267221] md/raid0:md126:   comparing sdb5(5832190976) with
sda5(5832190976)
[    2.267226] md/raid0:md126:   EQUAL
[    2.267228] md/raid0:md126: FINAL 1 zones
[    2.267232] md/raid0:md126: done.
[    2.267235] md/raid0:md126: md_size is 11664381952 sectors.
[    2.267238] ******* md126 configuration *********
[    2.267241] zone0=[sda5/sdb5/]
[    2.267246]         zone offset=0kb device offset=0kb size=5832190976kb
[    2.267249] **********************************
[    2.267250]
[    2.267261] md126: detected capacity change from 0 to 5972163559424
[    2.314814]  md126: unknown partition table

[    2.081249] md: bind<sdc1>
[    2.082846] md: bind<sdd1>
[    2.084128] md: raid0 personality registered for level 0
[    2.084220] bio: create slab <bio-1> at 1
[    2.084224] md/raid0:md127: looking at sdd1
[    2.084226] md/raid0:md127:   comparing sdd1(5860530176) with
sdd1(5860530176)
[    2.084228] md/raid0:md127:   END
[    2.084229] md/raid0:md127:   ==> UNIQUE
[    2.084230] md/raid0:md127: 1 zones
[    2.084232] md/raid0:md127: looking at sdc1
[    2.084233] md/raid0:md127:   comparing sdc1(5860530176) with
sdd1(5860530176)
[    2.084235] md/raid0:md127:   EQUAL
[    2.084237] md/raid0:md127: FINAL 1 zones
[    2.084239] md/raid0:md127: done.
[    2.084240] md/raid0:md127: md_size is 11721060352 sectors.
[    2.084242] ******* md127 configuration *********
[    2.084243] zone0=[sdc1/sdd1/]
[    2.084246]         zone offset=0kb device offset=0kb size=5860530176kb
[    2.084247] **********************************
[    2.084248]
[    2.084253] md127: detected capacity change from 0 to 6001182900224
[    2.085855]  md127: unknown partition table

unknown partition table doesn't look good to me, but I can see this error
for other md drives aswell.


> - check blkid -p on the device - does it detect some known signature?
>

blkid -p /dev/md12*
/dev/md126: UUID="1686eb8f-be62-462b-9326-319a7cc8e087" VERSION="1"
TYPE="crypto_LUKS" USAGE="crypto"
/dev/md127: UUID="2c6299cf-7527-407c-b210-62d0ae43d469" VERSION="1"
TYPE="crypto_LUKS" USAGE="crypto"
blkid -p /dev/mapper/stuff
<no output>


>
> - boot to old kernel, does it work? Or it is broken?
>

same behaivour on old kernel. Can do luksOpen w/o problems but unable to
mount fs.


>
> (And read the FAQ, there is a lot of other hints.)
>
> >>> md126 : active raid0 sda5[0] sdb5[1]
> >>> 5832190976 blocks super 1.2 512k chunks
> ...
>
> >>> cryptsetup luksDump /dev/md126
>
> So this is your device, RAID0. Read first kb and
> check what's there now with blkid etc.
>

I did check the keyslot with the keyslot_checker in misc, did report that
everything looks fine.
Did aswell check the disk with hd tool and looks fine aswell all random
data up to 0x20000 where data begins.

If no other ideas come to mind until tomorrow I will reformat the disks I
think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20121216/98a3df2f/attachment.html>


More information about the dm-crypt mailing list