Linux 起動時に UNEXPECTED INCONSISTENCY で起動しない場合の対処方法

えーっと・・・個人的には VMware まわりで何度かこのエラーに遭遇しているわけですが・・・

ホストのおたんちん Windows が VMware 起動中にまるごと落ちてくれたりすると VMware 側の Linux ファイルシステムに以上がでることがたまにあります。まぁイメージ的には電源をいきなりオフにするような感覚ですから。

で、ファイルシステムに整合性がなくなった状態になると Linux 起動時にエラーで止まります。ext3 とか使っていてジャーナルファイルだけで何とかなる場合には自動修復して起動するわけですが、より派手に壊れるとダメなわけです。

Your system appears to have shut down uncleanly
Press Y within 3 seconds to force file system integrity check...
Checking root filesystem


/dev/VolGroup00/LogVol00: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options )
                                                           [FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):

さて、起動しなくなったモノは仕方がない。画面のメッセージ通りにマニュアルで fsck 実行しろと言われているのでその通りにするしかありません。

/dev/VolGroup00/LogVol00: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options )
                                                           [FAILED]

のように壊れていると判断されているデバイス毎に fsck を実行します。ファイルシステムのタイプ指定を念のために行っておいた方がよさそうです。破損箇所を修復するかと聞いてきて、いちいち "Y" を答えるのが面倒だけど、エラー画面に書いてあるとおり "-a" や "-p" オプションは除いて実行しなければなりません。Linux のファイルシステムが解析できる人以外は、タダひたすら "Y" を連打するだけで面倒くっせーんですが・・・連打します。

というわけで、入力コマンドはこんな感じ。

fsck  -t  ext3  /dev/VolGroup00/LogVol00

画面イメージはこんな感じ。ちょうど今日実行してました。fsck でチェック＆修復する時間は HDD の要領に比例して馬鹿長くなりますが、150GB 程度のシステムで２時間ほどかかりました。

1.　まずエラー画面　→　fsck の実行

2.　ひたすら "Y" 連打で修復

3.　修復完了

修復が完了したらリブートしてみる。リブートしてみて同じように fsck を求められたらそのデバイスに対しても実行します。いつまで経ってもこのフェーズから抜けられない場合や、修復後に結局起動しなかった場合は、起動に必要な重要ファイルが逝ってしまったと言うことで、素直に諦めて再インストールした方が常人なら再構築への一番の近道だと思われます。

なお、めでたく起動した場合は、修復したファイルは /lost+found っていうゴミ箱もどきのようなフォルダは如何に格納されています。必要そうなデータファイルなら名前を変更してあげれば再利用できます。まぁ残念ながらファイル名はノード名で保存されているので、中身を見ないと何が何のファイルだったのかわからないので待避されたファイルが大量になるとゲンナリします。

/lost+found 周りをより詳しく知りたい方はぐぐって深追いしてみて下さい。このエントリではココまで。

まぁ VMware 上の開発環境と言えども fsck での復旧は時間がかかるし面倒くっさかったですわぁ〜本番だったら冷や汗もんですけどね。