☰

/etc/crypttab 未在 initramfs 中更新

tag-icon • tag-icon ubuntu luks zfs initramfs crypttab
/etc/crypttab 未在 initramfs 中更新

我新安装了 ubuntu 22.04，并从 ubuntu 安装程序选项中选择了全磁盘加密 (LUKS) 和 ZFS。

我需要进行一些编辑，/etc/crypttab以便以自动方式解锁我的驱动器（花式 USB 自动解锁），但我所做的编辑/etc/crypttab不会保留到 initramfs 中。

我正在做的是：

  • 编辑/etc/crypttab
  • 跑步update-initramfs -u
  • 重新启动我的机器进入要求输入 LUKS 密码的系统 (initramfs)
  • 检查内容，/etc/但不存在 cryptotab。

我对它的工作原理的理解是否错误？我需要将某些版本的 crypttab 保留到加载程序，但它不起作用。

有任何指示我做错了什么吗？

答案1

我来这里是因为我遇到了同样的问题，通过谷歌找到了这个问题，并且有一些信息要添加。我正在尝试在不输入密码的情况下自动解锁 LUKS 驱动器。

首先，我将/etc/crypttab其条目编辑并更改为以下内容：

sda3_crypt UUID=2d661ff8-d6a8-49c9-ae96-4d6e234bffe2 /dev/zero luks,discard,keyfile-size=32

然后，我使用以下命令添加了一个新密钥：

sudo cryptsetup luksAddKey --new-keyfile-size 32 /dev/sda3 /dev/zero

最后，我运行update-initramfs了以下输出：

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.0.0-2-amd64
cryptsetup: WARNING: sda3_crypt: key file /dev/zero has insecure ownership, see 
    /usr/share/doc/cryptsetup/README.Debian.gz.
cryptsetup: WARNING: Skipping root target sda3_crypt: uses a key file

这看起来已经很可疑了，但我还是重新启动了。不幸的是，这些操作导致系统无法启动：

Gave up waiting for suspend/resume device
Gave up waiting for root file system device: Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/legend--vg-root does not exist. Dropping to a shell!


BusyBox v1.35.0 (Debian 1: 1.135.0-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /etc/crypttab
cat: can't open '/etc/crypttab': No such file or directory

通过在 BusyBox 提示符下输入以下命令，我能够再次成功启动系统：

cryptsetup luksOpen --key-file /dev/zero --keyfile-size 32 /dev/sda3 sda3_crypt
exit

但最初的问题仍然存在：为什么/etc/crypttabinitramfs 中不可用？

更新

经过更多研究，我现在终于可以回答最初的问题：/etc/crypttabinitramfs 中不存在，因为默认解锁脚本不使用该位置；它使用/cryptroot/crypttab相反。

要像 initramfs 中/etc/crypttab一样可用/cryptroot/crypttab，请在目录中创建以下脚本/etc/initramfs-tools/hooks并使其可执行：

#!/bin/sh
cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
exit 0

最后，请注意，使用空密码来自动解锁 LUKS 设备违背了加密的目的。它与根本不使用加密一样不安全。

答案2

不是跑步sudo update-initramfs -u，而是跑步sudo update-initramfs -c -k -all

添加新的 nvme 驱动器并加密后，我遇到了这个问题。

答案3

我遇到了类似的问题，这个讨论帮助我解决了这个问题，但不需要添加钩子，如上所述。

我的加密分区位于 sda3 上，但因为我使用不同的分区方案从先前的配置复制了数据，所以我的 /etc/crypttab 看起来像这样：

sda6_crypt UUID={uuid] 无 luks，丢弃

看来，当生成 initramfs 映像时（安装新内核时以及其他更新时也是如此）， /etc/crypttab 中的命名与实际分区之间的不匹配会导致错误（当然我没有这样做）请参阅），这样 initramfs 中的文件（位于 /cryptroot/crypttab）为空（零字节）。缺少文件是导致引导过程挂起的原因。将 /etc/crypttab 更正为：

sda3_crypt UUID={uuid} 无 luks，丢弃

解决了问题。当然，如果您的 initramfs 已经鸣响，则需要重新生成：

sudo update-initramfs -u

但未来的更新应该正常进行。

答案4

对我来说（因为我以前被烧伤过）我做了双重检查。 （这是 ubuntu 20.04，但答案也与 22.04 相关）

在update-initramfs -c -k all我做了mkdir /tmp/x; cd /tmp/x; unmkinitramfs -v /boot/initrd.img-$(uname -r) .并检查之后/tmp/x/main/cryptroot/crypttab。里面是空的。

我的解决方案是编辑/etc/cryptsetup-initramfs/conf-hook和创建密钥文件模式。我的最终配置是： KEYFILE_PATTERN=/etc/cryptsetup-keys.d/*.key在conf-hook和myroot UUID="8481c1f8-91d4-469d-9132-12d3948f503a" /etc/cryptsetup-keys.d/root.key luks,discard/etc/crypttab中。钥匙，没有行尾换行符当然是在/etc/cryptsetuyp-keys.d/root.key

这样做之后，解压 initramfs，我看到一个main/cryptroot/crypttab看起来正常的文件，并且密钥文件（具有新文件名）被复制到main/cryptroot/keyfiles/myroot.key（“myroot”与 initramfs 的 crypttab 中的任何内容匹配）。

相关内容