Your message dated Tue, 29 Jun 2010 16:51:55 +0200
with message-id <20100629145154.ga4...@resivo.wgnet.de>
and subject line Re: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload
ioctl failed: Invalid argument
has caused the Debian Bug report #586120,
regarding device-mapper: reload ioctl failed: Invalid argument
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
586120: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586120
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: cryptsetup
Version: 2:1.1.2-1
Severity: critical
Justification: causes serious data loss
This has been working fine for years, but now:
# cryptsetup create backcrypt /dev/sda2
Enter passphrase:
device-mapper: reload ioctl failed: Invalid argument
# cryptsetup --debug create backcrypt /dev/sda2
# cryptsetup 1.1.2 processing "cryptsetup --debug create backcrypt /dev/sda2"
# Locking memory.
# Allocating crypt device /dev/sda2 context.
# Trying to open and read device /dev/sda2.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt target of version 1.7.0.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Iteration time set to 1000 miliseconds.
# Password verification disabled.
Enter passphrase:
# dm status backcrypt OF [16384]
# Calculated device size is 1558305 sectors (RW), offset 0.
# DM-UUID is CRYPT-PLAIN-backcrypt
# Udev cookie 0xd4d7c8d (semid 131073) created
# Udev cookie 0xd4d7c8d (semid 131073) incremented
# Udev cookie 0xd4d7c8d (semid 131073) incremented
# Udev cookie 0xd4d7c8d (semid 131073) assigned to dm_task type 0 with flags 0x0
# dm create backcrypt CRYPT-PLAIN-backcrypt OF [16384]
# backcrypt: Stacking NODE_ADD (254,0) 0:6 0660
# dm reload backcrypt OF [16384]
device-mapper: reload ioctl failed: Invalid argument
# Udev cookie 0xd4d7c8d (semid 131073) decremented
# Udev cookie 0xd4d7c8d (semid 131073) incremented
# Udev cookie 0xd4d7c8d (semid 131073) assigned to dm_task type 2 with flags 0x0
# dm remove backcrypt OF [16384]
# backcrypt: Stacking NODE_DEL (replaces other stacked ops)
# Udev cookie 0xd4d7c8d (semid 131073) decremented
# Udev cookie 0xd4d7c8d (semid 131073): Waiting for zero
# Udev cookie 0xd4d7c8d (semid 131073) destroyed
# Releasing crypt device /dev/sda2 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 22: Invalid argument
The only thing in /var/log/messages is:
kernel: [13012.176668] device-mapper: ioctl: error adding target to table
-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686
root=UUID=9fe8865b-d220-468b-b7a4-bf58b16fe562 ro noacpi quiet
-- /etc/crypttab
# <target name> <source device> <key file> <options>
-- /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/hda2 none swap sw 0 0
UUID=4102f17e-4c54-4ae7-bcfe-00fe90391454 none swap sw
0 0
# /dev/hda1 / ext3 defaults,errors=remount-ro 0 1
UUID=9fe8865b-d220-468b-b7a4-bf58b16fe562 / ext3
defaults,errors=remount-ro 0 1
# /dev/hda3 /home ext3 defaults 0 2
UUID=e7278e8b-8010-4339-9c73-4978433da54c /home ext3
defaults 0 2
# /dev/hda4 /home/nzhang ext3 defaults 0 2
UUID=075ef34d-9163-4228-adf8-a7d0c5cb61ef /home/nzhang ext3
defaults 0 2
/dev/disk/by-label/HDEXT115 /media/hdext115 ext3 user,exec,dev,suid,rw 0 0
/dev/disk/by-label/HDEXT20 /media/hdext20 vfat
user,exec,dev,suid,rw,umask=0000 0 0
/dev/disk/by-path/pci-0000:02:00.2-usb-0:2:1.0-scsi-0:0:0:0 /media/jenny4g vfat
user,exec,dev,suid,rw,umask=0000 0 0
/dev/mapper/backcrypt /media/backcrypt ext3 rw,,user 0 0
/dev/mapper/crypt17 /media/crypt17 ext3 rw,,user 0 0
-- lsmod
Module Size Used by
sha256_generic 10748 0
aes_i586 6816 0
aes_generic 25738 1 aes_i586
cbc 2047 0
usb_storage 30461 0
cpufreq_conservative 4018 0
cpufreq_userspace 1480 0
cpufreq_stats 1940 0
cpufreq_powersave 602 0
nf_conntrack_ftp 4272 0
nf_conntrack_irc 2535 0
ipt_REJECT 1517 4
ipt_LOG 3570 7
xt_limit 1088 7
xt_state 927 43
xt_tcpudp 1743 36
nf_conntrack_ipv4 7597 43
nf_conntrack 38067 4
nf_conntrack_ftp,nf_conntrack_irc,xt_state,nf_conntrack_ipv4
nf_defrag_ipv4 779 1 nf_conntrack_ipv4
iptable_filter 1790 1
ip_tables 7690 1 iptable_filter
x_tables 8327 6
ipt_REJECT,ipt_LOG,xt_limit,xt_state,xt_tcpudp,ip_tables
vfat 6570 0
fat 34912 1 vfat
fuse 43758 1
dm_crypt 9127 0
dm_snapshot 18021 0
dm_mirror 9671 0
dm_region_hash 5644 1 dm_mirror
dm_log 6369 2 dm_mirror,dm_region_hash
dm_mod 46082 4 dm_crypt,dm_snapshot,dm_mirror,dm_log
ide_cd_mod 21076 0
ide_core 59618 1 ide_cd_mod
xircom_cb 5685 0
snd_intel8x0 19523 0
snd_intel8x0m 8100 0
snd_ac97_codec 79148 2 snd_intel8x0,snd_intel8x0m
ac97_bus 710 1 snd_ac97_codec
snd_pcm_oss 28671 0
snd_mixer_oss 10461 1 snd_pcm_oss
pcmcia 17442 0
snd_pcm 47214 4
snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss
i2c_piix4 7076 0
yenta_socket 16403 2
rsrc_nonstatic 7057 1 yenta_socket
parport_pc 15799 0
tpm_tis 5496 0
snd_timer 12258 1 snd_pcm
i2c_core 12696 1 i2c_piix4
battery 3782 0
parport 22554 1 parport_pc
processor 26599 1
pcmcia_core 20450 3 pcmcia,yenta_socket,rsrc_nonstatic
psmouse 44653 0
video 14605 0
ac 1640 0
tpm 8137 1 tpm_tis
snd 34363 7
snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
pcspkr 1207 0
evdev 5609 5
soundcore 3450 1 snd
button 3598 0
tpm_bios 3569 1 tpm
snd_page_alloc 5045 3 snd_intel8x0,snd_intel8x0m,snd_pcm
output 1204 1 video
serio_raw 2916 0
ext3 94204 3
jbd 32169 1 ext3
mbcache 3762 1 ext3
sg 15968 0
sr_mod 10770 0
sd_mod 25869 5
crc_t10dif 1012 1 sd_mod
cdrom 26487 2 ide_cd_mod,sr_mod
ata_generic 2019 0
uhci_hcd 16057 0
ata_piix 17640 4
ehci_hcd 27763 0
libata 115665 2 ata_generic,ata_piix
usbcore 98402 4 usb_storage,uhci_hcd,ehci_hcd
thermal 9206 0
scsi_mod 101401 5 usb_storage,sg,sr_mod,sd_mod,libata
nls_base 4541 3 vfat,fat,usbcore
thermal_sys 9378 3 processor,video,thermal
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cryptsetup depends on:
ii dmsetup 2:1.02.48-1 The Linux Kernel Device Mapper use
ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib
ii libdevmapper1.02.1 2:1.02.48-1 The Linux Kernel Device Mapper use
ii libpopt0 1.16-1 lib for parsing cmdline parameters
ii libuuid1 2.16.2-0 Universally Unique ID library
cryptsetup recommends no packages.
Versions of packages cryptsetup suggests:
pn busybox <none> (no description available)
ii dosfstools 3.0.9-1 utilities for making and checking
ii initramfs-tools [linux-initra 0.94.4 tools for generating an initramfs
ii udev 157-1 /dev/ and hotplug management daemo
-- no debconf information
--- End Message ---
--- Begin Message ---
hey,
On 29/06/2010 Clayton wrote:
> Jonas, it works now! More below.....
great, let's see.
> On Mon, 28 Jun 2010 10:46:39 +0200
> Jonas Meurer <jo...@freesources.org> wrote:
> > > 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.
this incident shows one advantage of using crypttab: you configure your
encrypted device the correct way, and afterwards just have to invoke
'cryptdisks_start backcrypt' in order to unlock it.
in order to ignore the device at boot time, the 'noauto' option exists.
see man(5) crypttab for more information.
> > 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
ok, indeed the default cipher changed for plain dm-crypt with cryptsetup
release 1.1.0.
>
> > 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.
great. the default key size should be 256 (if i remember correctly).
consider to put the following into /etc/crypttab:
# <target name> <source device> <key file> <options>
backcrypt /dev/sdc2 none
cipher=aes-cbc-plain,size=256,hash=ripemd160,noauto
> > > 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.....
i guess this is due to the different key size. a different cipher and
hash should give full random data as result, but if only keysize
changes, some decrypted data seems to be consistent.
> Looks like you can probably close this bug report down, unless you have
> any ideas for making default changes less bumpy.
yes, this mail closes the bugreport.
greetings,
jonas
signature.asc
Description: Digital signature
--- End Message ---
