Ubuntu 9.10でgit経由のカーネル再構築

ついでなので、gitからUbuntuカーネルコードをダウンロードする方法も試す事にしました。 VMWareで新しいCloneを作ったので、i386 Desktop版をインストールして最新の状態にアップデートした状態からのスタートです。

参考資料

後半の手順は前回のYet Another Diary::Ubuntu 8.10 (interpid)以降でのsystemtapと同じです。

あいかわらず本家のKernelCompileです。

そこからUbuntuのバージョン毎にgitを使った方法を載せているHow to compile a kernel for Ubuntu Karmicに飛んでいます。

事前準備

$ sudo apt-get install fakeroot kernel-wedge build-essential makedumpfile
$ sudo apt-get build-dep linux
$ sudo apt-get install git-core libncurses5 libncurses5-dev

カーネルコードの展開

今回はVMWare上の/homeに30GB分の別のHDDイメージを作成しました。"rsync -av"でデータを移してから/etc/fstabを編集して再起動しています。

$ cd
$ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git source
$ cd source
$ git checkout Ubuntu-2.6.31-15.50 -b rebuildtest

"debian.master/changelog"ファイルをみて、"2.6.31-15.50"が直近のリリースされたバージョン、"2.6.31-15.51"が作業中のUNRELEASEDバージョンだと分かります。

最後の"-b"オプションに続ける"rebuildtest"の部分は適当な名前をつけます。 これで~/sourceにkernelのgitリポジトリが構築できました。

試しに$ git branchを実行すると、自分が作成した"rebuildtest"プロジェクトの他に"master"というブランチ名が確認できます。 カーネル開発をする分けではないですが、最新のカーネルコードを取得したい場合には、まず"master"ブランチを最新に更新し、それから自分用の"rebuildtest"ブランチのコードに更新をかけるのが良いと思われます。

2009/12/09追記：
最新のカーネルコードにするためには、"git branch master"で一旦branchを変更してから"git pull"でリポジトリからコードを持ってきます。 参考資料にある手順は自分でカーネルコードに変更を加えている前提で書かれているため、マージの手順が面倒になっています。
単純に新しいカーネルコードをビルドするだけであれば、新しいブランチ名で"git checkout"の部分をやり直すのが簡単だと思います。

あとは前回と同じ

注意するところは、まだセットアップが完了していないので前回debian/rules updateconfigsを実行する代りに下記のコマンドで"debian/control.d"などを作成する必要があります。

$ debian.master/scripts/misc/kernelconfig oldconfig

この後で$ fakeroot debian/rules clean、$ time AUTOBUILD=1 fakeroot debian/rules binary-mygenericのように進めていきます。

*.deb, *.ddebパッケージの作成完了まで90分ほどかかる見込みです。

linux-image-debugパッケージがない事の損失

linux-image-debugパッケージがapt-getできなくても、どこかのFTPサーバーに入っていれば良いのですが、残念ながらそうなっていないようです。

今回のような手順で"generic"パッケージを作っても、apt-getした"linux-image"と手元で作成した"linux-image-debug"は異なるものなので、systemtapをフルに使うためには今回作成したパッケージと一緒にインストールする必要があります。

systemtap以前はデバッグパッケージは開発者が文字通りデバッグ用に使うぐらいしか用途がなかったと思います。 しかし、これから普及が進めば問題が発生した場合、ある程度はサービスを停止せずに問題を絞り込む事ができると期待しています。

systemtap自体はこれだけで問題を解決するには難しいですけれど、server/clientの枠組みもできて、 原因を追求するために問題が起っている、そのマシンの状態を把握できるというのは必要なことです。

もしカーネル開発者が自分たちの視点だけで、肥大化するカーネルパッケージのサイズを絞り込む方法を考えるなら最初からビルドしないという選択肢もありそうですが、今後はせめて本番サーバーとして使われそうなLTSだけを対象にしてdebugパッケージをダウンロード可能にして欲しいところです。