ありがたいことに3/11の地震では自宅・会社共に目立った損傷はなかったのですが、災難はその後の計画停電と共に。シャットダウンを忘れたり、頻繁な電源On/Offのためか、2台のLinuxサーバーが立て続けに壊れましたorz
一台は完全にHDDがお亡くなり。幸いにも重要なデータ部分がRAID1運用されていた(というか/bootだけRAIDに入ってなかった)ので、OS入れなおして生き残ったパーティションをコピーして復帰。
もう一台が厄介。まずLinuxのソフトウェアRAID1(md)がホットスペアまで用意してあったにもかかわらず、一方及びスペアがRAID構成から抜け落ち片肺運転に。ドライブを追加しなおして起動しようとするとブートの初期で
Decompressing Linux...done
Booting the kernel
Red Hat nash version 4.2.1.13 starting
exec of init (/sbin/init) failed!!! : 2
Kernel panic-not syncing: Attempted to kill init !
なんてメッセージを出して起動しない。
ドライブ構成はこんな感じに全てソフトウェアRAID1で、LVMはなし。HDDはSCSI。
- md0 100MB /boot
- md1 1GB /
- md2 4GB /var
- md3 1GB /tmp
- md4 20GB /usr
exec of init failedのエラーコード2は、/sbin/initが見つからないということらしい
。
さらにネットで調べたところ、(エラー番号2以外の場合も含め)/sbin/initが失敗するのは以下の理由がありそう。
- /sbin/initそのもの、もしくはそれを格納するファイルシステムが破損している
- fsckしてみる
- 他の動くシステムから/sbin/initをコピーする
- /sbin/initを格納するファイルシステムがマウントできない
- /bootにあるinitrdファイル(一般的に拡張子img)が破損している
- 同ファイルがソフトウェアRAID(md)・LVM・SCSI(aic7xxx)などのカーネルモジュールを含まない形で構成されている
- タイミングの問題でデバイスの認識が失敗した
CentOSなどRHEL系ではカーネルオプション'quiet'を外して起動するとより詳細な情報が。
掲示板でよく見かけた回答は「mkinitrdを使ってinitrdを作り直せ」。やり方は
- LinuxのインストールCDをrescueで立ち上げるなど、ソフトウェアRAIDがマウントできる状態まで持っていく
- ドライブをマウント
mount /dev/md1 /mnt
mount /dev/md0 /mnt/boot
mount /dev /mnt/dev
chroot /mnt
mount /proc
mount /sys
- タイミング問題の場合はmkinitrd (実態はスクリプトファイル)にsleepコマンドを入れるなどする
- initrdを再構築
mkinitrd /boot/(imgファイル名) カーネルバージョン
が、chrootを打ち込んだときに/bin/shが無いだとかPermission deniedだとかで失敗するorz さてどうしたものか・・・
[参考]
[2011/3/30 追記] SATA I/Fカード故障&ファイルシステム破損の複合だった模様。
- SATA I/Fを交換しない限りOS再インストールでも/のマウント失敗
- 交換してOS再インストールすると起動するが、/を以前(故障時に取ったバックアップ・fsck済み)のものに書き戻すとやはり起動せず
- /bootと/以外を以前のものに書き戻すと起動するが、/usr/lib64以下に壊れたライブラリがいくつかある模様
OS新規インストールして、必要なファイルを個別にバックアップから書き戻すことになりそうです。/etcのバックアップファイルがダメージなしなら楽なのだけど。ちなみにOSを入れてあったのは今回故障したSATA I/Fとは別のSCSI I/F(Adaptec 29160)に繋いであったものです。
[2011/3/31 追記] 中盤加筆・修正、参考リンク追加
[2011/6/7 追記] なんてことはない、SCSIケーブルの接続不良だった模様。抜いて挿したら直ったという、教科書どおりの修復なり。でもSATA I/F挿さなかったらそれはそれで動いたんだよなぁ。どちらにしろ/以下OS関連のファイルはダメージを負っていたので、再インストールでした。
RSS2.0
Y:
ALL:
Comments