[dm-crypt] Weird cryptsetup-1.6.x problem
sven at whgl.uni-frankfurt.de
Thu Aug 29 19:10:41 CEST 2013
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
# 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  (*1)
# dm versions OF  (*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  (*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.
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
>> 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
>> 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
>> 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.
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt