我有以下设置:
- artix linux 操作系统
- Linux 强化内核“6.1.24-hardened1-1-hardened”
- 加密根分区(无 lvm)
- 未加密的启动分区(已安装 GRUB)
- 设备是 USB 记忆棒
- 没有 EFI 分区、模块、挂钩等。
- mkinitcpio.conf HOOK 顺序:基本 udev 自动检测 modconf kms 阻止 lvm2 加密键盘键盘映射控制台字体恢复文件系统 fsck
我有两台机器,从此 USB 启动时它们的行为不同。机器 1 正常启动,没有问题。机器 2 正常启动,直到加载 initramfs。当它到达钩子时,encrypt
它无法通过 UUID 找到加密的根分区,并在 10 秒后放弃尝试解密。这使我进入救援 shell。在此 shell 中,运行blkid
不会产生有关 USB 或其分区的任何信息,包括它刚刚从中启动的启动分区。但是,它确实提供了机器 2 的内部 HDD 的 UUID 和设备映射。
我猜测这可能与 UEFI 启动有关,所以我进入 BIOS 设置并确保它已设置为传统启动。我在 BIOS 启动菜单中确认没有 UEFI 启动到 USB 的选项。
我决定看看 GRUB 本身在识别根分区方面是否存在问题。我按下c
进入 GRUB 命令行,ls
然后输入了 USB 的根分区和启动分区,以及内部 HDD 分区。
尽管在 grub 配置中将日志级别设置为 999,但除了无法找到根分区之外,似乎没有任何警告或错误。所有上述行为都是一致可重现的,并且对机器 1 正常启动 USB 的能力没有影响。
答案1
执行以下步骤后,机器 2 能够成功启动到 USB:
autodetect
从中删除HOOKS
/etc/mkinitcpio.conf
- 跑步
mkinitcpio -p linux-hardened
- 跑步
update-grub
在阅读 arch mkinitcpio 页面后,我想到了这个想法:https://wiki.archlinux.org/title/mkinitcpio#Build_hooks。该页面autodetect
自始至终都提到了钩子的几个怪癖,包括在谈论“备用 ramdisk 映像”时“在创建过程中跳过自动检测钩子,因此包括支持大多数系统的全系列模块”。我不认为它会起作用,但我决定重建映像,autodetect
现在机器 2 和 1 都能够启动到 USB。为了确保这不仅仅是一个侥幸,我autodetect
像以前一样重建了启用的映像,再次只有机器 2 无法正确启动到 USB。我autodetect
再次禁用它,它再次正常工作。
我不完全确定为什么这可以解决问题。我猜@DanielB 关于可能缺少驱动程序的说法是正确的,这也许autodetect
会阻止使用必要的驱动程序构建映像,从而无法与机器 2 正确交互。