昨日、私は紛らわしい問題に遭遇しました。ブート中に、システムはスーパーブロックの最終マウント時刻が未来であると不平を言ったので、fsckを要求しました。私はDebianSqueezeを何ヶ月も使用していて、初めて問題に遭遇しました。 UTCの問題なのかしら。
私はグーグルで検索しましたが、私を導くものは何も見つかりませんでした。
これは、ハードウェアクロックが停止したとき、またはハードウェアクロックが過去のある時点で誤って設定された(そしてその後ラインに戻された)ときに発生する可能性があります(通常は発生します)。前者は後者よりはるかに一般的です。
マシンのシステムクロックとハードウェアクロックの両方が正確であることを確認し(hwclock
を実行)、メンテナンスでマシンを停止し、電源を切り、電源を切り(物理的に主電源から切断)、数回待ちます数分後に、もう一度起動します。 BIOSに移動し、そこで時間を確認します。それでも正しい場合は、ハードウェアクロックの設定が間違っている可能性が高く、二度と発生しない可能性があります。間違っている場合(おそらく1988年1月1日またはその他の「ラウンド」時間に設定されている場合)、CMOSバッテリーが切れているため、BIOSを使用して時間を正しく設定して起動する前に、バッテリーを交換する必要があります。予備のBIOSバッテリーを置いておく(DCツールボックスにはそれぞれ1つのボックスがあります))ことは常に良い考えです。
Linux Mint Debian Edition(LMDE)で、上記のCook Schellingの回答を使用して、管理者として/ etc/default/rcSを編集し、「FSCKFIX = no」を「FSCKFIX = yes」に変更しました
再起動すると、問題は修正されました。
これで、BIOSセットアップでクロックを変更すると、システムは「スーパーブロックの最終マウント時刻は将来です」タイプの問題を自動的に修正します。
非常に単純な問題です。そして、それは解像度です。
日付を新しいものに変更します。
$ date -s "2016年10月2日18:00:00"
自動モードなしでfsckチェックを実行し、問題を修正するために「y」を入力します。この場合、ロックが解除されます。
$ fsck
Ctrl + Dはサーバーを再起動します。これにより、サーバーが正しく起動します。
後でシステム時刻が同期されている場所を確認し、UTC設定などを確認します。
すべての最高の男。
...そしてif時計が正しく設定されている場合は、fsck
を実行するだけです。恐れるな。これはテストディストリビューションです-多分彼らは何かを台無しにしました。 ;)
解決策を見つけました。/etc/default/rcSを編集しました:行を変更しました
UTC=no
に
UTC=yes
次に再起動して、問題がないことを確認しました。
UTCのデフォルト設定は「はい」で、「いいえ」に変更したことを覚えています。それは私の間違いのようです。しかし、なぜそれがごく最近まで長い間正しく機能していたのでしょうか?