Re: Can't mount my LUKS crypted disk after kernel update / reboot

[Philipp Durrer <philipp@xxxxxxxxxxxxxxxxxxx>]

2012/12/16 Milan Broz <gmazyland@xxxxxxxxx>

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.

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