‘清除孤立的inode’和状态在hibernate恢复时丢失

我安装了一个新的16.04 LTS。 我遇到了Wifi applet显示错误（从Suspend恢复后）和hibernate恢复的一些问题。 我使用此处显示的方法在菜单上启用了hibernate模式。 现在hibernate恢复不会间歇性地工作。 有时它工作正常，有时它在简历上显示文字，说明“清除孤立的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 

Answer 1

我只是“修复”了同样的问题，因此即使您的问题不同，也会提供我的解决方案。

我首先遍历了by-uuid问题（因为我删除了systemd，我认为sysvinit可能导致设备顺序混乱，正如其他地方所建议的那样，并且uuid引用应该已经解决了问题。或者我认为。

这似乎是好一周，甚至两个，然后它再次开始。

在此之后，我想起了我对Gentoo的麻烦，我必须在grub.cfg中明确设置resume=/dev/disk/by-uuid/{} ，否则无论如何都不会恢复。 在那里，它解决了我的问题。 我甚至安装了dracut来管理我的initramfs。 它再次工作了一段时间，然后它没有。

然后我尝试了不同的东西，如降级内核，安装bootlogd ，但没有任何建议有什么特别之处。

此时，我开始寻求更多帮助。 我在kernel.org上掌握了所有 – 不太可读 – 的信息。 我试过这个，那个，我不太记得我做了什么，但是嘿。

它有时会起作用，然后它再次没有。

现在，我实际上是偏执狂，寻找内核中的隐藏模块并设想冷启动攻击，确定有人可能得到我的BIOS支持，从hibernate状态恢复，然后重置计算机并从一些外国成像系统转储内存启动。 （请注意，所有这些绝对不是牵强附会，只是 – 事实certificate – 完全不相关。）

在这个任务中 – 今天晚上 – 我设法找到了这个网站： https ： //01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues 。 从这里开始，我将参数2.1 initcall_debug ， 2.3 ignore_loglevel和2.4 dynamic debug添加到我的grub.cfg作为内核启动参数。

然后又发生了。

但现在我更专注。 我注意到我的“孤立的inode”内容是由于“ Superblock上次写入时间是未来的 ”。 我花了几个小时发现当时的情况，大约半年前，再次无济于事。 我只是假设它与缺乏systemd和我使用localtime作为hwclock的习惯有关（由于偶尔使用W7进行双启动），所以它必须在6-10分钟（不精确的时钟源）到2的间隔内最多小时（我在GMT + 1 DST）。

男孩，我错了。

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

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

因此，我终于发现我的CMOS电池被破坏了 。 它可能有点充电 – 即使它不是可充电的 – 当我长时间离开计算机时，它可能已经拾取了足够的电荷以“存活”1-2天 – 或者它可能只是温度， 谁知道。 （这不是我的主要计算机，所以它确实连续几天每隔一周无动力。）

tl;博士 ：

也就是说，我建议换掉你的CMOS电池，或者 – 如果它是笔记本电脑或类似电脑 – 那么

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

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

3. 马上重启。 这非常重要，因此您可以在激活新设置的情况下hibernate。

4. hibernate，让机器关闭相当长的时间，比如至少几小时，然后恢复。

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

对于所有这些步骤，您需要是root用户，因此建议您在每次重新启动后以sudo -s命令开始，并首先安装Midnight Commander（ apt install mc或Software Center）之类的东西并使用它（ mc ）来使用配置和日志。

现在你有一个登录/var/log/boot ，你可以在其中查找启动时的事件，就像“孤立的inode”的实际原因一样。 如果您发现“未来的修改时间”有问题，或者有很多小时或更长时间的差异，那么您肯定也会注意到您的CMOS / RTC电池注定失败，并且需要更换它。

Answer 2

好吧，我很惊讶没有人建议这一点，因为我已经有这个问题很长一段时间了。 看起来的答案就是盯着我的脸。 显然我的交换分区大小与我的内存大致相同。 另外，我没有在我的grub文件中添加指向我的交换分区的UUID的链接。 将交换分区大小增加到内存的两倍并在grub文件中添加其UUID后，hibernate恢复在过去几天正常工作。 虽然，从hibernate状态恢复的时间要长一点，但我并没有抱怨。

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

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

UPDATE

使用低级接口uswsusp作为默认的hibernate机制大大改善了我的恢复时间到一分钟之内！

sudo apt-get install uswsusp

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

• SLEEP_MODULE="uswsusp"