[pkg-cryptsetup-devel] Bug#586120: Bug#586120: device-mapper: reload ioctl failed: Invalid argument

[Clayton]

Jonas, it works now! More below.....

On Mon, 28 Jun 2010 10:46:39 +0200
Jonas Meurer <jonas at freesources.org> wrote:

> Hey Clayton,
> 
> On 28/06/2010 Clayton wrote:
> > On Sun, 27 Jun 2010 11:35:31 +0200
> > Jonas Meurer <jonas at freesources.org> wrote:
> > 
> > > On 27/06/2010 Clayton wrote:
> > > > On Sat, 26 Jun 2010 12:32:02 +0200
> > > > Jonas Meurer <jonas at freesources.org> wrote:
> > >
> > > what does 'blkid /dev/mapper/backcrypt' return?
> > 
> > # blkid /dev/mapper/backcrypt
> > /dev/mapper/backcrypt: UUID="77f77add-7913-459a-bf81-d88b70323ad6"
> > SEC_TYPE="ext2" TYPE="ext3"
> > 
> > and then it gives me the above error message again when I try to
> > mount it.....
> 
> that's strange. what does 'fsck.ext3 /dev/mapper/backcrypt' return?

# fsck.ext3 /dev/mapper/backcrypt
e2fsck 1.41.12 (17-May-2010)
fsck.ext3: Superblock invalid, trying backup blocks...
fsck.ext3: The ext2 superblock is corrupt while trying to
open /dev/mapper/backcrypt

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>

# e2fsck -b 8193 /dev/mapper/backcrypt
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to
open /dev/mapper/backcrypt

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>

> > > the default key size and cipher mode changed for plain dm-crypt in
> > > cryptsetup package 2:1.1.0-1. it seems like you don't
> > > use /etc/crypttab at all, where key size and cipher mode can be
> > > configured.
> > 
> > KISS has meant up until now: "don't need crypttab, don't want to
> > mess with it". I am guessing that this may be about to change....
> 
> what is KISS? in my eyes it's better to use crypttab, as you can set
> cipher, hash and key size as well as other options there, and the
> cryptdisks initscript will unlock the device automatically at boot.
> but in the end, it's your decision.

KISS = "Keep It Simple Stupid"
I actually only mount this device once per month to stuff a backup in
it, and don't actually want it open all the time, nor have it mounted
at boot time.

> > > again, 'cryptsetup create' doesn't fail if either passphrase or
> > > cipher/ hash/keysize are wrong. thus the only way to verify
> > > successfull setup is to check the content of unlocked device.
> > > 
> > > try the following (these where the old defaults for cryptsetup
> > > before 1.1.0):
> > > 
> > > # cryptsetup --key-size 128 --cipher aes-cbc-plain create
> > > backcrypt /dev/sdb2
> > > and see what 'blkid /dev/mapper/backcrypt' returns in that case.
> > 
> > Well, this is interesting, I too was expecting this to work but it
> > did not:
> > 
> > cryptsetup --key-size 128 --cipher aes-cbc-plain create
> > backcrypt /dev/sdc2
> > 
> > mount still fails in the same way, and now
> > 
> > # blkid /dev/mapper/backcrypt
> > outputs exactly nothing.
> > 
> > If I remove the device and go back to
> > # cryptsetup create backcrypt /dev/sdc2
> > 
> > I then get, again
> > # blkid /dev/mapper/backcrypt
> > /dev/mapper/backcrypt: UUID="77f77add-7913-459a-bf81-d88b70323ad6"
> > SEC_TYPE="ext2" TYPE="ext3"
> > 
> > and still a broken mount command.
> > 
> > This crypto partition was created several years ago. I wonder if
> > creation defaults have changed more then once since then?
> 
> which cryptsetup version did you use before the upgrade? take a look
> at /var/log/dpkg.log if you're unsure. did you already try to
> downgrade to the old cryptsetup version and see, whether it works
> again?

This looks to me like where it probably broke:
2010-05-02 23:55:40 upgrade cryptsetup 2:1.1.0~rc2-1 2:1.1.0-2.1

> ah, and i was wrong with the changed defaults. the only change to
> plain dm-crypt was the cipher change from aes-cbc-plain to
> aes-cbc-essiv:sha256. so you should try this one instead:
> 
> # cryptsetup -c aes-cbc-plain create backcrypt /dev/sdc2

And yes, this works! Back in business. Since "--key-size 128" seems to
have broken our last attempt, what is the default key size now so that
I can make a record of it? After recent events, it seems quite
important to record the defaults for dm-crypt volumes as insurance
against default changes.

> > But, if the device has not been truly unlocked because of a crypto
> > problem, should blkid be seeing an ext3 file system?
> 
> it's strange indeed. maybe your ext3 filesystem is damaged for some
> reason?

And this behavior (showing the file system of a volume that has
supposedly not been unlocked because I used the wrong cipher?) continues
to be extremely strange. And if I was a security paranoid,
worrisome.....

Looks like you can probably close this bug report down, unless you have
any ideas for making default changes less bumpy.

Thanks for helping to get this working again,
Clayton :-)