Hi List/Milan, I guess I forgot to mention, that I checked dmesg for any relevant kernel messages, but without any luck. I guess that's why I thought the problem was weird in the first place. I can't do any debugging as the box is located at a remote site, anyway, I managed to get a dump of a corresponding run of cryptsetup: # cryptsetup 1.6.2 processing "cryptsetup --debug -v -d /kspace/nas/d6c5ffe8-a53a-4497-91ca-be95ca04929c.bin luksOpen /dev/md127 d6c5ffe8-a53a-4497-91ca-be95ca04929c" # Running command open. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /dev/md127 context. # Trying to open and read device /dev/md127. # Initialising device-mapper backend library. # Trying to load LUKS1 crypt type from device /dev/md127. # Crypto backend (Linux 3.4.29 kernel cryptoAPI) initialized. # Reading LUKS header of size 1024 from device /dev/md127 # Key length 32, device size 536872960 sectors, header size 2050 sectors. # Timeout set to 0 miliseconds. # Password retry count set to 3. # Password verification disabled. # Iteration time set to 1000 miliseconds. # Password retry count set to 1. # Activating volume d6c5ffe8-a53a-4497-91ca-be95ca04929c [keyslot -1] using keyfile /kspace/nas/d6c5ffe8-a53a-4497-91ca-be95ca04929c.bin. # Detected kernel Linux 3.4.29 x86_64. # dm version OF [16384] (*1) # dm versions OF [16384] (*1) # Detected dm-crypt version 1.11.0, dm-ioctl version 4.22.0. # Device-mapper backend running with UDEV support disabled. # dm status d6c5ffe8-a53a-4497-91ca-be95ca04929c OF [16384] (*1) # File descriptor passphrase entry requested. # Trying to open key slot 0 [ACTIVE]. # Releasing crypt device /dev/md127 context. # Releasing device-mapper backend. # Unlocking memory. I personally can't see anything unexpected here, but then again, I am not sure, what the output should look like. Regards -Sven On Thu, August 29, 2013 07:27, Milan Broz wrote: > On 28.8.2013 23:48, Sven Eschenberg wrote: >> Hi List, >> >> After upgrading one of my systems I ran into the following rather >> strange >> problem: >> >> I use an initramfs which uses cryptsetup for the initial mapping, later >> during boot more mappings are added. >> >> After upgrading to a 1.6.x version of cryptsetup the system does boot >> fine, with old initramfs (still holding old cryptsetup), but a new >> kernel >> with updated cinitramfs won't boot. Unfortunately I don't have the exact >> same kernel with both initramfses at hand, so the kernel was upgraded >> too. >> >> cryptsetup fails and states command failed, code 22, which afaik means >> invalid parameter. That could indicate that something from the kernel is >> missing, but I checked back and AES, XTS, ripmed, dmcrypt target are all >> in the kernel (even not modular, to ease startup). > > If it is kernel, there must be error message in syslog (use some kernel > parameter to display log to console, depends on used init system). > It looks like that some module is missing in initramfs... > > (Unfortunately all I get from kernel device-mapper if it fails is -EINVAL, > that's why userspace cannot sometimes display better info. > Anyway, running cryptsetup with --debug can provide more info as well. > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
