ubuntu10.04サーバーでの起動時にfsckをスキップします
私たちはここで、再起動中に長いチェックディスクを実行することを主張するubuntu10.04サーバーの前に座っています。
チェックをスキップするためにgrubのカーネルブートオプション行を編集する1つのオプションが表示されます。
--skip-fsckのようなparmaterは何でしょうか？
私もグーグルとドキュメントを試していますが、今のところ見つかりませんでした。まだ探している...
編集：
Matの助けを借りて（chkdskではなくfsckをグーグルで検索）、パラメータを見つけました。おそらく「fastboot」であり、起動中にgrubを編集しようとしましたが、それでも正しい方法が見つかりませんでした。必要ですか-前に？どの行？
EDIT2：
Ubuntu 10.04のブートプロセスは、従来のLinuxの場合とは異なり、ブートプロセスを「高速化」するためにいくつかの変更が加えられています。明らかに、これにより、fsckはctrl-cで中止できるフォアグラウンドプロセスではなくなったという事実が生じます。 「C」を押すと記載されていますが、これは機能せず、反応もありません。
EDIT3：
これはUbuntu10.04サーバーです。私はこれを見つけました：
https：//wiki.ubuntu.com/LucidLynx/ReleaseNotes#Ubuntuサーバーでの起動時出力の変更
引用：「Ubuntuサーバーでの起動時出力の変更
Plymouthの導入により、起動スクリプトからの起動時メッセージがtty1のログインプロンプトの上に表示されなくなりました。代わりに、それらはすべてtty7に出力され、Ubuntuサーバーでは、Alt + F7を押すことで起動後に表示できます。すべてのシステムで、ブート出力は/var/log/boot.logにもあります。
[...] mountallと対話するためのホットキーは、スプラッシュスクリーンがなくても機能しますが、検出できません。実行中のfsckをキャンセルするにはC。 Mはメンテナンスシェルを要求します。使用できないマウントをスキップするS。およびFは、fsckによって検出されたエラーの修正を試みます。」
C、C、m、M、およびCtrl-Cを試しましたが、結果はありませんでした。 Alt-F7はAlt-F1とは異なるブートログに私を送りますが、どちらも反応せず、まだfsck-ingです。
絶対にバックグラウンドでチェックしているような気がします。 （upstart？）そのプロセスの制御を取得できません。フォアグラウンドでは、ブートプロセスは他のディスク（クリーンなディスク）に対して続行されましたが、その後停止しましたが、ctrl-cは受け入れられませんでした。また、利用可能なログコンソールはなく（alt-f2、...）、ブートログのみです。
EDIT4：多分これは関連情報です：
fstabオプション/ etc/fstabはシステム構成ファイルであり、マウントするパーティション（ファイルシステム）とファイルシステムツリーの場所をLinuxカーネルに指示するために使用されます。
典型的なfstabエントリは次のようになります。
/dev/hda1 / ext3 defaults 1 1
/dev/hdb1 /home ext3 defaults 1 2
The 6th column (in bold) is a fsck options.
0 = Do not check.
1 = First file system (partition) to check;
/ (root partition) should be set to 1.
2 = ALL OTHER file systems to be checked.
しかし、それはディスクのチェックをやめるのは悪い考えです。これが私の心です。
「checkdisk」がfsckを意味すると仮定すると、カーネルはこれに責任を負いません。ユーザースペースで処理されます。
最近の実験から、CTRL-Cを使用してfsckを早期に中断し、ブートプロセスを完了するのが安全であることがわかりました。次に、ntranceが言ったように、fstabのオプションを編集するか、tune2fsを使用してファイルシステムを再調整し（ext [234] FSであると想定）、より多くの時間を確保できます（-i）以上のマウント（-c）必須のfscksの間に必要です。
まず、TTY7またはTTY1でCを押してみましたか？また、手動fsckにMを試しましたか？これらはブートスプラッシュプロセッサ、プリマスのホットキーであり、mountall自体のホットキーではなく、プリマスの「ウォッチキーストローク」機能を介して実装されていると思います。
ただし、ext3またはext4で実際に長いfsckが発生している場合は、ドライブがダーティとしてマークされている可能性があります。これは、何度も再起動され、fsck間の最大マウント数に達したか、非常に長い時間で「最後のfsckからの最大時間」に達したことが原因である可能性があります。基本的に、FSが通常設定されている方法では、がらくたをクリーンアップするために時々完全なfsckを実行する必要があります。
別のオプションは、実際にボリュームにひどい問題が見つかったことです。これらはすべて、tty7の出力のどこかに報告する必要があります。
この場合、ボリュームが完全にfsckされると、プロセスを中断しても、システムはボリュームがダーティとしてマークされているため、ボリュームをマウントしません。これを回避するためのハックがありますが、ほとんどの場合、それが完了するのを待つ方が良いでしょう。 TTY7（alt-f7）で何らかの進歩が見られるはずです。
GRUBのブートオプションの「カーネル」部分を編集し、「ro」を「rw」に変更します。これにより、ルートファイルシステムがマウント読み取り/書き込みになります。 Fsckは読み取り/書き込みファイルシステムをチェックするのが好きではなく、スキップされます。
RHELおよびCentOSの場合、「fastboot」が正しいブートオプションです。
警告：/ etc/default/rcSにFSCKFIX = yesがある場合に何が起こるかはテストしていません...その場合、悪いことが起こる可能性があります。
免責事項：これを行ったUbuntuのバージョンは正確にはわかりません。