[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#926533: marked as done (linux-image-armmp-lpae: Fail to mount cryptsetup device: missing aes-xts-plain64 cipher)

Your message dated Sun, 1 Sep 2019 21:47:58 +0200
with message-id <20190901214758.303e2f39@erker.lan>
and subject line Re: linux-image-armmp-lpae: Fail to mount cryptsetup device: missing aes-xts-plain64 cipher
has caused the Debian Bug report #926533,
regarding linux-image-armmp-lpae: Fail to mount cryptsetup device: missing aes-xts-plain64 cipher
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 owner@bugs.debian.org
immediately.)


-- 
926533: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926533
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-armmp-lpae
Version: 4.19+104
Severity: normal

Dear Maintainer,

after upgrading from 4.9.144-3 to 4.19+104 I am not able to mount
cryptsetup devices anymore.

  # cryptsetup luksOpen /dev/lvm-foo/crypto foo
  Enter passphrase for /dev/lvm-foo/crypto: 
  device-mapper: reload ioctl on   failed: No such file or directory
  Failed to setup dm-crypt key mapping for device /dev/lvm-foo/crypto.
  Check that kernel supports aes-xts-plain64 cipher (check syslog for more
  info).
  device-mapper: remove ioctl on temporary-cryptsetup-3150  failed: No
  such device or address
  device-mapper: table ioctl on   failed: No such device or address


The output of dmesg is:
  device-mapper: table: 253:8: crypt: Error allocating crypto tfm
  device-mapper: ioctl: error adding target to table


The respective LUKS header of the cryptsetup device looks like this:

  # cryptsetup luksDump /dev/lvm-foo/crypto 
  LUKS header information for /dev/lvm-foo/crypto
  Version:        1
  Cipher name:    aes
  Cipher mode:    xts-plain64
  Hash spec:      sha1
  Payload offset: 4096
  MK bits:        256
  ...


Maybe the lack of the "aes-xts-plain64" cipher is related to the following?

  # dpkg -L linux-image-4.9.0-8-armmp-lpae | grep aes
  /lib/modules/4.9.0-8-armmp-lpae/kernel/drivers/crypto/omap-aes.ko
  # dpkg -L linux-image-4.19.0-4-armmp-lpae | grep aes
  [no output]


I am using a BananaPi M1 board.

Thank you for your time!

Cheers,
Lars

--- End Message ---
--- Begin Message --- 
Version: 5.2.9-2

Hello,

recent changes (after Buster) seems to have resolved the issue in newer
packages.

Thus the state of cryptsetup working with the different kernel versions on ARM
is the following:
* Stretch (linux-image-4.9.0-9-armmp-lpae): OK
* Buster (linux-image-4.19.0-5-armmp-lpae): failure
* Bullseye/testing (linux-image-5.2.0-2-armmp-lpae): OK



On Sat, 06 Apr 2019 18:15:08 +0200 Lars Kruse <devel@sumpfralle.de> wrote:
> Maybe the lack of the "aes-xts-plain64" cipher is related to the following?
> 
>   # dpkg -L linux-image-4.9.0-8-armmp-lpae | grep aes
>   /lib/modules/4.9.0-8-armmp-lpae/kernel/drivers/crypto/omap-aes.ko
>   # dpkg -L linux-image-4.19.0-4-armmp-lpae | grep aes
>   [no output]

this theorie turned out to be a red herring: the above file is not part of the
5.2.0-2 package, but cryptsetup works nevertheless.
I have no other clue, how to check the state of cryptsetup support, except for
running cryptsetup itself.

The following modules are loaded during a successful cryptsetup run:
* xts
* gf128mul
* algif_skcipher
* af_alg

But they can be successfully loaded in the failing kernel package version, as
well. Thus these kernel modules are not sufficient indicators of success.

Summary: the problems seems to affect only the Buster release (which is still a
pity).
(marking the bug as closed for the later version)

Cheers,
Lars

--- End Message ---
Reply to: