bird自宅サーバダウン (と、年始の挨拶), きょうのつぶやき

自宅サーバダウン (と、年始の挨拶)

すみません、Twitter を見ていた方はご存知と思いますが、ここ数日この自宅サーバが落ちてました。

顛末を話せば長いのですが1、事の発端は、最近僕の周りの友人宅でも頻発している PS3 の故障 (特に PS2 互換機能付きの初代機はヤバいらしい) に備えるために、自宅の PS3 のバックアップ2を取ろうと思い立ったことでした。普段 PS3 には 250GB の USB HDD が接続されており、今回も最初そこへバックアップを取ろうとしたんですが、3時間くらい処理したあげく、「空き容量が不足しています。」ということで失敗。120GB の内蔵 HDD のうち 70GB 程度使用、外付け HDD の方が 120GB くらいまだ空いていたので大丈夫だと思ったんですが…。つーか空き容量くらい最初に調べてよ!

しょうがないので自宅にもう一つあった別の USB HDD (160GB) にバックアップしようとそちらの準備をいそいそと。そっちはかつて自宅 VAIO 君の内蔵 HDD が入っているので、今は NTFS でフォーマットされています。そのままでは PS3 では認識できないので、最初 VAIO 君につないで FAT32 でフォーマットしなおそうと思いました3

さて、FAT32 でのフォーマットの前に、もともと内蔵ディスクだったせいでパーティションも3つに分かれていたままだったので、まずはパーティション構成を修正しようと一番後ろのパーティションを削除したところ、VAIO 君の Explorer がハング。しょうがないので再起動後再挑戦してみたんですが、今度は USB HDD を挿しただけで Explorer がハング(汗。どうもおかしな状態に陥ってしまったようです。

どうにもらちがあかないので、Windows よりもなにが起こっているのかがわかりやすい、Linux の自宅サーバにつないでみることにしました。ところが、やっぱり USB HDD デバイスにアクセスに行くプロセスは無限待ちになってしまいます。そればかりか、Kernel Driver が Console に定期的にエラーを吐く状態に。USB HDD を抜いても止まりません。どうも USB HDD 側からの応答がない感じですね。

で、面倒だったので自宅サーバも再起動してみることにしたんですが、それが運のつきでした。自宅サーバは普段、毎朝自動でパッケージアップデートがかかるように設定しています4。ずっと起動しっぱなしにしている分にはめったにトラブルは起きないのですが、そうやって自動的にアップデートされたパッケージのせいで、「起動しなくなる」ことがときどきあるのです(なんとも恐ろしい)。今回もまさにその罠にハマってしまいました。再起動中、「root fs が見つからない」で Kernel Panic。しかもいろいろごちゃごちゃやっているうちに BIOS 画面から先に進まなくなってしまったりして。いよいよ万事休す、という状態でした。(ここまでが一日目。HDD からブート自体ができなくなっていたので、この時点ではハード故障も疑っていました。)

ところで、自宅サーバで使っている Think Pad X20 は、モバイルノートなので HDD 以外のストレージデバイスを持ちません。何しろ古い PC なので、BIOS も内蔵 HDD とフロッピーディスク以外は、Network からの起動(!)くらいにしか対応していませんでした。ところが昨今の Linux Distro でフロッピーのブートディスク/Rescue ディスクを持つものはもうほとんどありません5。たいてい CD-ROM です。うーん、困った!

…というのは嘘でw。今までもこういう状況はしばしば発生したりしていたので (<ダメじゃん!・笑)、実は予め一つの対策をしてありました。自宅サーバの HDD を3つのパーティションに分け、先頭のパーティションに MS-DOS をインストール、そこに Linux カーネルと LOADLIN.EXE など、最低限のツールを入れておいたのです6
そんなわけで、Lilo のプロンプトが表示されているタイミングで Shift キーを叩いてメニューを表示させ、予め仕込んであった DOS を起動、LOADLIN を使って古いカーネルで起動してみたところ、とりあえず Single User Mode で起動しなおすことに成功しました。

さて、再起動後、とりあえず初めにやったのが、kernel pkg の reconfigure でした。再起動に失敗する、ということは、ほとんどの場合、kernel pkg の install がうまく行っていないことに由来します。そこで、reconfigure してみれば何かエラーがあればわかるだろう、と考えました。手順としてはまず、

# dpkg -l "*linux-image*"

として今インストールされている中で最も新しい kernel pkg は何かを調べます。今回の場合、「linux-image-2.6.26-2-686」という pkg が最新のようでしたので、そちらを reconfigure してみました。

# dpkg-reconfigure linux-image-2.6.26-2-686

すると、特にエラーもなく終了します。/boot 以下に生成された、新しい initrd.img-2.6.26-2-686 のサイズが前バージョンよりも妙に小さい点が少し気になりましたが7、とりあえず念のため lilo の再インストールを行った後8、再起動してみました。

しかし、結果はあえなく惨敗。ブートメッセージから kernel が正しく切り替わったことは確認できましたが、今度はまた別の、起動中に「Waiting for root file system」というメッセージを出して止まり、しばらく待つとほとんど周辺デバイスを認識していない状態で Busybox Shell に落ちる、という状況でした。

停止する直前に見えるその、「Waiting…」メッセージでググってみたところ、僕が使っている Debian lenny のドキュメントに、そのものずばりの「4.8. システムの起動が Waiting for root file system とともにハングしてしまう」という項目を発見。ふむふむなになに、これまで hda1 等として認識されていた内蔵 HDD が sda1 等となってしまうことがあり、デバイス名で直接 root fs を指定している場合に起動しなくなることがあるのか。

まぁこんな事は Linux ではよくあること<ヲイ。早速ここに書かれた対処方法のうち、「fs に LABEL をつけて、そちらで指定するようにする」を行うことにしました。

まず、自宅サーバの root fs は XFS なので、xfs_admin コマンドにより下記のようにして LABEL をつけます。この際本当は、その root fs 以外を root として (rescue ディスクを使うなどして)、mount されていない状態で行った方がいいんですが、今回はちょっとそういう状況を作るのが難しかった&めんどくさかったので、-f オプションをつけてマウント中の fs に強制的に LABEL を書き込みました。

# xfs_admin -f -L ROOT /dev/hda3

また swap パーティションにも LABEL を書いておきます。こちらはいったん swapoff するようにすれば、安全に LABEL を書き込めます。

# swapoff -a
# free # swap がないことを確認  
# mkswap -L SWAP /dev/hda2

最後に、/etc/fstab をこれまでのデバイス名直接指定から、LABEL 指定に切り替えました。書き換え後の fstab は以下の通りです。

tpx20:~# cat /etc/fstab
LABEL=ROOT      /               xfs     defaults                        0       1  
LABEL=SWAP      none            swap    sw                      0       0  
proc            /proc           proc    defaults                        0       0  
/dev/fd0        /floppy         auto    defaults,user,noauto            0       0  
/dev/cdrom      /cdrom          iso9660 defaults,ro,user,noauto         0       0

この状態でまず、再起動を試みてみることにしました。まず、再起動後の「LILO:」プロンプトで Shift キーを押し、LILO の boot メニューを出します。そこで、boot オプションとして以下を指定します。

boot: linux root=LABEL=ROOT single

起動時の root fs はブートローダーから指定されるもの (root fs 内に入っている /etc/fstab は root fs をマウントするまでは読めない…缶詰の中に缶切りが入っている状態なので) ですから、上記のようにして新しく LABEL 指定で root fs を指定してあげる必要があります。ほんとうは再起動前にブートローダーの設定を変更しちゃっても良かったんですが、1) 起動時プロンプトで明示的に指定できること、2) 動作しているブートローダーの設定を壊してしまうのが怖かったこと、3) そもそもこの段階では LILO で LABEL で root fs を指定する方法を知らなかったこと(^^;、などの理由から、行いませんでした。

さて、先ほどのドキュメントのページの記述がビンゴなら、これで正しくブートできるはずです。しかし結果は今までと変わらず、「Waiting for…」で止まってしまいます。あっれー?

どうも原因は他にあったようです。しょうがないのでもう一度原因について考察してみることにしました。問題は、root fs が見つからなくて停止してしまうこと。停止後の Busybox シェルでも、ほとんどデバイスは認識されていない状態であること9。ここでふと、「そういえば initrd.img のサイズが少し小さかったな…」ということに思い至りました。Debian の場合、kernel pkg の install プロセスの中で、initrd.img を作成しているのは initramfs-tools というツール群で、その設定ファイルは /etc/initramfs-tools にあります。そこでそちらを覗いてみると、initramfs.conf という設定ファイルと、新しい pkg により内容が更新されたが、まだインストールはされていない10ことを意味する initramfs.conf.dpkg-dist がありました。おお、これは怪しい。

早速オリジナルの initramfs.conf と dpkg-dist 版の diff を取ってみました。変更点はさほど多くないながら、これまで「MODULES=dep」となっていた部分が、新しい方では「MODULES=most」となるようになっています。

そこで早速上記を新しい方に合わせて修正し、再度 kernel pkg の reconfigure を行ったところ、今度は /boot 以下の initrd.img のサイズが今までの3倍くらいに大きくなっています。おお!

そして再起動を行ったところ、ようやく、きちんと再起動して上がってくるようになりました。いやーよかったよかった。

ところで、無事再起動できたマシンの状態をチェックしたところ、うちの環境では HDD の名前が変化する、という状況は実は発生していませんでした(つまり /dev/hda1~3 のままだった)。つまり、LABEL 名で指定するようにするという対処は実際は必要なかったわけですが、とはいえ実害もないので、とりあえずこのままにしておく予定です。

最後に lilo の設定も LABEL で root fs を指定するよう修正して再インストールし、そちらでも無事に再起動することを確認して、とりあえず今回のトラブルは無事収束しました。いや〜、久々のトラブルでいろいろ勘が鈍ってて、今回はさすがにちょっとあせりました。上ではまとめてさらっと書いてますが、実際にはこの10倍くらいいろいろ試行錯誤したりググったりしてます(汗。でも時々こういうことがあると、頭の体操になっていいかも<え。

…こんなふうに波乱万丈な船出となった 2010 年、皆さま今年もよろしくお願いします<えー。

きょうのつぶやき

自宅サーバ、ハードはまだなんとか壊れてないっぽい。起動時root fsが見つからなくてコケてる模様。いくつか対処を試してみたが、どれも不発。続きはまた今度。 (00:02 webから)

自宅サーバとりあえず復活?いちお、memo.digitune.org見えるようになったっぽい。 (08:30 webから)

原因はたぶん、initrdが壊れてたから、かなぁ。 (08:30 webから)

時間があれば今回やったこと、後でまとめます。疲れた…。 (08:31 webから)

最近、僕が使っているInternet接続環境からだとどれでも全てほぼ確実に2chに書き込めない。はて、するってーと今書き込んでるのってどんな人なんだろ? (10:14 APIから)

すげぇ! RT @keng_jp うしっ! ソーシャルネットワーキングで3位。Tweetie 2を追い抜いてTwitterクライアントとしてはトップ!  App Store総合ではTop 100入りの94位。#ramblin (21:12 webから)

今日は久しぶりに妻と夜ドラに行こう〜♪ (21:16 webから)

コメント

kapi (Sat, 13 Mar 2010 13:19:35)
ウチもようやっとPS3のHDD入れ替えたよ。
がー、やはりバックアップがちぃーと問題に。
1TBの外付けHDDがあるからよゆーだぜーと思ってたらフォーマットがNTFSだった。
今時FAT32のHDDなんかあるけー。
と思ったが、意外なドライブの存在に気づいた。
こないだ買ったハンディカムじゃー。
PS3につなげてみたところ、見事FAT32のHDDとして認識。
バックアップとってみたらできた。
digitune (Tue, 23 Mar 2010 20:45:46)
おお、ようやくRSS Readerでここまで追いついた(汗。
ナイスハックでしたな>バックアップ。

PS3のバックアップはちょっと微妙な仕様があって、コピ禁セーブデータは確かバックアップ出来なかったような。しかし新旧PS3を2台使う「移行ツール」の方は可能とかなんとか。何じゃそれ!
kapipi (Wed, 07 Apr 2010 01:07:55)
SCE解散乙
PS3は本体一万五千円ぐらいにして毎月千円ぐらい払わせるゲーム配信ビジネスにシフトすれ。
有名ゲームの短編シナリオでも毎月配信しとけばアフォどもは喜ぶだろう。メーカーはパッケージソフトの宣伝もできて一石二鳥。2年縛りにすれば黒になる。
あとVAIOへのリモートデスクトップ機能を付けてシナジー効果を期待。PC販促グッズ化させることで本社にも文句言わせないようにする。
さらに、俺に経営権を渡すことで4年で立て直しすることが可能だ。某play faceとか言ってたやつを始めとして無能っぽいやつは即座に座敷牢送りじゃ。
digitune (Fri, 09 Apr 2010 08:48:30)
うむ。とはいえ基本何も変わってないんだかな。
びしねすはいろいろむつかしいネー。
なぜか偉いんだけどロジカルでない人たちの意見を調整するのはほとんど不可能だしそもそもやるべきじゃないよ…。

  1. いや、そうでもないかも・汗。 ↩︎

  2. そう、PS3 って内蔵ハードディスクのバックアップ機能があるのです。なんというおもちゃだ。 ↩︎

  3. 160GB USB HDD を FAT32 でフォーマットしようと思うと、Windows 標準機能ではムリなので、何らかのツールが必要になります。自宅 VAIO には以前買った USB HDD についていた、メルコ製の Disk Formatter がインストールされていました。 ↩︎

  4. セキュリティホールが発見されても速やかに自動的に適用されるように。 ↩︎

  5. 原因はたぶん、Kernel の肥大化でしょうね。標準的なデバドラを含めるだけで、FDD 1枚には収まりませんから…。 ↩︎

  6. ちなみに2番目が swap パーティション、3番目が root です (「HDD は先頭に近い方がアクセスが早い」というかつての知識を未だ信じてる俺)。しかし最近のブートローダーは Kernel が Disk のどこにあってもブート可能なんですねー。 ↩︎

  7. 後から思えばこの時点でもう少しちゃんと調べるべきだった…。 ↩︎

  8. root ユーザで「lilo」と実行するだけです。 ↩︎

  9. ただこれは、最近の Linux で導入されている udev の場合そういうものなのかも、と思ったりもしていました。 ↩︎

  10. 設定ファイルでは、各サーバマシンの事情により管理者が設定を変更している可能性がいろいろあるため、pkg にもともと含まれる default の設定ファイルを強制的に上書きしてしまう事>はせずに、このように設定ファイルの横に .dpkg-dist という名前で置かれる、という作法になっています。 ↩︎