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

Jonas Meurer jonas at freesources.org
Mon Jun 28 08:46:39 UTC 2010


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:
> > 
> > are you sure that this is the case? what does 'blkid /dev/sda' and
> > 'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no
> > filesystem should be detected.
> 
> desktop1:/media# blkid /dev/sdc1
> /dev/sdc1: LABEL="HDEXT115" UUID="8dd61b60-2aeb-4b00-a056-a86223d6e47c"
> TYPE="ext3" 
> desktop1:/media# blkid /dev/sdc2
> 
> desktop1:/media# blkid /dev/sda1
> /dev/sda1: UUID="9fe8865b-d220-468b-b7a4-bf58b16fe562" TYPE="ext3" 
> desktop1:/media# blkid /dev/sda2
> /dev/sda2: UUID="4102f17e-4c54-4ae7-bcfe-00fe90391454" TYPE="swap" 
> 
> So sdc2 is showing no file system, consistent with an encrypted
> device....

ok, indeed /dev/sdc2 should be the one containing the encrypted device.

> > > So now: cryptsetup create backcrypt /dev/sdb2
> > > works.
> > 
> > this should work for _any_ block device, regardless whether it
> > contains encrypted fs or not. thus the success of above command does
> > not indicate that /dev/sdb2 is the correct device.
> 
> That possibility never occurred to me.... I am now seeing as well that
> it does not complain about a bad password, either....
> 
> > > BUT!!: when I try to mount the partition, this happens:
> > > 
> > > # mount /media/backcrypt/
> > > mount: wrong fs type, bad option, bad superblock on /dev/dm-0,
> > >        missing codepage or helper program, or other error
> > >        In some cases useful info is found in syslog - try
> > >        dmesg | tail  or so
> > 
> > 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?

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

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

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

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

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100628/f7af105d/attachment.pgp>


More information about the pkg-cryptsetup-devel mailing list