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

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

[Philipp Durrer - Nexus Informatik]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

Hi

 

I've got a very serious issue, I can't mount my LUKS crypted software raid
disk after a regular kernel update (Ubuntu 11.10, Kernel 3.0.0-12-generic to
3.0.0-17-generic) and a following reboot.

 

After the reboot the raid disks start properly and are active:

 

>cat /proc/mdstat

>Personalities : [raid0] [raid1] [linear] [multipath] [raid6] [raid5]
[raid4] [raid10]

>md0 : active raid1 sda2[0] sdb2[1]

>      488269 blocks super 1.2 [2/2] [UU]

> 

>md2 : active raid1 sda4[0] sdb4[1]

>      3905214 blocks super 1.2 [2/2] [UU]

> 

>md126 : active raid0 sda5[0] sdb5[1]

>      5832190976 blocks super 1.2 512k chunks

> 

>md1 : active raid1 sda3[0] sdb3[1]

>      9764529 blocks super 1.2 [2/2] [UU]

> 

>md127 : active raid0 sdd1[1] sdc1[0]

>      5860530176 blocks super 1.2 512k chunks

> 

>unused devices: <none>

 

The LUKS header looks fine aswell:

>cryptsetup luksDump /dev/md126

>LUKS header information for /dev/md126

> 

>Version:        1

>Cipher name:    aes

>Cipher mode:    xts-essiv:sha256

>Hash spec:      sha1

>Payload offset: 4096

>MK bits:        512

>MK digest:      f0 59 ac a8 13 3c e1 XX YY ZZ ce 0f ba cd 63 0a 4a d0 25 b2

>MK salt:        e8 3f fc 25 3a 0e a3 XX XX YY ZZ 45 1c 12 31 f6

>                cb ea 03 d2 51 66 f9 4c 51 c4 29 4d 97 4f 17 0f

>MK iterations:  33375

>UUID:           1686eb8f-be62-462b-9326-319a7cc8e087

> 

>Key Slot 0: ENABLED

>        Iterations:             133653

>        Salt:                   c1 d9 a0 ff 6e 7a XX XX YY ZZ a7 67 dc 8f
10 93

>                                4e a2 9c 9e d8 39 4f 91 37 3d e3 8f df 24
dc 60

>        Key material offset:    8

>        AF stripes:             4000

>Key Slot 1: DISABLED

>Key Slot 2: DISABLED

>Key Slot 3: DISABLED

>Key Slot 4: DISABLED

>Key Slot 5: DISABLED

>Key Slot 6: DISABLED

>Key Slot 7: DISABLED

 

I can aswell open the Disk successful without compaints:

>cryptsetup -d /keystore/tempstuff1 luksOpen /dev/md126 stuff

>cryptsetup status stuff

>/dev/mapper/stuff is active.

>  type:    LUKS1

>  cipher:  aes-xts-essiv:sha256

>  keysize: 512 bits

>  device:  /dev/md126

>  offset:  4096 sectors

>  size:    11664377856 sectors

>  mode:    read/write

 

But when I try to mount the device mapper disk I get compaints:

>mount /dev/mapper/stuff /home/crypt/

>mount: you must specify the filesystem type

 

> mount -t ext4 /dev/mapper/stuff /home/crypt/

>mount: wrong fs type, bad option, bad superblock on /dev/mapper/stuff,

>       missing codepage or helper program, or other error

>       In some cases useful info is found in syslog - try

>       dmesg | tail  or so

 

> dmesg | tail

>[12124.435471] EXT4-fs (dm-5): VFS: Can't find ext4 filesystem

 

Filesystem check doesn't work either :(

 

>fsck.ext4 /dev/mapper/stuff

>e2fsck 1.41.14 (22-Dec-2010)

>fsck.ext4: Superblock invalid, trying backup blocks...

>fsck.ext4: Bad magic number in super-block while trying to open
/dev/mapper/stuff

>.

 

I can't see any updated dependencies of cryptsetup that are related to this
issue, I had the default cryptsetup version 1.1.3 on the box and now tried
with 1.5.1 with no success :(

Any ideas ? I would greatly appreciate any inputs helping me, that I don't
lose about 12 TB  of precious data. -.-

 

Thank you.

Regards


[-- Attachment #2: Type: text/html, Size: 13825 bytes --]

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

[Javier Juan Martínez Cabezón]

On 13/12/12 21:36, Philipp Durrer - Nexus Informatik wrote:
> Hi
> 
> 
> 
> I've got a very serious issue, I can't mount my LUKS crypted
> software raid disk after a regular kernel update (Ubuntu 11.10,
> Kernel 3.0.0-12-generic to 3.0.0-17-generic) and a following
> reboot.
> 
> 
> 
> After the reboot the raid disks start properly and are active:
> 
> 
> 
>> cat /proc/mdstat
> 
>> Personalities : [raid0] [raid1] [linear] [multipath] [raid6]
>> [raid5]
> [raid4] [raid10]
> 
>> md0 : active raid1 sda2[0] sdb2[1]
> 
>> 488269 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md2 : active raid1 sda4[0] sdb4[1]
> 
>> 3905214 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md126 : active raid0 sda5[0] sdb5[1]
> 
>> 5832190976 blocks super 1.2 512k chunks
> 
>> 
> 
>> md1 : active raid1 sda3[0] sdb3[1]
> 
>> 9764529 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md127 : active raid0 sdd1[1] sdc1[0]
> 
>> 5860530176 blocks super 1.2 512k chunks
> 
>> 
> 
>> unused devices: <none>
> 
> 
> 
> The LUKS header looks fine aswell:
> 
>> cryptsetup luksDump /dev/md126
> 
>> LUKS header information for /dev/md126
> 
>> 
> 
>> Version:        1
> 
>> Cipher name:    aes
> 
>> Cipher mode:    xts-essiv:sha256
> 
>> Hash spec:      sha1
> 
>> Payload offset: 4096
> 
>> MK bits:        512
> 
>> MK digest:      f0 59 ac a8 13 3c e1 XX YY ZZ ce 0f ba cd 63 0a
>> 4a d0 25 b2
> 
>> MK salt:        e8 3f fc 25 3a 0e a3 XX XX YY ZZ 45 1c 12 31 f6
> 
>> cb ea 03 d2 51 66 f9 4c 51 c4 29 4d 97 4f 17 0f
> 
>> MK iterations:  33375
> 
>> UUID:           1686eb8f-be62-462b-9326-319a7cc8e087
> 
>> 
> 
>> Key Slot 0: ENABLED
> 
>> Iterations:             133653
> 
>> Salt:                   c1 d9 a0 ff 6e 7a XX XX YY ZZ a7 67 dc
>> 8f
> 10 93
> 
>> 4e a2 9c 9e d8 39 4f 91 37 3d e3 8f df 24
> dc 60
> 
>> Key material offset:    8
> 
>> AF stripes:             4000
> 
>> Key Slot 1: DISABLED
> 
>> Key Slot 2: DISABLED
> 
>> Key Slot 3: DISABLED
> 
>> Key Slot 4: DISABLED
> 
>> Key Slot 5: DISABLED
> 
>> Key Slot 6: DISABLED
> 
>> Key Slot 7: DISABLED
> 
> 
> 
> I can aswell open the Disk successful without compaints:
> 
>> cryptsetup -d /keystore/tempstuff1 luksOpen /dev/md126 stuff
> 
>> cryptsetup status stuff
> 
>> /dev/mapper/stuff is active.
> 
>> type:    LUKS1
> 
>> cipher:  aes-xts-essiv:sha256
> 
>> keysize: 512 bits
> 
>> device:  /dev/md126
> 
>> offset:  4096 sectors
> 
>> size:    11664377856 sectors
> 
>> mode:    read/write
> 
> 
> 
> But when I try to mount the device mapper disk I get compaints:
> 
>> mount /dev/mapper/stuff /home/crypt/
> 
>> mount: you must specify the filesystem type
> 
> 
> 
>> mount -t ext4 /dev/mapper/stuff /home/crypt/
> 
>> mount: wrong fs type, bad option, bad superblock on
>> /dev/mapper/stuff,
> 
>> missing codepage or helper program, or other error
> 
>> In some cases useful info is found in syslog - try
> 
>> dmesg | tail  or so
> 
> 
> 
>> dmesg | tail
> 
>> [12124.435471] EXT4-fs (dm-5): VFS: Can't find ext4 filesystem
> 
> 
> 
> Filesystem check doesn't work either :(
> 
> 
> 
>> fsck.ext4 /dev/mapper/stuff
> 
>> e2fsck 1.41.14 (22-Dec-2010)
> 
>> fsck.ext4: Superblock invalid, trying backup blocks...
> 
>> fsck.ext4: Bad magic number in super-block while trying to open
> /dev/mapper/stuff
> 
>> .
> 
> 
> 
> I can't see any updated dependencies of cryptsetup that are related
> to this issue, I had the default cryptsetup version 1.1.3 on the
> box and now tried with 1.5.1 with no success :(
> 
> Any ideas ? I would greatly appreciate any inputs helping me, that
> I don't lose about 12 TB  of precious data. -.-
> 
> 
> 
> Thank you.
> 
> Regards
> 
> 
> 
> 
> 
> _______________________________________________ dm-crypt mailing
> list dm-crypt@saout.de 
> http://www.saout.de/mailman/listinfo/dm-crypt


Your solution is in the FAQ ;), section issues

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

[Javier Juan Martínez Cabezón]

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?


On 13/12/12 21:36, Philipp Durrer - Nexus Informatik wrote:
> Hi
> 
> 
> 
> I've got a very serious issue, I can't mount my LUKS crypted
> software raid disk after a regular kernel update (Ubuntu 11.10,
> Kernel 3.0.0-12-generic to 3.0.0-17-generic) and a following
> reboot.
> 
> 
> 
> After the reboot the raid disks start properly and are active:
> 
> 
> 
>> cat /proc/mdstat
> 
>> Personalities : [raid0] [raid1] [linear] [multipath] [raid6]
>> [raid5]
> [raid4] [raid10]
> 
>> md0 : active raid1 sda2[0] sdb2[1]
> 
>> 488269 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md2 : active raid1 sda4[0] sdb4[1]
> 
>> 3905214 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md126 : active raid0 sda5[0] sdb5[1]
> 
>> 5832190976 blocks super 1.2 512k chunks
> 
>> 
> 
>> md1 : active raid1 sda3[0] sdb3[1]
> 
>> 9764529 blocks super 1.2 [2/2] [UU]
> 
>> 
> 
>> md127 : active raid0 sdd1[1] sdc1[0]
> 
>> 5860530176 blocks super 1.2 512k chunks
> 
>> 
> 
>> unused devices: <none>
> 
> 
> 
> The LUKS header looks fine aswell:
> 
>> cryptsetup luksDump /dev/md126
> 
>> LUKS header information for /dev/md126
> 
>> 
> 
>> Version:        1
> 
>> Cipher name:    aes
> 
>> Cipher mode:    xts-essiv:sha256
> 
>> Hash spec:      sha1
> 
>> Payload offset: 4096
> 
>> MK bits:        512
> 
>> MK digest:      f0 59 ac a8 13 3c e1 XX YY ZZ ce 0f ba cd 63 0a
>> 4a d0 25 b2
> 
>> MK salt:        e8 3f fc 25 3a 0e a3 XX XX YY ZZ 45 1c 12 31 f6
> 
>> cb ea 03 d2 51 66 f9 4c 51 c4 29 4d 97 4f 17 0f
> 
>> MK iterations:  33375
> 
>> UUID:           1686eb8f-be62-462b-9326-319a7cc8e087
> 
>> 
> 
>> Key Slot 0: ENABLED
> 
>> Iterations:             133653
> 
>> Salt:                   c1 d9 a0 ff 6e 7a XX XX YY ZZ a7 67 dc
>> 8f
> 10 93
> 
>> 4e a2 9c 9e d8 39 4f 91 37 3d e3 8f df 24
> dc 60
> 
>> Key material offset:    8
> 
>> AF stripes:             4000
> 
>> Key Slot 1: DISABLED
> 
>> Key Slot 2: DISABLED
> 
>> Key Slot 3: DISABLED
> 
>> Key Slot 4: DISABLED
> 
>> Key Slot 5: DISABLED
> 
>> Key Slot 6: DISABLED
> 
>> Key Slot 7: DISABLED
> 
> 
> 
> I can aswell open the Disk successful without compaints:
> 
>> cryptsetup -d /keystore/tempstuff1 luksOpen /dev/md126 stuff
> 
>> cryptsetup status stuff
> 
>> /dev/mapper/stuff is active.
> 
>> type:    LUKS1
> 
>> cipher:  aes-xts-essiv:sha256
> 
>> keysize: 512 bits
> 
>> device:  /dev/md126
> 
>> offset:  4096 sectors
> 
>> size:    11664377856 sectors
> 
>> mode:    read/write
> 
> 
> 
> But when I try to mount the device mapper disk I get compaints:
> 
>> mount /dev/mapper/stuff /home/crypt/
> 
>> mount: you must specify the filesystem type
> 
> 
> 
>> mount -t ext4 /dev/mapper/stuff /home/crypt/
> 
>> mount: wrong fs type, bad option, bad superblock on
>> /dev/mapper/stuff,
> 
>> missing codepage or helper program, or other error
> 
>> In some cases useful info is found in syslog - try
> 
>> dmesg | tail  or so
> 
> 
> 
>> dmesg | tail
> 
>> [12124.435471] EXT4-fs (dm-5): VFS: Can't find ext4 filesystem
> 
> 
> 
> Filesystem check doesn't work either :(
> 
> 
> 
>> fsck.ext4 /dev/mapper/stuff
> 
>> e2fsck 1.41.14 (22-Dec-2010)
> 
>> fsck.ext4: Superblock invalid, trying backup blocks...
> 
>> fsck.ext4: Bad magic number in super-block while trying to open
> /dev/mapper/stuff
> 
>> .
> 
> 
> 
> I can't see any updated dependencies of cryptsetup that are related
> to this issue, I had the default cryptsetup version 1.1.3 on the
> box and now tried with 1.5.1 with no success :(
> 
> Any ideas ? I would greatly appreciate any inputs helping me, that
> I don't lose about 12 TB  of precious data. -.-
> 
> 
> 
> Thank you.
> 
> Regards
> 
> 
> 
> 
> 
> _______________________________________________ dm-crypt mailing
> list dm-crypt@saout.de 
> http://www.saout.de/mailman/listinfo/dm-crypt

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

[Milan Broz]

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.

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


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

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

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

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

(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.

Milan

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

[Philipp Durrer]

[-- Attachment #1: Type: text/plain, Size: 5908 bytes --]

2012/12/16 Milan Broz <gmazyland@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.

[-- Attachment #2: Type: text/html, Size: 7529 bytes --]

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

[Milan Broz]

On 12/16/2012 07:11 PM, Philipp Durrer wrote:

> dmsetup table --showkeys

Hm, I should said do compare but do NOT send this to list
(it contains volume key).

You should reencrypt your devices now...
(including truecrypt device you have mapped, because they are no longer
secure)

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

That's fine, it should be LUKS device without partition
(this message is misleading and should be removed from kernel IMO)

I thihk LUKS/dmcrypt  works as expected here, something was corrupted in MD or ext4.


> 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.

check plain (unlocked) luks device as well, maybe you will see some pattern
which explains that why overwritten (it apparently missing ext4 or any known signature
to blkid)

Milan

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

[Arno Wagner]

On Sun, Dec 16, 2012 at 07:11:22PM +0100, Philipp Durrer wrote:
> 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

Woah, stop! Or rather too late. Everybody in the internet now has
your master keys and can decrypt your devices!

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

It has to be. LUKS does nto decrypt is anything at all with it is
broken. Unlike plain dm-crypt that will happily decrypt with 
everything wrong and produce just random-looking stuff.

Now, if you look into the FAQ, item 6.12, you will see that the
satart of the md device has to be intact for decyption to happen.
Also, what superblock format did you use? 
"mdadm --examine <some raid component>" should tell you.
The idea is that if it is 1.1 or 1.2 then the md superblock
are also at the beginning. Overwrites typicallyt happen 
at the beginning, not somewhere in there,
 
Just to be sure: Does maybe the new kernel not support the
filesystem you are using? Maybe this is a module-loading
problem?

What you also can try is to specify an alternate superblock
for mount. The option for that is e.g. "sb=131072" (from the
man-page)

[...]
 
> 
> 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.

Well, it would be nice to find out what caused this, but
I can understand that you do not want to invest too much more
time.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell