毎日、働いてくれているLinux Server君も、あるとき突然ご臨終することは、たまにあります。
特に、複数のLinuxサーバを管理している管理者の方は、年に数回遭遇するのではないでしょうか?
さて、Kernel Panicと、無慈悲な表示を画面に出力して、うんともすんとも動かなくなったらどうしましょう。
ほとんどのケースでは、そうなる前に、Mentenance Login が出て起動しないものの、なんとかシングル
モードでのログインが可能だったりします。
その場合は、通常 fsck または、fsck.ext3 等のコマンドで、復旧することが可能ですが、
Kernel Panicとなり、マウントすらできない状態に陥ってしまうと、自己修復することができなくなります。
そんなときは、debian(ETCH)のインストールディスクから起動させ、起動時に rescueと実行し、
インストール開始し、レスキューの実行で、ディスクにアクセスできる可能性があります。
ただ、マウントできない場合、ここでもエラーになる可能性のほうが高く。
その場合、下のほうにある、シェルの実行でシェルを起動後、対象のドライブに fsck.ext3等を実行します。
コレでほとんどが修復可能です。
この方法は、debianのインストールディスクを使用して、turbo linux等の他のディストリビューションにも有効です。
ただし、仮に復旧したとしても、出来ればすぐさまバックアップをとって、ディスクの交換をオススメします^^;
特に、複数のLinuxサーバを管理している管理者の方は、年に数回遭遇するのではないでしょうか?
さて、Kernel Panicと、無慈悲な表示を画面に出力して、うんともすんとも動かなくなったらどうしましょう。
ほとんどのケースでは、そうなる前に、Mentenance Login が出て起動しないものの、なんとかシングル
モードでのログインが可能だったりします。
その場合は、通常 fsck または、fsck.ext3 等のコマンドで、復旧することが可能ですが、
Kernel Panicとなり、マウントすらできない状態に陥ってしまうと、自己修復することができなくなります。
そんなときは、debian(ETCH)のインストールディスクから起動させ、起動時に rescueと実行し、
インストール開始し、レスキューの実行で、ディスクにアクセスできる可能性があります。
ただ、マウントできない場合、ここでもエラーになる可能性のほうが高く。
その場合、下のほうにある、シェルの実行でシェルを起動後、対象のドライブに fsck.ext3等を実行します。
コレでほとんどが修復可能です。
この方法は、debianのインストールディスクを使用して、turbo linux等の他のディストリビューションにも有効です。
ただし、仮に復旧したとしても、出来ればすぐさまバックアップをとって、ディスクの交換をオススメします^^;
この記事にコメントする