web-dev-qa-db-ja.com

再起動時にfsck.ext4を強制しますが、実際には「強制」です

Ubuntu 10.04サーバーの1つで問題が発生しています。 fsck.ext4 -n /dev/sda5を実行すると、空きiノード数、空きブロック数などにエラーがあることがわかります。

私が試してみました:

touch /forcefsck

また試してみました:

shutdown -rF now

それでも、再起動後にエラーが表示されます。

また、eeePCネットブックUbuntu 10.10を確認したところ、同じ問題が発生しています!

再起動時に「/」ファイルシステムの本当に「強制」「強制」「ファイルシステムを真剣に修正」fsckを強制するにはどうすればよいですか?

説明:私はfsck.ext4 -nを実行します。これは、ファイルシステムがマウントされているため、エラーがあるかどうかを確認するためです。これはあることを教えてくれます。起動プロセス中の30回のマウントごとの自動fsckは、ルートファイルシステムのエラーを処理するために正確にであると考えました。しかし、私の場合はそうしません。 LiveCDで再起動してエラーを修正してから再起動することもできますが、それはライブサーバーの深刻なダウンタイムです。再起動し、自動fsckを実行してから、起動を続行することは、ライブサーバー上ではるかに持続可能であり、適切な動作であると考えています。

追加情報:出力は次のとおりです。 autofsckで修正できるように見えますよね?

root@server:~# fsck.ext4 -n /dev/sda5
e2fsck 1.41.11 (14-Mar-2010)
Warning!  /dev/sda5 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1849368, counted=1948909).
Fix? no

Free inodes count wrong (545504, counted=552134).
Fix? no


/dev/sda5: ********** WARNING: Filesystem still has errors **********

/dev/sda5: 116752/662256 files (0.2% non-contiguous), 795324/2644692 blocks
21
UrkoM

E2fsckのmanページから:

「一般に、マウントされたファイルシステムでe2fsckを実行するのは安全ではないことに注意してください。唯一の例外は、-nオプションが指定され、-c、-l、または-Lオプションが指定されない場合です。ただし、たとえ安全であってもファイルシステムがマウントされている場合、e2fsckによって出力される結果は無効ですe2fsckがマウントされているファイルシステムをチェックするかどうかを尋ねる場合、唯一の正しい答えは '' no ''です。彼らは他の方法でこの質問に答えることを検討すべきです。」

そのため、-nオプションを使用してもfsckでマウントされたFSをチェックすると、結果がまったく無効になる場合があります。マウントされたファイルシステムをチェックしないでください。 Live-CD/Live-USBを使用します。

マウント中にファイルシステムをチェックしないと、touch /forcefsckを使用する必要がある理由がわかりません。アンマウントして修正することができます。しかし、そうであり、修正後もFSにまだエラーがある場合は、次の使用を検討できます。

e2fsck -cy /dev/sda5

これにより、不良ブロックと呼ばれるハードドライブ関連の問題が修正されます(これには長い時間がかかります)。

マウントされたファイルシステムをチェックしたい場合、どうすればよいかわかりませんが、別の質問を作成する必要があると思います。

私はこれが本当に古いスレッドであることを知っていますが、最近この問題を解決する必要があったので、ブートアップ中にfsckで見つかった問題をOSに強制的に修正する方法を投稿したかった(12.04)。

コマンドSudo touch /forcefsckを実行する必要があります。これにより、次回の起動時にfsckが実行されます。 /var/log/boot.logでfsckの結果を確認できます。

ただし、fsckが見つけたものをすべて修正する保証はありません。これを行うには、ファイル/ etc/default/rcSを編集する必要があります。そのファイルの最後に行があります:

FSCKFIX=no

これを次のように変更する必要があります。

FSCKFIX=yes

これは、-yオプションを指定してfsckを実行するのと同じ効果があり、実装可能なすべての修正を強制し、ユーザーの操作を要求しません。

これにより、特にリモートシステム上にいる場合は常に可能とは限らないライブディスクからの起動に頼ることなく、OPが要求したようにfsckを実行できます。

24
Brian
Sudo touch /forcefsck
Sudo reboot

タイプミスがあります。/forcefcskに触れています。 「c」と「s」が入れ替わっています。 fsckはFileSystemChecKの略です。

12
Dan Benamy

パーティションが使用中であるため、修復する/にfsckを強制することはできません。別のパーティションまたはライブCDからチェックを実行してください。

3
charlie-tca

次の方法で自動的に改訂を行うことができます。

Tune2fs -c 5 -i 10 / dev / sda1

-cは、fsckを実行する前の最大マウント数であり、-iは、fsckを実行する前の最大日数です。

この場合、5回のマウントごと、または10日ごとのいずれか早い方に行われます。

私は2台のコンピューターを所有しています。1台はLinux SuSE 13.2で、もう1台はLinux Mint 18.0で、両方とも完全に動作します。

1
hk3jld

touch /forcefsckだけでは、次回の起動時にシステムがfsckで動作することを保証しませんでした。私も実行する必要がありました:

Sudo tune2fs -c 1 /dev/<my partition>

例えば.

Sudo tune2fs -c 1 /dev/sda1

私が見つけたより多くの説明はここにあります: fsckにリブート後にファイルシステムをチェックさせる方法

0
Clock ZHONG