尽管这个问题涉及嵌入式主板，但在我看来，serverfault 是最适合发帖的 stackexchange 论坛。几个月来，我和我的同事一直在研究这个奇怪的 Linux 启动问题，但我们有点不知所措。任何建议都值得赞赏。
我们有一块 Portwell 主板（单核 Atom 超线程），运行 Centos 6.4。一位客户向我们反映一个非常奇怪的启动问题，我们终于能够重现这个问题。
如果你这样做，一切都会正常：
- 正常开机
- 停止系统
- 暂时拔掉系统电源
- 插入电源
- 启动
但是，如果您执行以下操作，作为启动正常部分运行的常规 fsck 将会出现错误：
- 正常开机
- 正常关机
- 请勿断开电源
- 等待 8 到 12 小时（更短的时间似乎不会造成问题）
- 再次开机
我们得到的错误如下图所示：
我们可以按 ctrl-D 并重新启动任意多次，错误仍会不断出现。但请注意，文件系统没有任何问题。
我们可以通过这种方式消除错误：
- 关闭
- 断电至少 10 分钟（时间太短，问题仍不会消失）
- 重新插入电源并启动。
截至昨天，我们的假设是硬盘可能已减速但并未关闭，并且随着时间的推移，磁盘缓存可能会降级。然而，事实证明这是错误的，因为以下步骤也可以解决问题：
- 让系统启动并显示错误
- 不要断开电源
- 进入 BIOS 并将系统日期更改为未来的某个时间
- 启动进入 Linux。
这块主板没有电池，所以当我们第一次开机时，它总是显示错误的日期，大约是 2010 年 1 月的某个时间。所以在通常情况下，日期是错误的，但操作系统正常启动。当操作系统启动时，NTP 会正确设置日期。如果我们将其插入但关闭 12 小时，日期会再次重置，但出于某种原因，fsck现在关心日期，并希望进行手动 fsck，因为它认为这种差异是一个主要问题。如果我们手动将日期更改为未来日期，它就会正常启动。如果我们将其改回过去日期，它会再次出错。但如果我们断开电源足够长的时间并启动，尽管日期错误，我们也不会收到任何错误。
有人能帮我们推理出 fsck 可能正在查看的各种事物吗？有时是否会因日期错误而出错，但如果系统日期是将来的日期则永远不会出错？
如果我们可以将 BIOS 编程为默认的遥远的未来某个日期，那么可能会解决这个问题，但重要的是要了解为什么会发生这种情况，因为我们不想只是贴上创可贴并希望如此。
谢谢您的任何建议。
答案1
显然，由于系统时钟“坏了”，我们必须broken_system_clock = true放入[options]部分/etc/e2fsck.conf。