コグノスケ

レコーダーがやってきた

奥さんが何か番組を録画したいと言っていたのでレコーダーを買いに行きました。せっかくだし会社に貢献するかなってことで、DIGA DMR-BWT1100を買いました。

昔レコーダのチームの人に型番の読み方を聞いたんだけど、忘れましたね…。確かBWTはB: Blu-ray対応、W: 2チューナ（Z: 3チューナ、R: 1チューナ）、T: 3D対応（何も無し: 3D未対応）、だっけ？数字は計画性が無くて100増えたり1000減ったりしてイマイチ意味がわかんねーです。

アンテナ線

さっそくDIGAをテレビに繋ごうと思って、今日テレビの裏を見たら、引っ越し当初に「映ればいいだろ、こんなの」ってずさんな配線をしたのを思い出しました。

家にあるAQUOSは地デジもBSも映るのに、アンテナ線が1本しか繋がっていません。UHF/BS混合の信号をBS端子に入れて、地デジ端子を開放状態にすると、地デジもBSも映ってしまうためです。

でもDIGAはそんなヘンテコ仕様になってないので、UHF/BS分配器とアンテナ線3本が追加で必要です。分配器はどうでもいいとしても、アンテナ線が全然足りません。後で買ってくるか…。

RAIDが崩壊した

外付けHDDのドライバをカーネルモジュールにして、めでたしめでたし…かと思ったら、起動時に変なメッセージが出ています。読んでみるとHDD 5台構成にしたはずのRAID 5が4台構成で動いています。

md: md0 stopped.
md: bind<sdb>
md: bind<sdd>
md: bind<sde>
md: bind<sdf>
md: bind<sdc>
md: kicking non-fresh sdb from array!
md: unbind<sdb>
...

あるぇー、なんで /dev/sdbが弾かれてるの？HDD壊れたかしら？って思ったのですが、違いました。内蔵HDDをsdfのままで一度起動したことが原因でした。

RAIDさんの憂鬱

デバイスファイル名だとわかりづらいので、変化前の内蔵HDDがsdaだったときのデバイスファイル名を小文字で、変化後のsdfだったときのデバイスファイル名を大文字で書きましょう。対応表は下記の通り。

上記を踏まえて時系列で説明してみましょう。

• RAIDは（sdb, sdc, sdd, sde, sdf）で組んでいたので、変化後は（SDA, SDB, SDC, SDD, SDE）でRAID 5を再構築しなければなりません。
• そんなことつゆ知らずのRAIDシステムは同じデバイスファイル名（SDB, SDC, SDD, SDE, SDF）でRAID 5を再構築しようとします。
• 内蔵HDDのSDFはRAID 5の構成部分ではありませんので、RAIDシステムは「SDFが変になった！」と判断します。
• RAIDシステムはSDFをアレイから外し、SDB, SDC, SDD, SDEつまりsdc, sdd, sde, sdfの4台構成にします。
• 内蔵HDDがsdaになって、再び元の構成に戻ります。
• そんなの関係ねえRAIDシステムはやっぱり同じデバイスファイル名（sdb, sdc, sdd, sde, sdf）でRAID 5を再構築しようとします。
• 先ほどの4台構成に入っていなかったsdbだけ更新されておらず、情報が古いためRAIDシステムは「sdbが変になった！」と判断します。
• RAIDシステムはsdbをアレイから外し、sdc, sdd, sde, sdfの4台構成にします。←今ココ

とまあ、RAIDシステムのバカなんだか賢いんだかよくわかんねえ動きをしてくれた結果、4台構成になってしまったわけです。それにしてもHDD認識の順番がころころ変わるのは困るのよねー…。

RAID復っっ活！！

直し方は時間かかりますがとても簡単です。sdbが物理的に壊れたわけではないので、単にsdbをもう一度アレイに追加すれば良いだけです。

# mdadm --manage /dev/md0 -a /dev/sdb

こんな感じです。長くても1日ほっとけば直ってると思います。アレイを直している様子が見たければ、$ cat /proc/mdstatで概要が、# mdadm --detail /dev/md0で詳細情報が見られます。

ファイルサーバのカーネルを入れ替え

家のファイルサーバを復活させたついでに、Linux Kernelを2.6.30からlongterm maintenanceの2.6.35.9に入れ替えました。2.6.30以降のどこかでファイルサーバのCPU（Intel Atom）への対応が入ったのと、longtermなら中途半端なバージョンよりは安定している気がすると思ってのことです。

コンパイルしていざ再起動するとkernel panic…。rootがマウントできないと怒っています。

今までは内蔵HDDがsdaで、外付けのRAIDがsdb, sdc, sdd, sde, sdfだったのですが、カーネルを入れ替えたら内蔵HDDがsdf外付けのRAIDがsda, sdb, sdc, sdd, sdeになってしまったようです。

認識順序が変わったかなと思って、試しにroot=/dev/sda1をroot=/dev/sdf1に変えて再起動したところあっさり起動しました。しかしトラブった時のために昔の環境も残しておきたいのですよ。

カーネルごとに設定を書けるgrubは良いとしても、/etc/fstabはそうはいきません。swap領域に /dev/sda5を使っているので、カーネル入れ換えごとに /dev/sda5にしたり、/dev/sdf5にするのは面倒くさいです。

モジュールにしよう

設定ファイルをいちいち書き換えるのは面倒くさいので、内蔵HDDさんにはなんとしても /dev/sdaで居ていただかなくてはなりません。そのためにはカーネルから一番最初に内蔵HDDを認識してもらう必要があります。

幸運なことに私の環境では内蔵HDDのドライバはata_piixで、外付けHDDのドライバはsata_sil24と異なるドライバが使われていましたので、ata_piixをカーネル組み込みに、sata_sil24だけモジュールにしました。これならata_piixが一番最初に認識され、rootがマウントされ、その後sata_sil24が認識されます。バッチリです。

最初はLinuxのHDD認識のアルゴリズムを見ないとわからないけど、面倒くさそうだなあ？？と考えていたのですが、そんなこと調べるまでもなく単純に解決できたのでした。

めでたし、めでたし。