本日、またまた自宅サーバがおかしくなりました。
前回はファイルシステムがおかしくなり、起動に必要なファイルやディレクトリが消えてしまったわけですが、今回も似たようなもので、statに失敗するディレクトリやファイルが発生してしまいました。
どうしようも無いので、落ちるのを覚悟でリブートしたら、やっぱり落ちました。(^^;
#壊れた状態にメールなどが溜まるより、止まっていた方が良いので。
実は前回修復時、以前の轍は踏むまいと、MBRはPC-DOS7のを入れて起動パーティションのSuperBlockにliloのBootAreaを書込み、念のため起動パーティションも/bootとして別パーティションに分け、/bootも安全にミラー(RAID1)が掛けられるはずだったのですが、、、
#/etc/fstabはこんな感じ。
/dev/hda2 swap swap defaults 0 0
/dev/hdb2 swap swap defaults 0 0
/dev/md1 / ext3 defaults 1 1
/dev/md0 /boot ext3 defaults 1 2
/dev/md2 /home ext3 defaults 1 2
実際には「/」に割当てた領域の片側(/dev/hda3)が、どうやってもraidhotadd(mdadm --add)できなかった(Error:-16)のですが、どうやら起動時に/dev/hda3を見に行ってしまい、そのままマウントしたのと同じ状態になるという、バグにはまってしまい、いつか直そうとそのまま放置していたのです。
さらに悪いことに(ファイルシステムが壊れるまで気がつかないでいたのですが)、なぜか「/」に/dev/hda3が本当にマウントされていて、なおかつmtabでは「/」には/dev/md1がちゃんとマウントされていることになっている、、、という、訳の分らない複雑な状態に陥っていたのでした。
これなら、ファイルシステムも壊れるよなぁ。。。
今度は2時間掛けて何とか修正しましたが、当初試したのは、
・インストールCDでbootして/dev/hda3を修復
・/dev/md1(実体は/dev/hdb3)の中身も慎重に修正
、、、でも、やはり/dev/hda3がraidhotaddできません。
ただし、今度は/dev/hda3は、完全に切離されている状態(なぜかというと、その前は/dev/md1=「/」の内容を書き換えると、/dev/hda3をテンポラリでマウントした中身も書き換わっていた!)なので、少し安心。(^^;
そこで、当てずっぽうに/dev/hdb3を「/」にマウントしてみたりして、最後にちゃんと/dev/md1で起動したら、、、あら不思議、何の問題も無くraidhotaddができました。(^^)
原因は分りませんが、何らかのタイミングで/dev/hda3が起動時に参照されないことがあり、raidhotaddできる状態で起動できるようです。
以降も何回かliloの実行、リブートはしましたが、問題ありません。
もう怖いので、これ以上余分にはRAIDそのものは触りませんが、やっぱりハードウェアRAIDの組めるサーバが欲しいです。
そうしたら、今のサーバを引退させて、もう少し今回の原因を確かめる気にもなるのですが。(^^;