システム時刻の変更を試行しながら、「手動でfsckを実行」メッセージを回避するにはどうすればよいですか？

18

私は、ユーザーが必要に応じて日付と時刻を操作できるようにし、再起動が勝手に行われる可能性のあるシステムを使用しています。これは1つのことを除いて問題ありません。逆方向に大きな時間ジャンプがある場合、再起動時に次のエラーが表示されます。

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.

…その後、ブートはユーザーコンソールの入力を待ってハングし、コンソールアクセスが取得されても、続行するにはルートパスワードが必要です。

これは明らかに理想的とは言えません。チェックをスキップする方法、または再起動時にチェックを自動的に実行する方法はありますか？

Googleは、これがヒットした場合、またはヒットしたときにfsckを手動で実行する必要があるヘルプのみを提供していますが、これは私が望んでいることではありません。時刻を設定した後に手動でfsckを実行しても、その時点でファイルシステムがマウントされているため機能せず、fsckを完全に無効にすることは理想的ではありません。

RedHat 6を使用しています。

更新：私が現在行っている解決策は、fstabをハックして再起動時のfsckチェックを無効にすることです。を使用してディスクの最後のマウント時間を編集しようとしましたがdebugfs、これはext3ドライブでは正常に動作しますが、ext4では一貫して失敗するようです。

— 私と
ソース

15

e2fsck将来の最後のマウント時間または最後の書き込み時間の特定のチェックを無効にするハッキングを提案するつもりでした。これらは、で定義されているproblem.c / problem.h、およびで使用super.c。しかし、見ている中で、私がするE2fsprogs 1.41.10がに新しいオプション追加することを発見/etc/e2fsck.conf呼ばbroken_system_clockを。これはまさに必要なもののようで、Red Hat Enterprise Linux 6を使用しているため、このオプションを含む1.41.12が必要です。manページから：

   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.

はい、マニュアルページに「ヒューリスティック」と綴ることはできません。おっとっと。しかし、おそらくコードはとにかく動作します。:)

— mattdm
ソース

それは素晴らしいように見えますが、manページはext2とext3のみに影響することを暗示しており、ext3とext4の組み合わせを使用しています。それでも、私は今それを試してみます、それがうまくいくかのように、まさに私が探しているものです。

— me_and

1

できます！ext4を含む。ありがとうございました！

— -me_and

1

ソースコードを変更する以外に、このチェックを具体的に削除する方法があるとは思わない。fsckからのすべてのエラーを無視することは危険に思えますが、他の問題が発生した場合はどうなりますか？

したがって、次の回避策をお勧めします：fsckを実行する直前に、ブートスクリプトを変更してシステムの日付を将来（32ビットマシンでは2038-01-18など）に設定し、ハードウェアから読み戻すその後のクロック（hwclock --hctosys、ハードウェアとハードウェアクロックでのGMTの使用に応じて、必要に応じてオプションを追加します。）

— ジル「SO-悪であるのをやめる」
ソース

これは、次回同じバグに再び遭遇する可能性のあるウィンドウがあるという意味ではないでしょうか？すなわち、最後のマウント時間は2038-01-18であるため、現在の時間もそれに設定されている場合、最後のマウントの前に再びマウントしようとする（システムに関する限り）競合状態があります。

— me_and

@me_and：はい、悪意のあるユーザーに対して私の手がかりが役に立たないのではないかと心配しています。それがあなたが直面しているものである場合、fsckにパッチを当てることが最良の選択肢のようです。

— ジル 'SO-悪であるのをやめる'

0

これは、仮想マシンで実行する必要があるように思えます。仮想マシンでは、より多くの制御（または単にスナップショットに戻す）を行うことができます。

— ジェメスポ
ソース

VMで実行することは実際には選択肢ではありません。いずれの場合も、スナップショットに戻すことは、ユーザーが設定した他の状態をすべて削除することを意味します。

— me_and

0

ここに私にとってうまくいった解決策があります：

/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

— GoinOff
ソース