☰

如何避免“手动运行 fsck”消息，同时允许尝试系统时间更改？

tag-icon • tag-icon boot rhel date fsck
如何避免“手动运行 fsck”消息，同时允许尝试系统时间更改？

我正在使用一个系统，我们希望允许用户根据需要随意设置日期和时间，并且可以任意重新启动。这很好，除了一件事：如果有很大的时间向后跳跃，重新启动时会出现以下错误：

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

…然后启动挂起，等待用户控制台输入，即使获得控制台访问权限，也需要 root 密码才能继续。

这显然不太理想。有没有办法跳过检查或强制检查在重新启动时自动进行？

谷歌只提供了需要手动运行 fsck 的帮助，如果/当这个被击中时，这不是我所追求的。设置时间后手动运行 fsck 不起作用，因为此时文件系统仍处于挂载状态，并且仅完全禁用 fsck 不太理想。

我使用的是红帽6。

更新：我目前正在使用的解决方案是破解 fstab 以禁用重新启动时的 fsck 检查。我尝试使用 编辑磁盘上的最后安装时间debugfs，这对于 ext3 驱动器工作正常，但在 ext4 上似乎不一致地失败。

答案1

我打算建议黑客e2fsck禁用对未来最后安装时间或最后写入时间的特定检查。这些定义在问题.c/问题.h，并用于超级c。但在查看时，我发现 E2fsprogs 1.41.10 添加了一个新选项，/etc/e2fsck.conf称为损坏的系统时钟。这似乎正是您所需要的，并且由于您使用的是 Red Hat Enterprise Linux 6，因此您应该拥有 1.41.12，其中包含此选项。从手册页：

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

是的，手册页不能拼写“heuristics”。哎呀。但想必代码无论如何都能工作。 :)

答案2

我怀疑是否有一种方法可以专门删除此检查，而无需修改源代码。忽略 fsck 中的所有错误听起来很危险，如果还有其他问题怎么办？

因此，我建议采用以下解决方法：在运行 fsck 之前更改启动脚本以将系统日期设置为将来的某个时间（例如 32 位计算机上的 2038-01-18），然后从硬件中读回它之后设置时钟（hwclock --hctosys，根据需要提供更多选项，具体取决于您的硬件以及硬件时钟中 GMT 的使用。）

答案3

这听起来像是应该在虚拟机中运行，您可以在其中拥有更多控制权（或者只是恢复到快照）。

答案4

这是一个对我来说非常有效的解决方案：

创建/etc/e2fsck.conf：

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

有关此修复的更多信息，请参见此处：

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

相关内容