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

Clayton ckoeni at gmail.com
Mon Jun 28 03:36:51 UTC 2010


Hi'ya Jonas,

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

> also you should take a look at /var/log/syslog, and
> at /dev/disk/by-id/ in order to find out which device is the
> encrypted partition on external USB drive.

On my system recently, syslog suddenly contains not much of
anything. /var/log/messages contains (this time around):

kernel: usb 2-2: New USB device found, idVendor=058f, idProduct=6390
kernel: usb 2-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
kernel: usb 2-2: Product: USB TO IDE Bridge
kernel: usb 2-2: Manufacturer: Generic 
kernel: usb 2-2: configuration #1 chosen from 1 choice 
kernel: scsi6 : SCSI emulation for USB Mass Storage devices 
kernel: scsi 6:0:0:0: Direct-Access Generic USB Disk 9.02 PQ: 0 ANSI: 2
kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
kernel: sd 6:0:0:0: [sdc] 320173056 512-byte logical blocks: (163
GB/152 GiB) 
kernel: sd 6:0:0:0: [sdc] Write Protect is off 
kernel: sdc: sdc1 sdc2 
kernel: sd 6:0:0:0: [sdc] Attached SCSI disk

all of which looks fine to me. And

# ll /dev/disk/by-id/
total 0
ata-HITACHI_DK23EA-30_N49571 -> ../../sda 
ata-HITACHI_DK23EA-30_N49571-part1 -> ../../sda1 
ata-HITACHI_DK23EA-30_N49571-part2 -> ../../sda2 
ata-HITACHI_DK23EA-30_N49571-part3 -> ../../sda3
ata-HITACHI_DK23EA-30_N49571-part4 -> ../../sda4
dm-name-backcrypt -> ../../dm-0
dm-uuid-CRYPT-PLAIN-backcrypt -> ../../dm-0 
scsi-SATA_HITACHI_DK23EA-_N49571 -> ../../sda 
scsi-SATA_HITACHI_DK23EA-_N49571-part1 -> ../../sda1 
scsi-SATA_HITACHI_DK23EA-_N49571-part2 -> ../../sda2 
scsi-SATA_HITACHI_DK23EA-_N49571-part3 -> ../../sda3 
scsi-SATA_HITACHI_DK23EA-_N49571-part4 -> ../../sda4 
usb-Generic_USB_Disk-0:0 -> ../../sdc 
usb-Generic_USB_Disk-0:0-part1 -> ../../sdc1
usb-Generic_USB_Disk-0:0-part2 -> ../../sdc2

which certainly shows crypto going on, though this system has not been
rebooted since my last attempt to mount, and those two dm- entries
are still there because I never removed the crypto 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.....

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

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

But, if the device has not been truly unlocked because of a crypto
problem, should blkid be seeing an ext3 file system?

Clayton





More information about the pkg-cryptsetup-devel mailing list