前回の微続きで、カーネルを再構築して入れ替えた際に、そのサーバでioDriveを利用していた場合の対応についてです。

Fusion-io社が配布してくれているモノは十分なのですが、俺の対処が横着だったためにハマった例です。こちらも半年以上前のメモ起こしですが、基本は変わらないはずです。

ioDriveドライバについて

Support :: Fusion-io でログインするとソースやパッケージをダウンロードできます。例えば、ioDrive -> Squeeze -> r2.3.1 と選択して、通常は iomemory-vsl-2.6.32-5-amd64_2.3.1.123-1.0_amd64.deb やその他Utilitiesもろもろ落としてきてサーバにインストールしてioDriveを利用できるようにします。

それと、今回の問題を解決するのに必要な iomemory-vsl_2.3.1.123-1.0.tar.gz も落としておきます。tarballも配布されていることを知らずに解決を試みましたが無理だった例を記しておきます。

カーネル再構築後にドライバを認識しない問題

ioDriveを導入していたサーバで、linux-image-2.6.32-5-amd64 なり linux-image-2.6.32-5-xen-amd64 を再構築したモノを入れなおした場合、iomemory-vslドライバが動作しなくなります。同じドライバを入れなおしても同様です。

具体的な症状としては、カーネル入れ替え後に再起動したら、/dev/fct* を認識しなくなり、ソフトウェアRAIDが組めなくなり、マウントができない── といった内容になります。

この状態でなんとかしようと、モジュールを有効にしようとしてもエラーになります。

この時点では fio-status はパッと見動くのですが、無理矢理 modprobe -f iomemory-vsl で有効にしようとすると、out of memory になってしまい、fio-status すら動かなくなります。

上記例では新カーネル名が 2.6.32-5-amd64-drecom になっていますが、仮に公式と同じ名前のままにしても症状は変わりません。要は iomemory_vsl はちゃんと公式のカーネルに基づいてコンパイルされているため、中身が入れ替わると動かなくなるとうわけです。

iomemory-vslを再構築

パッケージを作りなおす

iomemory-vslのTARBALLが配布されていることを知らなかったため、元のdebパッケージだけでなんとかしようともがきましたが、実はTARBALLからdebパッケージを作成すれば解決しました。

もちろん、コンパイルは新カーネルで動作しているサーバ上で行う必要がありますが、その手順を紹介します。

まずはパッケージ作成に必要なパッケージをインストールします。linux-headersが必要なため、新カーネル作成時に同時に作成しておく必要があります。

次に、ソースを持ってきて解凍します。

場合によって元のパッケージとファイル名が重複しないようリビジョンを変更しておきます。

そしてシンボリックリンクを作成し、パッケージを作成します。

ドライバを入れ替える

作ったdebファイルや、公式パッケージはPrivateAPTサーバに入れておくとします。
ioDrive認識中のサーバでの新カーネルとドライバの入れ替え手順はこんな感じです。

全て停止・削除

パーティション利用の停止、アンマウント、RAID停止、モジュール削除、パッケージ削除、です。

全てインストールして再起動

無事に起動すれば、デバイスの認識からマウントまで元通りに動作するはずです。当然ですが、データはいじっていないので全てそのまま残っています。



この件で嬉しかったのは、TARBALLの中にdebuild用debianディレクトリが既に用意されていたことです。新カーネル用だったためシンボリックリンクは必要でしたが、ちゃんとdebuild一発で動くようになっています。

とまぁこんな感じで我々の208日問題対応が進みましたよ、というお話でした。