我正在 2021.12.x Arch Linux 安装中设置暂停到磁盘和恢复。我的问题是关于恢复时安全（不丢失数据）解锁分区。
这是我的配置。引导加载程序是 grub 2.06，我使用的是基于 busybox 的 initramfs。相关分区如下。我没有使用LVM。
# partition encrypted mountpoint decrypted volume name
- --------- --------- ---------- ---------------------
...
3 root luks2 / cryptroot
4 swap luks2 [SWAP] cryptswap
...
我/etc/mkinitcpio.conf已经配置了这些钩子。
HOOKS=(base udev ... openswap openroot ... resume ... filesystems fsck)
我没有使用内置的加密钩。它只能解锁一个设备（通常只能解锁cryptdevice内核参数中指定的根设备），但我也需要解锁加密的交换设备。因此，我使用两个自定义挂钩代替加密挂钩：openswap 和 openroot。 openswap 挂钩本质上是运行：cryptsetup luksOpen <swap device> cryptswap
提示输入密码。 openroot 挂钩对根分区设备执行相同的操作：cryptsetup luksOpen <root device> cryptroot。
接下来，内置的resume钩子将交换设备的主设备号和次设备号写入/sys/power/resume。
printf "$devmajor:$devminor" >/sys/power/resume
此时有两种情况。
情况 1：如果完全关闭后启动
完全关闭后启动计算机时，未锁定的交换分区中没有休眠映像。没有任何可恢复的内容，因此会进行常规引导。此时根分区已解锁（通过 openroot 挂钩），因此引导可以正确进行。
在这种情况下不存在安全问题。
情况 2：如果在挂起到磁盘后启动
早些时候，当我启动挂起到磁盘时，根分区将处于解锁和安装状态，并且休眠映像将按原样捕获此状态。现在，在内核使用此休眠映像恢复后，系统将继续使用此（已）解锁/安装的根分区设备。
这就是我的问题出现的地方：
我知道这样不好mount处于挂起和恢复之间的设备。例如，kernel.org 说：“如果您在挂起和恢复之间触摸磁盘上的任何内容…………就和您的数据吻别吧。”我的配置不执行此操作。
cryptsetup luksOpen对于处于挂起和恢复之间的设备来说，这是否同样糟糕？是否cryptsetup luksOpen构成触摸（上面的 kernel.org 术语）磁盘？回想一下，initramfs openroot 挂钩cryptsetup luksOpen <root device> cryptroot在挂起和恢复之间运行。
如果是这样，该如何处理？
答案1
就其本身而言，它cryptsetup luksOpen是纯粹的只读操作。然而，简单地解锁块设备的行为就会触发诸如 udev 规则之类的依赖关系，这反过来可能会触发自动组装（对于 raid 和 lvm 设备），这反过来会创建更多的块设备，进而触发更多的 udev 规则等。
因此，最好通过按正确的顺序运行钩子来避免整个难题。
如果resume钩子只需要交换分区（即不涉及其他交换设备或交换文件），则应在, beforeresume之后直接运行。openswapopenroot
否则，你的设置也会给人一种错误的安全感，因为要求提供根加密密码，而恢复根本不需要该密码，并且最终会被简历丢弃。
除非您有代码来停止执行，否则对于挂起的系统，resume即使您反复为挂钩输入错误的密码，挂钩也应该成功openroot。因此，这是在更改钩子顺序之前验证该理论的简单方法。