20.10密码设置突然无法打开luks:不能使用双欧洲央行密码进行密钥槽加密。

Question

由于最近的更新从20.04到20.10密码设置未能打开luks容器。

信息是：

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

• 我能够打开和编辑Ubuntu20.04下的luks容器。
• 只有升级后才会失败。
• 我仍然可以打开和编辑Fedora下的luks容器。Fedora下的数据仍然可用，luks容器本身也很好。

isLuks

是积极的，

cryptsetup -v luksDump  /dev/sdx3

带来了预期的结果，完美。

发行：

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

成功地请求和接受密码，然后用

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

随后，/dev/mapper没有显示这个luks映射，而对其他luks映射仍然很好。

/dev/sdx唯一的特别之处是:它是一个btrfs/gpt磁盘。与Ubuntu，Fedora，Suse一起工作，直到升级。事件开始后，Fedora 32下的调整大小很好，没有问题(因为缩小了gpt/btrfs/LUKS分区)。

以前在Ubuntu20.04下工作很好(直到升级到20.10之后重新启动)。

升级前kern.log中没有问题：

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

比较其他版本:版本与U20.10:密码安装2.3.3 (但不起作用)与Suse 15.1，密码安装2.0.6和使用Fedora 32，密码安装2.3.4，并用于与U20.04，密码安装2.2.2 AFAIK。

为什么它在Ubuntu20.10下失败了？我能做些什么来解决这个问题？

Answer 1

不是一个明确的答案，但是你的initramfs缺少一个密码模块。今天，我自己也被咬了一口，方式略有不同，但结果却是一样的(因此我看到了这篇文章)：

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

当这种情况发生时，内核dmesg和密码设置都令人怀疑地没有任何消息。遗憾的是，我无法告诉您在您的情况下丢失了哪个模块，但在我的例子中，是cryptd模块。

我不认为磁盘布局、密码设置，甚至是特定的内核版本应该受到指责。最有可能的原因是Debian/Ubuntu系统在内核升级时生成initramfs的方式。下面是如何在内核(dist-)升级时失败：

• apt安装了一个新的主要内核版本
• update-initramfs使用当前加载的模块来收集系统挂载根文件系统所需的所有模块。
• 由于您的系统目前正在运行旧内核，此列表不包含(A)任何新模块，或(B)当前模块(或重命名的模块等)的新依赖项。
• 您的系统愉快地使用initramfs中一组不完整的模块引导新内核。

通常，当模块缺少某些依赖项时，您可能会看到“未解决的符号”错误。然而，内核密码API为所有密码算法提供了一个通用接口，因此即使缺少特定的算法，符号也是存在的。更糟的是，如果请求的算法不可用，内核内密码解析器不会记录任何警告。

如何修复？

首先，使用旧内核引导到新系统。Debian总是确保您可以在以前的内核上运行当前的用户，我想Ubuntu也是这样做的。

使用以下命令(或类似的命令)查看内核版本之间的所有模块更改(全部位于一行，我拆分命令以提高可读性)：

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

以>开头的行表示仅存在于新内核的模块。考虑到这个错误，很有可能丢失的模块是一个密码模块，所以您可以添加| grep /crypto/来缩小列表范围。

一旦确定了可能的嫌疑人，就可以通过将它们添加到/etc/initramfs-tools/modules (每行一个)并运行update-initramfs -u -k all来重新生成initramfs，将它们包含在initramfs中。

，它还是不能工作，

这里的方法只涉及上面的情况(A)，因为旧内核中不存在模块，所以缺少一个模块。案件(B)实际上没有一个直接的解决办法。您可以进行合理的猜测，也可以简单地将所有密码模块添加到/etc/initramfs-tools/modules中，并希望得到最好的结果。但是最好确保Ubuntu已在USB上准备就绪，以便使用其救援模式 (第二个项目，页面没有锚)使用正确的内核版本引导系统。