☰

“清除孤立的 inode”和休眠恢复时丢失的状态

tag-icon • tag-icon 16.04 suspend power-management hibernate
“清除孤立的 inode”和休眠恢复时丢失的状态

我安装了全新的 16.04 LTS。我遇到了 Wifi 小程序显示错误（从挂起状态恢复后）和休眠恢复的问题。我使用所示方法在菜单上启用了休眠这里。现在休眠恢复间歇性地无法工作。有时它可以正常工作，有时它会在恢复时显示有关“清除孤立 inode”的文本，并且系统只是重新启动，没有之前的内存状态。

以下是一些信息：

$ sudo blkid
/dev/sda1: LABEL="System Reserved" UUID="50921EE4921ECE7A" TYPE="ntfs" PARTUUID="dda192f8-01"
/dev/sda2: LABEL="Primary Disk" UUID="765E305F5E3019F7" TYPE="ntfs" PARTUUID="dda192f8-02"
/dev/sda3: LABEL="Secondary Disk" UUID="E2D42C6AD42C42E1" TYPE="ntfs" PARTUUID="dda192f8-03"
/dev/sda5: UUID="dbaad068-46da-4637-9c45-5c32c20d3cfe" TYPE="swsuspend" PARTUUID="dda192f8-05"
/dev/sda6: UUID="31385b29-f351-4a10-9dcf-c92efd58334b" TYPE="swap" PARTUUID="dda192f8-06"
/dev/sda7: UUID="1f734f56-7328-4029-88a0-fa995426d4d2" TYPE="ext4" PARTUUID="dda192f8-07"

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=31385b29-f351-4a10-9dcf-c92efd58334b

答案1

好吧，我很惊讶没有人提出这个建议，因为我已经遇到这个问题很长时间了。答案似乎就在我眼前。显然我的交换分区与我的内存大小大致相同。另外，我没有在 grub 文件中添加交换分区 UUID 的链接。将交换分区大小增加到内存的两倍并在 grub 文件中添加其 UUID 后，休眠恢复在过去几天里一直正常工作。虽然从休眠状态恢复需要更长的时间，但我没有抱怨。

您需要确保您的交换分区在以下文件中定义：

  • /etc/initramfs-tools/conf.d/resume
  • /etc/default/grub

更新

使用低级接口uswsusp作为默认休眠机制大大缩短了我的恢复时间至一分钟以内！！！

sudo apt-get install uswsusp

创建文件/etc/pm/config.d/00sleep_module并添加以下行：

  • SLEEP_MODULE="uswsusp"

答案2

我只是“修复”了完全相同的问题，因此将在此提供我的解决方案，即使您的问题不同。

我首先迭代了by-uuid问题（当我删除了 systemd 时，我认为 sysvinit 可能会导致设备顺序混乱，正如其他地方所建议的那样，而 uuid 引用应该可以解决问题。或者我是这样认为的。

一周甚至两周后它似乎都好了，然后它又开始了。

之后，我想起了我在 Gentoo 上遇到的问题，当时我必须在 grub.cfg 中明确设置resume=/dev/disk/by-uuid/{}，否则无论如何它都无法恢复。在那里，它解决了我的问题。我甚至安装了 dracut 来管理我的 initramfs。它又工作了一段时间，然后就不行了。

然后我尝试了不同的方法，如降级内核、安装bootlogd，但没有任何特殊迹象。

此时，我开始寻求更多帮助。我掌握了所有（不太容易理解的）信息在 kernel.org。我尝试了这个，那个，我记不清我到底做了什么，但是嘿。

有时候它会再次起作用，但有时候它又不起作用。

现在我才真正开始疑神疑鬼，寻找内核中的隐藏模块，设想冷启动攻击，认为有人可能拿到了我的 BIOS 密码，从休眠状态恢复，然后重置计算机，并从某个外部映像系统启动时转储内存。（请注意，这一切绝对不是牵强附会的，只是——事实证明——完全不相关。）

在今天晚上的这次探索中，我设法找到了这个网站： https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues。从这里，我添加了参数2.1 initcall_debug，2.3 ignore_loglevel， 和2.4 动态调试作为内核启动参数。

然后，同样的事情又发生了。

但现在我更加细心了。我注意到我的“孤立 inode”内容是由于“超级块上次写入时间是未来“。我花了几个小时才弄清楚问题出在哪里，大约半年前，同样无济于事。我只是假设它与缺少 systemd 和我使用本地时间作为硬件时钟的习惯有关（由于偶尔与 W7 双启动），所以它必须在 6-10 分钟（不精确的时钟源）到最多 2 小时的间隔内（我在 GMT+1 DST）。

天哪，我错了。

碰巧的是，现在添加了 ignore_loglevel 内核参数后，启动日志包含了启动时我的时钟的准确日期以及修改时间。

我的时钟实际上设置为 2013 年 6 月 6 日，这大概是 BIOS 发布日期，或类似的日期。这是三年的差异（根据 ntpdate 为 97010350.488716 秒）。

因此，我终于明白了我的 CMOS 电池坏了。它可能有点充电了 - 即使它不是可充电的 - 并且当我长时间开着电脑时，它可能已经积累了足够的电量来“存活” 1-2 天 - 或者可能只是温度，谁知道呢。（这不是我的主要电脑，所以每隔一周它确实会连续几天没有电。）

总结：

话虽如此，我还是建议更换你的 CMOS 电池，或者——如果你是笔记本电脑或类似设备——那么

  1. （可选，如果您使用 Xenial 16.04 的默认安装，则不需要此项）安装并配置 bootlogd，这样您就可以在 /var/log/boot 中找到您的启动日志。（使用 systemd，您只需运行journalctl -b即可获取启动日志。）

  2. 编辑您的文件，并在第一行以 开头的行末尾/boot/grub/grub.cfg添加以开头的第一行下方的。initcall_debug ignore_loglevellinux /boot/vmlinuz...menuentry

  3. 马上重启。这非常重要，这样您就可以在休眠状态下激活新的设置。

  4. 休眠，让机器关闭相当长一段时间，比如至少几个小时，然后恢复。

  5. journalctl -b > /var/log/boot最后，如果您不记得删除了名为 的东西systemd和/或安装了名为 的东西upstart，请运行openrc、 或sysvinit。

对于所有这些步骤，您需要以 root 身份运行，因此建议您每次重启后都使用一个命令启动，首先sudo -s安装类似 Midnight Commander（或软件中心）的程序，然后使用它（ ）处理配置和日志。apt install mcmc

现在您有一个登录名/var/log/boot，您可以在其中查找启动时发生的事件，例如“孤立 inode”的实际原因。如果您发现“将来的修改时间”有问题，相差几个小时或更长时间，那么您的 CMOS/RTC 电池肯定也坏了，需要更换它。

相关内容