Home / ubuntu / Questions / 1286462
In Process
opinion_no9
Asked: 2020-10-24 22:08:50 +0800 CST

20.10 cryptsetup suddenly fails to open luks: Cannot use twofish-ecb cipher for keyslot encryption

  • 772

Since the recent update from 20.04 to 20.10 cryptsetup fails to open luks container.

Message is:

> Cannot use twofish-ecb cipher for keyslot encryption. Keyslot open
> failed. No usable keyslot is available.
  • I was able to open and edit the luks container under Ubuntu 20.04.
  • Only fails since the upgrade.
  • I can still open and edit the luks container under Fedora. Data is still available under Fedora and the luks container itself is fine.

isLuks

is positive,

cryptsetup -v luksDump  /dev/sdx3

brings the expected results, perfect.

issue:

sudo cryptsetup luksOpen /dev/sdx3 luks-61[...]51

successfully requests and accepts passphrase then fails with

> Cannot use twofish-ecb cipher for keyslot encryption. 
> Keyslot open failed. 
> No usable keyslot is available.

Subsequently /dev/mapper does not show this luks mapping while still working fine for the other luks mappings.

Only special thing about /dev/sdx is: it is a btrfs/gpt disk. Working fine with Ubuntu, Fedora, Suse until the upgrade. After the incident started, a resize under Fedora 32 worked fine, no issues (remarkable for shrinking a gpt/btrfs/LUKS partition).

Used to work fine under Ubuntu 20.04 (until the reboot after upgrade to 20.10).

no problem in kern.log BEFORE the upgrade:

Oct 18 16:14:47 kurt kernel: [   24.243562] BTRFS: device label bxxxxxxxx_crypt devid 1 transid 612 /dev/dm-2

Oct 18 16:14:47 kurt kernel: [   24.269818] BTRFS info (device dm-2): use zlib compression, level 3

Oct 18 16:14:47 kurt kernel: [   24.269820] BTRFS info (device dm-2): disk space caching is enabled

Oct 18 16:14:47 kurt kernel: [   24.269821] BTRFS info (device dm-2): has skinny extents

comparing other flavours: Version with U20.10: cryptsetup 2.3.3 (not working, however) Working with Suse 15.1, cryptsetup 2.0.6 and working with Fedora 32, cryptsetup 2.3.4 and used to work with U20.04, cryptsetup 2.2.2 AFAIK.

Why does it fail under Ubuntu 20.10? What can I do to fix it?

btrfs luks cryptsetup 20.10

1 Answers

  1. Not a definitive answer, but your initramfs is missing a crypto module. I got bitten by this myself today, in a slightly different way, but with the same result (hence how I came across this post):

    Cannot use serpent-xts cipher for keyslot encryption. 
Keyslot open failed.

    Both the kernel dmesg and cryptsetup are suspiciously devoid of any messages at all when this happens. Sadly, I can't tell you which module was missing in your case, but in my case it was the cryptd module.

    I don't think the disk layout, or cryptsetup, or even the specific kernel version is to blame here. The most likely cause is the way Debian/Ubuntu systems generate the initramfs on kernel upgrade. Here's how this can fail on a kernel (dist-)upgrade:

    • apt installs a new major kernel version
    • update-initramfs uses the currently loaded modules to gather all the modules your system needs to mount the root filesystem
    • because your system is currently running the old kernel, this list does not contain (A) any new modules, or (B) new dependencies of current modules (or modules that were renamed, etc)
    • your system happily boots the new kernel with an incomplete set of modules in the initramfs

    Normally, you would expect to see "unresolved symbol" errors when a module is missing some dependencies. However, the kernel crypto API provides a generic interface for all crypto algorithms, so the symbols are there, even if a specific algorithm is missing. To add insult to injury, the in-kernel crypto resolver doesn't log any warnings if a requested algorithm is unavailable.

    How to fix?

    Firstly, boot into the new system using your old kernel. Debian always makes sure you can run the current userland on the previous kernel, I imagine Ubuntu does the same.

    Use the following command (or similar) to view all module changes between the kernel versions (all on one line, I split the command for readability):

    diff <(cd /lib/modules/$OLD_KERNEL_VERSION/ && find . -type f) \
     <(cd /lib/modules/$NEW_KERNEL_VERSION/ && find . -type f)

    Lines beginning with > indicate modules that only exist for the new kernel. Given the error, it would be a pretty safe bet that the missing module is a crypto module, so you can add | grep /crypto/ to narrow down the list.

    Once you've identified the likely suspects, you can force them to be included in the initramfs by adding them to /etc/initramfs-tools/modules (one per line) and running update-initramfs -u -k all to regenerate the initramfs.

    It still doesn't work

    The approach here only covers case (A) above, where you are missing a module because it doesn't exist in the old kernel. Case (B) doesn't really have a straightforward fix. You could either make an educated guess, or simply add all the crypto modules to /etc/initramfs-tools/modules, and hope for the best. But better make sure you have the Ubuntu installer ready on USB stick to use its rescue mode (second bullet, the page has no anchors) to boot your system using the correct kernel version.

    • 1