☰

为什么 systemd 等待“fstab”中不存在的磁盘？

tag-icon • tag-icon boot systemd fstab uuid ecryptfs
为什么 systemd 等待“fstab”中不存在的磁盘？

我的系统启动需要 95 秒：实际启动 5 秒，等待不存在的驱动器 90 秒：

(...boot.log...)
A start job is running for dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device (1min 29s / 1min 30s)
Timed out waiting for device dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device.

该设备未在 中列出fstab，我什至没有找到该硬件（USB 磁盘等）。它来自哪里以及如何禁用它？

我的主目录中有 ecryptfs，并且我手动禁用了交换以保存我的 SSD 磁盘。

答案1

用于grep -r 6bbb4ed8 /etc查找对该设备的任何引用并随后重建 initrd ( mkinitrd)。

答案2

该文件是管理加密文件系统/etc/crypttab的（鲜为人知的）对应文件。 fstabUbuntu 默认安装配置了一个加密的交换文件：

cryptswap1 UUID=6bbb4ed8-53ea-4603-b4f7-1205c7d24e19 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

最初我只禁用了这个交换分区fstab，即不是足够的。

欢迎任何更了解其目的和内部运作方式的人/etc/crypttab来扩展我的这个模糊的自我回答。

答案3

就我而言，戴尔 Latitude 笔记本电脑配有启动 SSD 和数据 HDD；后者产生了坏扇区，所以我最终备份了数据并物理移除了 HDD，在下次启动时遇到了丢失 HDD 的 90 英寸超时。

grep -r /etc根据 Hauke 的建议，找到了systemd 正在寻找的/etc/crypttabHDD UUID (per ) 对应的条目。/dev/disk/by-uuid

然后我记得几年前添加了这一行，以允许为两个磁盘输入一个 LUKS 密码，将 HDD 解密指向根文件系统上的密钥文件（在启动时通过我输入其 LUKS 密码来解密 - 看看crypttab(5)你是否是对多磁盘单 LUKS 密码设置感兴趣）。

评论该/etc/crypttab行恢复了 SSD 的快速启动速度（谢谢！）。

相关内容