![无效行 /etc/crypttab](https://linux22.com/image/151698/%E6%97%A0%E6%95%88%E8%A1%8C%20%2Fetc%2Fcrypttab.png)
我正在对无法启动的 Debian 系统进行故障排除;系统启动正常,有一天停止了(可能但不肯定与 相关apt upgrade
)。它有一个小的启动分区 (sda1),sda2 上有一个 LUKS 容器。 LUKS 容器内部是一个 LVM 层,其中有两个格式为 ext4 的成员(/
和/home
)。
启动时,cryptsetup 甚至不运行,并显示以下错误:“警告:无法连接到 lvmetad。回退到内部扫描。”然后计算机会转到 initramfs 控制台。
在另一台计算机上安装并 chroot 受影响的磁盘时,我发现在尝试更新 initramfs 时 /etc/cryptsetup 无效,尽管看起来很好。错误是:“cryptsetup:警告:/etc/crypttab 中 sd1 的行无效 -”
我的 crypttab 文件仅包含以下内容:
crypt UUID=<uuid> none luks
blkid
或者lsblk
确认已选择了适当的 UUID(/sda2 的 UUID,其子项是名为 的 LUKS 容器crypt
)。
部分版本信息:
debian: 9.8
kernel: 4.9.0.6-amd64
cryptsetup: 1.7.3
lvm: 2.02.168(2)
请注意,这sd1
是另一个 LUKS 设备,即已安装故障驱动器以进行故障排除的计算机的设备。也许在这种情况下,可以忽略该警告?即便如此,update-initramfs
当故障驱动器用作引导设备后,问题(加密被绕过)仍然存在。
此时,由于我不太确定问题是什么,所以我正在考虑重新安装 grub 并重新安装内核。不过,我希望得到有关替代步骤的建议。非常感谢。
答案1
尝试运行时出现的有关无效 crypttab 的错误update-initramfs
仅仅是因为主机也有 LUKS 容器。解决方案是在没有任何其他 LUKS 设备的系统中执行完全相同的步骤(我使用“实时”可启动 .iso 映像来执行该任务)。启动 .iso 后,update-initramfs -u -k all
工作顺利,系统恢复了可启动性。也许有一个选项可以指示 cryptsetup 忽略恰好存在于用作救援系统的计算机上的不相关 LUKS 设备。