web-dev-qa-db-ja.com

スーパーブロックの最終マウント時間は将来です

昨日、私は紛らわしい問題に遭遇しました。ブート中に、システムはスーパーブロックの最終マウント時刻が未来であると不平を言ったので、fsckを要求しました。私はDebianSqueezeを何ヶ月も使用していて、初めて問題に遭遇しました。 UTCの問題なのかしら。

私はグーグルで検索しましたが、私を導くものは何も見つかりませんでした。

3
Shawn Xie

これは、ハードウェアクロックが停止したとき、またはハードウェアクロックが過去のある時点で誤って設定された(そしてその後ラインに戻された)ときに発生する可能性があります(通常は発生します)。前者は後者よりはるかに一般的です。

マシンのシステムクロックとハードウェアクロックの両方が正確であることを確認し(hwclockを実行)、メンテナンスでマシンを停止し、電源を切り、電源を切り(物理的に主電源から切断)、数回待ちます数分後に、もう一度起動します。 BIOSに移動し、そこで時間を確認します。それでも正しい場合は、ハードウェアクロックの設定が間違っている可能性が高く、二度と発生しない可能性があります。間違っている場合(おそらく1988年1月1日またはその他の「ラウンド」時間に設定されている場合)、CMOSバッテリーが切れているため、BIOSを使用して時間を正しく設定して起動する前に、バッテリーを交換する必要があります。予備のBIOSバッテリーを置いておく(DCツールボックスにはそれぞれ1つのボックスがあります))ことは常に良い考えです。

5
womble

Linux Mint Debian Edition(LMDE)で、上記のCook Schellingの回答を使用して、管理者として/ etc/default/rcSを編集し、「FSCKFIX = no」を「FSCKFIX = yes」に変更しました

再起動すると、問題は修正されました。

これで、BIOSセットアップでクロックを変更すると、システムは「スーパーブロックの最終マウント時刻は将来です」タイプの問題を自動的に修正します。

2
user65258

非常に単純な問題です。そして、それは解像度です。

  • 日付を新しいものに変更します。

    $ date -s "2016年10月2日18:00:00"

  • 自動モードなしでfsckチェックを実行し、問題を修正するために「y」を入力します。この場合、ロックが解除されます。

    $ fsck

  • Ctrl + Dはサーバーを再起動します。これにより、サーバーが正しく起動します。

  • 後でシステム時刻が同期されている場所を確認し、UTC設定などを確認します。

すべての最高の男。

2
Anuj Garg

...そしてif時計が正しく設定されている場合は、fsckを実行するだけです。恐れるな。これはテストディストリビューションです-多分彼らは何かを台無しにしました。 ;)

1
PEra

解決策を見つけました。/etc/default/rcSを編集しました:行を変更しました

UTC=no

UTC=yes

次に再起動して、問題がないことを確認しました。

UTCのデフォルト設定は「はい」で、「いいえ」に変更したことを覚えています。それは私の間違いのようです。しかし、なぜそれがごく最近まで長い間正しく機能していたのでしょうか?

0
Shawn Xie