[dm-crypt] Weird cryptsetup-1.6.x problem

[dm-crypt] Weird cryptsetup-1.6.x problem

[Sven Eschenberg]

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

I have no idea, what could be the problem, and the error message doesn't
really help (Bad enough, without the -v option not even an error message
is shown)

Does anyone know, what could yield a Code 22 error during luksOpen? Milan
maybe?

Re: [dm-crypt] Weird cryptsetup-1.6.x problem

[Milan Broz]

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

Re: [dm-crypt] Weird cryptsetup-1.6.x problem

[Sven Eschenberg]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>