所以我搞砸了，echo disk > /sys/power/state而不是echo mem > /sys/power/state意外地被处决了。然后我意识到我刚刚做了什么。
有关设置的一些详细信息：
- 它在根分区上使用 LUKS 加密
- EFI 存根引导加载程序（我可以使用 efibootmgr 条目设置内核参数）
- Swapfile 位于 LUKS 分区上的 Btrfs 文件系统上
- 其中我没有交换文件偏移......我希望我没有被搞砸。
我的自定义 initramfs init 脚本尚未实现恢复。因此，我需要进入可启动 USB 并以某种方式提取内核存档（initramfs 嵌入在内核中）并对 init 文件进行更改，然后再次压缩它。如果这对于内核可执行文件来说是可能的话。我可能无法再次重新编译内核，除非我花费大量时间获取内核源代码并为我的 gentoo 环境重新编译它。但我也许可以作为最后的手段。那么，1. 如何使用更新的 init 文件编辑 vmlinuz（内核存档）？
LUKS 分区解锁后，如何访问此交换文件？我没有交换文件的偏移量。我现在不知道 Linus 是否会知道我的交换文件在哪里。它像“echo /dev/mapper/myrootfs > /sys/power/state”那么简单吗？最初的休眠似乎进展顺利，因此 Linux 似乎很容易找到我的交换文件在哪里。也许恢复也是一样？所以，2.我应该如何处理交换文件，我不知道它的偏移量。将安装为只读工作然后将交换文件指定为 /sys/power/state 工作还是会破坏我的文件系统？ （因为文件系统在技术上“仍然安装”）。也许像前面所说的那样将 /dev/mapper/myrootfs 回显到 /sys/power/state ，但指定偏移量的目的是让 Linux 知道交换文件在哪里。我没有。
编辑：我没有任何重要的东西，比如未保存的文档或任何东西（我打开的只是 X、我的 WM 和终端窗口）。如果我可以正常启动（在恢复的状态下），然后丢弃该休眠副本（就像我说的，我没有未保存的文档或类似的东西），那就没问题了。那可能吗？或者我的文件系统现在处于不安全状态并且安装它只会破坏它？
答案1
如果您不关心挂起的会话，则启动是安全的
如果您启动并且不恢复挂起的会话，您的文件系统不会受到损害。恢复会话所需的所有数据仅保存到交换文件中。保存会话后，您的计算机将正常关闭，因此文件系统不会“仍然安装”。
我有类似的设置（使用 systemd）。我重现了您的场景，看看会发生什么：
- 将我的系统挂起到磁盘
resume=<device> resume_offset=999999从引导加载程序中的内核命令行中删除
系统正常启动（未执行恢复）。我的文件系统很健康，交换空间是空的。
恢复暂停的系统
如果要修复休眠状态的恢复，我会执行以下操作
- 引导至某些安装介质
- 解锁并挂载系统分区（以及包含交换文件的分区）
- 找到交换文件的偏移量（参见这篇 ArchWiki 文章对于 Btrfs）
- 修改引导加载程序的条目以指定恢复设备和偏移量
- 重启系统正常
注意如果您在暂停后修改了文件系统，则恢复是不安全的。
使用自定义 init 脚本时，您需要修改 initramfs 中的脚本。最简单的方法是修改脚本并从某些安装介质重新创建它。
在你的脚本中你需要做类似的事情
echo 99999 > /sys/power/resume_offset
echo /dev/mapper/myrootfs > /sys/power/resume
从安装介质修改并重新生成 initramfs
看一眼systemd 做什么