カスタム Linux カーネルの FAQ

概ね Debian で配布しているビルド済みカーネルはあらゆるシステム、アーキテクチャで問題のないように
設定の多くを =m や =y にセットしており、多くの機能が有効になっています。

(やりすぎると起動できなくなりますが) 自身が管理しているシステムでは不要なデバイスドライバ等のモジュール並びに カーネルの機能を無効 (=n) にしたり、またデスクトップ用のパフォーマンス向上機能を有効化したい、 外部カーネルモジュールによっては必要とされるコンフィグが無効化されているので有効化したい、 パッチを当てたいなど、
コンフィグや時にはソースコードを変更してビルドしたいケースがあると思います。

また Debian アーカイブにはまだ収録されていない最新のカーネルを使いたい場合もあるでしょう。

そのような場合は本項目を参考にカーネルを再構築しましょう。

Debian における標準的で多くの人が実施していると思われる、make-kpkg コマンドによるビルドをまず説明します。
通常はこの方法で問題ありません。

公式カーネルパッケージについて知りたい

squeeze では公式パッケージとして付属するユーティリティ、文書等を含む以下のものが用意されています。
(x はカーネルの SUBLEVEL, ARCH は Debian のサポートアーキテクチャ名 (例:amd64, i386) を表します。)

主なソースパッケージは 2つで、それぞれ linux-2.6, linux-kbuild-2.6 ソースパッケージです。

linux-2.6 ソースパッケージ

linux-2.6 ソースパッケージ (バージョン 2.6.x)。
このソースパッケージには Debian 固有のパッチは適用されていません。 すなわち上流カーネルソースそのものです。
Debian 固有のパッチはビルド中に適用されます。

このソースパッケージから以下のバイナリパッケージが生成されます。

  • linux-base: 基本パッケージ。
    中身は 2010 年 11 月現在では perf コマンドのラッパーしかないが、 util-linux 等の起動に必要なパッケージをインストールさせ、 メンテナスクリプトでパッケージインストール後に /etc/fstab 等の UUID 化対応を行っています (参照)。 カーネルソース更新の度にビルドされ、カーネルパッケージはこのパッケージに常に依存し カーネルインストール前の準備を行います。
  • linux-doc-2.6.x: カーネルソースの Documentation/ 以下をパッケージングしたもの。
    カーネル/モジュールパラメータの調整の為の手順、デバイスドライバと対応 H/W の情報などカーネル内部の情報が ほぼ集約されています。
  • linux-image-2.6.x-ABI-SUBARCH: カーネルイメージ、カーネル本体です。
    パッケージはカーネルのメジャーバージョン (2.6.x)、 ABI そして SUBARCH で識別されます。
    SUBARCH はサブアーキテクチャでシステム上での確認は uname -m でできます。
    ABI は通常英数字で指定され、これが変更された場合カーネルの ABI (共有ライブラリ の用語を真似て SONAME とも言います) が変更された事を示し、同じ上流ソースから作成されたパッケージであったとしても ABI が異なるパッケージでは 状況によって挙動が変わる可能性があります。changelog 等を必ず確認して下さい。 (参照: Kernel ABI Changes)
  • ABI 破壊の例としては、あるシンボルが特定の場合を除いてエクスポートされ無くなり 外部カーネルモジュールが動作しなくなったなどというケースがあります。 (マクロ EXPORT_SYMBOL, EXPORT_SYMBOL_GPL 等の情報を参照。)
    シンボルのエクスポートの許可・不許可は、ソースコードを改変することによるものだけではなく、 カーネルコンフィグの ON/OFF によってシンボルのエクスポートの許可・不許可がスイッチされるものもあります。
    従ってコンフィグを誤るだけで簡単に ABI が破壊されます。 カーネルの更新と同時に外部カーネルモジュールの再構築を行うのは常識なので、 おそらく外部カーネルモジュール構築時に問題が露見するでしょう。 Debian 公式のカーネルパッケージでは、セキュリティフィックスやバグ修正など問題解決のためコンフィグを変更する必要があり、 それに伴い ABI が変わるケースがあります。
    ABI 変更に伴う影響よりも問題を放置することのほうがより影響がある場合は、苦肉の策として ABI (即ちパッケージ名) を変更し、 エンドユーザが誤って自動的にアップグレードしないようにする、という方針をとっています。
    ABI 破壊の危険性を避けたいユーザは表記した実パッケージ linux-image-2.6.x-ABI-SUBARCH を インストールすべきです。しかし、この様な場合、ABI 変更時には新しいカーネルが自動的にはインストールされず、 セキュリティフィックスの恩恵を受けられない可能性があります。 最新のパッケージを追従し続けたいユーザは以下のメタパッケージをインストールすればよいでしょう。
  • ABI について説明しましたが、2010 年現在、シンボルの変更は多少ありますが、 システムコールレベルでの大幅な変更でもない限り影響は小さいため ABI は変更しないそうです。
  • パッケージ名の x より後ろの部分はいわゆる変数 EXTRAVERSION です。 通常カーネルのファイル名は /boot/vmlinuz-2.6.x ですが、EXTRAVERSION はカーネルのファイル名に追記する文字列で、 これがセットされるとカーネル本体は /boot/vmlinuz-2.6.xEXTRAVERSION となります。
    即ち公式のカーネルパッケージは /boot/vmlinuz-2.6.x-ABI-SUBARCH となります。
  • linux-image-2.6.x-ABI-SUBARCH-dbg: デバッグシンボル付きカーネルイメージです。 /usr/lib/debug/ 以下にインストールされます。 カーネルハッキング (gdb 利用) 等で利用します。 通常のカーネルよりはサイズが肥大化しており、ログ出力される情報は多くなっています。
  • linux-headers-2.6.x-ABI-SUBARCH: カーネルヘッダー。
    カーネルイメージと同じく各アーキテクチャ内のサブアーキテクチャ毎にパッケージが作成されます。
    シンボルテーブル (Module.symvers)、.config も含まれます。
    通常はカーネルソースツリーに含まれていない外部カーネルモジュールの構築時に フルビルド済みカーネルソースのターゲットに代わるものとして利用されます。
    module-assistant が使用する /usr/src/linux へのリンクはこのパッケージに含まれる /usr/src/linux-headers-2.6.x-ABI-SUBARCH ディレクトリとするのが適切です。
  • linux-headers-2.6.x-ABI-all-ARCH は アーキテクチャ全てのヘッダーパッケージに依存するメタパッケージです。
  • linux-headers-2.6.x-ABI-all は 全アーキテクチャのヘッダーパッケージに依存するメタパッケージです。
  • linux-headers-2.6.x-ABI-common はアーキテクチャ内における共通ヘッダーを分離したパッケージで、 サブアーキテクチャのヘッダーパッケージはすべてこのパッケージに依存しています。
    /usr/src/linux-headers-2.6.x-ABI-common ディレクトリには ビルドに使用したカーネルソースの Makefile が置かれています。
    • linux-image の項で EXTRAVERSION と -ABI-SUBARCH の関係について述べました。 しかし、この Makefile の EXTRAVERSION は -ABI-SUBARCHセットされているとは限らないので注意して下さい。
      外部カーネルモジュール構築時には linux-headers-2.6.x-ABI-SUBARCH パッケージに含まれる Makefile を呼び出すようにしてください。これを呼び出すと適切な外部カーネルモジュールが生成されます。
  • カーネルヘッダーパッケージには modpost, genksyms など外部カーネルモジュール生成ユーティリティは含まれていません。
    従ってカーネルヘッダーパッケージだけでは外部カーネルモジュールを構築することはできません。
    実際にそれらのツールを含んだ linux-kbuild-2.6.x パッケージに依存しています。
    この linux-kbuild-2.6.x パッケージは linux-2.6 ソースパッケージからは生成されません。
    experimental 等ではこのパッケージが無いことがあり、外部カーネルモジュールを作成したい際に ターゲットのカーネルヘッダーパッケージに対する linux-kbuild-2.6.x パッケージを自前でビルドする必要があるかもしれません。
  • linux-libc-dev: カーネルヘッダーから不必要な情報を削除し再生成したユーザスペースヘッダー。 lenny から登場したパッケージです。 linux-2.6 ソースパッケージがビルドされる度に生成されます。
    このパッケージに含まれるヘッダーはライブラリを経由せずカーネルを直接叩こうとする場合に使用されますが、 直接使用することはまれで、通常は (e)glibc のユーザ空間ヘッダーから自動的に呼び出されるようになっています。 従って、libc6-dev は常にこのパッケージに依存しています。
    2.6.23 以前 は glibc の API を破壊する恐れがあるためこのようなパッケージはありませんでしたが、 現在では上流カーネルソースでサポートされている標準的なパッケージです。
  • 余談。etch 以前は linux-kernel-headers というパッケージで同様の機能が提供されていたが、これはある特定のバージョンのカーネルのヘッダーを抜き出し、 glibc が正常に動作するようバックポート (当然全アーキテクチャで) し続けたという曰く付きのパッケージである。 (その辺の昔話はこのあたりを参照。)
  • linux-manual-2.6.x: Section 9 マニュアル (カーネル内関数、インターフェースに関するマニュアル) です。
  • linux-patch-debian-2.6.x: 上流ソースとの差分 (パッチ) パッケージです。 これは kernel.org で配布されている上流カーネルソース (vanilla kernel や Linus' kernel tree など。linux-source パッケージではありません) を対象としたパッケージで通常は不要です。
  • linux-source-2.6.x: ビルドに使用したソースコードはこのパッケージです。 make-kpkg コマンド (kernel-package) でのビルドにはこのソースを使用することが多いと思われます。
    このソースには linux-patch-debian-2.6.x パッケージの全てのパッチが適用された状態でアーカイブされています。
  • linux-support-2.6.x-ABI: ABI 情報を検出するユーティリティです。パッケージメンテナ向けだと思われます。
  • linux-tools-2.6.x: 性能解析ツール perf を含むパッケージです。

linux-kbuild-2.6 ソースパッケージ

linux-kbuild-2.6 ソースパッケージ (バージョン 2.6.x)。
中身は linux-2.6 ソースパッケージから一部を抜き出したものだが、 最大の違いはこのソースパッケージは上流ソース linux-2.6.x の x の部分、SUBLEVEL が更新された際にのみビルドされる という取り扱いになっていることです。
従って重要なパッケージであるにもかかわらず、linux-kbuild-2.6.x バイナリパッケージが存在しない場合もあります。
とりわけ experimental では必要ならば自前でビルドしろというスタンスのようです。

linux-kbuild-2.6.x: Linux Kernel Kbuild インフラストラクチャ (scripts/)。
カーネルのシンボル解決用ユーティリティ genksyms, modpost も含まれるので、外部カーネルモジュール構築時に必須となります。
通常はカーネルヘッダーパッケージと同時にインストールされます。
ソースパッケージの項で説明した通り、このパッケージは linux-2.6 ソースからはビルドされず、 パッケージが存在しない場合もあります。
自前でビルドする方法もあります。

メタパッケージ

パッケージ作成時点での最新の実パッケージに依存しています。 パッケージの自動アップグレードには有用です。

linux-latest-2.6 ソースパッケージ

以下のパッケージは linux-latest-2.6 ソースパッケージから生成されるバイナリパッケージです。

ファームウェア

直接カーネルとは関係ありませんが関連するパッケージにファームウェアパッケージがあります。
firmware-linux-free のみ linux-2.6 ソースパッケージから生成されます。

その他

  • firmware-linux-nonfree

等があります。

firmware 等の用語で検索してみてください。

1. 必要なファイルのインストール

カーネルコンパイル並びにパッケージ作成のための開発ツールをインストールします。
fakeroot は root 権限を使わずにカーネルの再構築をすることができる為インストールを推奨します。
build-essential は gcc, binutils, libc-dev, make, dpkg-dev をインストールします。
バージョン 2.6.23-rc1 以上のカーネルでは、 lguest (x86 用の準仮想化ツール) がビルドされるため、libc-dev (libc6-dev。依存する linux-libc-dev パッケージも) が必要となります。 2.6.23-rc12.6.34-rc1 までは zlib1g-dev も必要です。 インストールしないとカーネルパッケージ構築中にビルドエラーが起きます。
cpio はカーネルヘッダーパッケージを作成する場合に必要です。

# aptitude install build-essential zlib1g-dev cpio kernel-package fakeroot

カーネルソースの入ったパッケージをインストールします。 パッケージ名は linux-source-2.6.x です。linux-source-2.6 メタパッケージをインストールしておくと x のリビジョンが上がった場合、 アップデートに追従できるので便利です。

Debian アーカイブに収録されているカーネルソースよりも更に新しいカーネルを必要とする場合は、 適宜 kernel.org から取得して下さい。
(当然 Debian 固有のパッチは含まれていませんので、適宜適用して下さい。)

以下の手順は Debian のソースでも kernel.org の上流ソースでも無関係に構築できます

ソースパッケージをインストールした場合、 ソースファイルは /usr/src/ に圧縮されたファイル (linux-source-(バージョン).tar.bz2) として置かれています。 適当なディレクトリに展開します。

$ tar xvfj /usr/src/linux-source-(バージョン).tar.bz2 /foo/bar/

展開したディレクトリに linux-source-(バージョン) というディレクトリが作成されるので、そこに移動します。
一度カーネルの設定やビルドしたことがあるならば、 問題が発生するのを防ぐため中間ファイルをすべて削除する make mrproper を実行します。

$ cd /foo/bar/linux-source-(バージョン)
$ make mrproper

2. カーネルの設定

ゼロから設定するのではなく、既にインストールされているカーネルの設定を引き継ぎたい場合には、 設定ファイルを .config としてソースディレクトリにコピーしておきます。

$ cp /boot/config-(インストール済バージョン) ./.config

その後、現在のカーネル用に設定ファイルを変換します。

$ make oldconfig

ただし、対象となるカーネルのコンフィグのバージョンがあまりにも離れている場合は設定が正確に引き継がれるとは限りません。 2.4 系のコンフィグを用いて 2.6 系に設定を引き継ごうとしてもうまくいきません。

カーネルの設定は make-kpkg configure で行います。

$ make-kpkg --append_to_version (文字列) --revision (リビジョンナンバー)  --config {menuconfig | xconfig | gconfig | config | oldconfig}  configure
  • --config オブションを指定することで設定時のユーザーインターフェースを変更できます。 このオプションを指定しないとデフォルトの (old)config が選択されます。
    • config は最もシンプルなコンフィグターゲットですが、すべての設定項目を1から順番に行う為、操作性は悪くなります。 しかし、他のライブラリ・開発ツールに依存していないため、端末アクセスさえ可能ならば実行できます。
    • menuconfig, nconfig は ncurses ベースのエディタです。こちらは libncurses-dev が必要です。
    • xconfig は Qt ベース (v2.6) のエディタです。こちらは libqt3-mt-dev が必要です。 2.6.37-rc1 からは libqt4-dev がインストールされていればそちらを、インストールされていなければ libqt3-mt-dev を使おうとします。
    • gconfig (v2.6) は GTK+ ベースのエディタです。こちらは libglade2-dev が必要です。
    • oldconfig は上述したとおり、既存の設定ファイルとビルドするカーネルソースの差分を検出し、設定するよう促します。
    • その他のコンフィグターゲットについては、以下のコマンドを実行して表示される、Configuration targets を参照。
      $ make help | pager

上述のとおりデフォルトのコンフィグターゲットは "config" または "oldconfig" ですが、

~/.kernel-pkg.conf (または /etc/kernel-pkg.conf) に次の項目を記載するとデフォルトのコンフィグターゲットを変更できます。
例えばデフォルトを "xconfig" にする場合、

config_target := xconfig

と書きます。

  • --append_to_version (--append-to-version) オプションをつけると、ソースのトップディレクトリの Makefile に書かれている EXTRAVERSION に追記できます。 これによりカーネルファイルは /boot/vmlinuz-(バージョン)(EXTRAVERSION) となるので、 同じバージョンのカーネルが既にある場合、ファイルの上書きを回避できます。
  • --revision オプションをつけると、パッケージにバージョンナンバーを付けることが出来ます。

    --revision を指定しない場合には 10.00.Custom になります。
    以下

--append_to_version -foo

--revision hoge

とします。出来上がる

カーネルは /boot/vmlinuz-(バージョン)-foo

パッケージは linux-image-(バージョン)-foo_hoge_i386.deb

となります。

2.1 設定の注意

2.1.1 外部カーネルモジュールについて
カーネルソースにも含まれているカーネルモジュール、 例えば pcmcia や 2.6 系での alsa を外部カーネルモジュールとして別途構築する場合は、 カーネル側の pcmcia や alsa を無効 (N) にしておく必要があります。

2.1.2 システム起動に必要な設定について
initramfs 等初期 (RAM) ディスク (初期ルートファイルシステム) を使用しない場合は、 システムの起動時に必要なものは モジュール (M) ではなく、組み込み (Y) にして下さい。
例えばルートファイルシステムが存在するディスクのドライバ

  • CONFIG_IDE (IDE 接続の HDD), CONFIG_BLK_DEV_IDEDISK および使用している IDE chipset support に対応するドライバ(CONFIG_BLK_DEV_PIIX 等)
    • CONFIG_ATA (* 注意) と関連するディスクドライバ
  • CONFIG_SCSI (SCSI 接続の HDD),および使用している SCSI ドライバ等

ルートファイルシステム

  • CONFIG_EXT3_FS (ext3 ファイルシステム)
  • CONFIG_EXT4_FS (ext4 ファイルシステム)
  • CONFIG_REISERFS_FS (reiserfs ファイルシステム)
  • CONFIG_JFS_FS (JFS ファイルシステム)
  • CONFIG_XFS_FS (XFS ファイルシステム)
  • CONFIG_NFS_FS (NFS ファイルシステム)

など。 これらをモジュールにした場合、 初期RAMディスク生成ツール を利用しないと起動できなくなります。
公式のパッケージはかなりモジュール化されているため、.config を流用するのは問題ないですが、 --initrd オプションを付け忘れて構築すると起動できなくなります。

initramfs を使用する場合の手順は後記

2.1.3 各 CPU の最適化

各 CPU の最適化等に関する設定は以下の項目です。

Processor type and features --->

Processor family --->

3. カーネルパッケージの構築

カーネルの設定が終わったらパッケージを構築します。

3.1 initramfs を使用しない場合

以下のコマンドを実行してください。構築にはしばらく時間がかかります。

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge kernel_image

3.2 initramfs を使用する場合

initramfs-tools をインストールします。(etch 以降ではデフォルトで initramfs-tools がインストールされています。)
その他のツールを選択したい場合は、 linux-initramfs-tool 仮想パッケージから適宜選んでインストールして下さい。
ツールの特徴・相違点については、 InitrdReplacementOptions - Debian Wiki を参照して下さい。
動作環境について言えば、initramfs-tools は klibc + sh、 yaird は perl で動作する点に違いがあります。

  • yairdはBTS:626688により削除されたため、wheezy以降では利用できないことに注意しておいて下さい。

続いて .config に

CONFIG_BLK_DEV_INITRD=y

(Initial RAM filesystem and RAM disk (initramfs/initrd) support)

があることを確認します。確認できたら make-kpkg を --initrd オプション付きで実行します。

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd kernel_image

このオプションをつけても作成されたカーネルパッケージに initrd.img 等が含まれていないので不審に感じるかもしれませんが、 (cf. dpkg -L linux-image-x.y.z または dpkg --contents linux-image-*.deb しても initrd* という文字列はないはず) カーネルパッケージに含まれるインストールスクリプト (postinst など) には ちゃんと update-initramfs -c (initramfs を生成するツール) を実行するよう指示されているはずです。

  • kernel-package バージョン 12.012 と initramfs-tools >= 0.55 からは初期 RAM ディスク生成処理は kernel-package の役目ではなくなり、 各初期 RAM ディスク生成ツールの役目となっています。--initrd オプションを付けると、 カーネルイメージパッケージの postinst (postrm) スクリプトに
    my $initrd             = "YES";
    というフラグが指定され、 このフラグがあると postinst スクリプトから /etc/kernel/postinst.d/initramfs-tools (initramfs-tools に含まれるファイル) が呼ばれ、 実際の生成処理に移ります。

正常に終了した場合はカレントディレクトリの一つ上 (../) に linux-image-(バージョン)-foo_hoge_i386.deb ファイルが生成されます。

3.3 その他のパッケージも作成する場合

3.3.1 ドキュメント・ヘッダー・デバッグパッケージ
buildpackage ターゲットで実行すると、dpkg-buildpackage コマンドを使い linux-image パッケージを含め以下のパッケージもビルドされます。

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd --uc --us buildpackage
  • linux-doc: Documentation 以下のドキュメントのパッケージ。
    • 構築時に docbook-utils がインストールされている場合は HTML ドキュメントも作成されます。 docbook-utils が未インストールの場合生成されません。
  • linux-manual: Section 9 マニュアル(カーネル内関数、インターフェースに関するマニュアル)。 ただし、ビルド時に docbook-utils がインストールされている必要があります。docbook-utils が未インストールの場合構築されません。
  • linux-headers: カーネルヘッダー。外部カーネルモジュールのビルド時、フルビルド済みのカーネルソースがない場合に使用します。
  • linux-image-*-dbg: デバッグシンボル付きカーネルイメージ。
  • linux-source: ソースパッケージ。ビルドに使用したソースをパッケージングします。

linux-doc, linux-headers, linux-image, linux-source パッケージはそれぞれターゲットでもあり、個別のパッケージのみ欲しい場合はそれぞれのターゲットで置き換えます。
linux-doc パッケージのみ必要な場合、

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge linux-doc
  • 注意: 上記パッケージの中には Debian アーカイブにある公式パッケージ (apt で引っ張ってこれるという意味です) と 同じ名前のパッケージがありますが、互換性はありません。 例えば、linux-headers パッケージは make-kpkg で作成すると、 それ単独でフルビルド済みカーネルソースと同じ役割をしますが、公式の linux-headers はそうではありません。

3.3.2 モジュールパッケージの同時構築
カーネルパッケージ構築と外部カーネルモジュールパッケージも同時に構築する場合は modules ターゲットを併用してください。
例: ALSA:
alsa-source パッケージをインストールした後、

$ cd /usr/src
$ tar -xjpf alsa-driver.tar.bz2

/usr/src/modules 以下にソースが展開されていることを確認し、カーネルソースディレクトリで、

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd --uc --us buildpackage modules

モジュールソースを展開したディレクトリが /usr/src ではない場合は、環境変数 MODULE_LOC に該当ディレクトリを指定してください。

$ MODULE_LOC=/hoge make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd --uc --us buildpackage modules

カーネルパッケージを構築した後に、モジュールパッケージのみ構築したい場合は以下を実行します。

$ make-kpkg --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd --uc --us modules

3.4 その他

その他、指定できるターゲットは、カーネルソースディレクトリに入ったのちに、以下のコマンドで見れます。

$ make-kpkg --targets

4. 構築したカーネルパッケージのインストール

# dpkg -i ../linux-image-(バージョン)-foo_hoge_i386.deb
  • インストールした後は必ず LILO や GRUB などのブートローダの設定を確認しましょう。
  • --initrd オプションで作成した場合は /boot/initrd.img-(バージョン) ファイルが存在することを確認して下さい。

  • GRUB (Legacy, 2 双方) の場合は update-grub を利用するとカーネル更新を自動で認識してくれます。 またカーネルパッケージインストール後自動で update-grub させる方法もあります。 (Software/LinuxKernel#update_grub)
  • IDE ドライバ (CONFIG_IDE) から libata (CONFIG_ATA) に移行した場合、 デバイスファイルが変更される (/dev/hda が /dev/sda となる) ことによりルートファイルシステムがマウントできなくなるので、 注意すること。(対処法は下記)

問題ない事を確認した上、新しいカーネルで起動し直しましょう。

5. 各種設定

様々なオプション、指定できる環境変数、make-kpkg のターゲット、設定ファイル kernel-img.conf, kernel-pkg.conf へのポインタが

  • man make-kpkg
  • /usr/share/kernel-package/rules

に、また、make-kpkg のデフォルト設定を変更する為の設定ファイル [/etc/|$HOME/.]kernel-pkg.conf についての説明は、

  • man kernel-pkg.conf

カーネルパッケージインストール後の処理 (ブートローダの設定ファイル更新、/vmlinuz, /initrd.img ファイルのリンク) の挙動変更については、

  • man kernel-img.conf

に載っています。

例:

  • make-kpkg に オプション --jobs 2 または環境変数 CONCURRENCY_LEVEL=2 を指定しておくと、make -j2 で CPU を 2 つ使ってコンパイルしてくれます。 数字は CPU 数より +1 か +2 (多くても2倍以下) にすると効率が良いでしょう。
  • distcc を起動しているホストがある場合は、 同様に --jobs (数字) オプションを追加することで分散コンパイルが可能となります。 全ジョブ数よりも +1 もしくは +2 (多くても2倍以下) にした数字で実行すると効率がよいでしょう。
    $ export DISTCC_HOSTS="127.0.0.1/3 192.168.0.3/3 192.168.0.4/2"
    $ CC=distcc make-kpkg --jobs 16 --rootcmd fakeroot --append_to_version -foo --revision hoge --initrd --uc --us buildpackage
    (DISTCC_HOSTS の順番はパフォーマンスの高いマシンの順番で記述、各 IP アドレスの / の後ろはそのホストで実行するジョブ数 (make -j)。詳細は distcc(1) 参照。)
  • [/etc/|$HOME/.]kernel-pkg.conf に config_target := xconfig と書くとコンフィグターゲットのデフォルトを変更できます。
  • [/etc/|$HOME/.]kernel-pkg.conf に root_cmd := fakeroot と書くと自動で fakeroot を使ってビルドしてくれます。
  • 以下のコマンドを実行すると、パッケージの debian/control ファイルに記載されるユーザ名、Email アドレスを変更できます。
    # kernel-packageconfig

User Mode Linux 用カーネルパッケージをビルドする

以下のような感じで --arch um をオプションに加える。

$ make-kpkg --arch um --append_to_version -foo --revision hoge --config {xconfig | menuconfig | config | oldconfig} configure
$ make-kpkg --rootcmd fakeroot --arch um --append_to_version -foo --revision hoge --initrd linux-image

カーネルパッケージをクロスビルドしたい

以下のような感じで --arch (ターゲットのアーキテクチャ) --cross_compile (クロスコンパイラバイナリのプレフィックス) をオプションに加える。
クロスコンパイル環境を事前に構築しておくこと。

$ make-kpkg --arch (ターゲットのアーキテクチャ) --cross_compile (クロスコンパイラバイナリのプレフィックス) --append_to_version -foo --revision hoge --config {xconfig | menuconfig | config | oldconfig} configure

$ make-kpkg --rootcmd fakeroot --arch (ターゲットのアーキテクチャ) --cross_compile (クロスコンパイラバイナリのプレフィックス) --append_to_version -foo --revision hoge --initrd linux-image

例:

$ make-kpkg --arch arm --cross_compile arm-linux-gnueabi --append_to_version -foo --revision hoge --config {xconfig | menuconfig | config | oldconfig} configure
$ make-kpkg --rootcmd fakeroot --arch arm --cross_compile arm-linux-gnueabi --append_to_version -foo --revision hoge --initrd linux-image

i386 (32bit) ユーザーランド上で amd64 (64bit版) カーネルパッケージをビルドしたい

以下のような感じで、 amd64 をターゲットとしたクロスビルドをするが、 その際にクロスコンパイラのプレフィックスにダミーターゲットの - を指定する。 (--cross_compile -)

$ make-kpkg --arch amd64 --cross_compile - --append_to_version -foo --revision hoge --config {menuconfig | config | oldconfig} configure
$ make-kpkg --rootcmd fakeroot --arch amd64 --cross_compile - --append_to_version -foo --revision hoge --initrd linux-image

※ xconfig は 64bit 版の qt ライブラリが無いために動かない。 menuconfig には lib64ncurses5-dev が必要。

トラブル

make-kpkg で正常にビルドできない

コンパイル時のエラーの場合、.config を再検討したり、 関連する Documentation/ 以下のファイルを読んで必要な条件を満たしているか確認しましょう。
それでも解決できない場合はカーネルのバグ (ビルドエラー) の可能性があるので、 調査の上必要ならば適切な提供元 (linux-source ならば BTS、kernel.org のソースならば LKML) のバグ報告をチェックしたり、新規のバグだと思われる場合は報告しましょう。

(ビルド自体を進めるにはコンフィグで無効にすればよいでしょう。)

make に由来するエラーの場合は原因は色々あります。
まずは、ツール等が正常にインストールされており、設定も適切で、PATH が通っていることを確認しましょう。
BTS や LKML、http://bugzilla.kernel.org/ もチェックして下さい。
もうほかにチェックすることがないと確信できる場合、
上流の変更に kernel-package が追いついていないと言うケースがあります。

とりわけ stable の kernel-package で 最新のカーネルをビルドする場合は起こり得ます。
最新の kernel-package を unstable から借用すればよいですが、stable リリースのカーネルよりも新しいカーネルが正常に動作する保証はありません。 (util-linux, udev, module-init-tools, *fsprogs その他のユーザランドツールが古いなど使用する上で様々な問題があるため。)
新しいカーネルを使いたい場合は諦めて stable-backport または testing (場合によっては unstable) の使用を検討してください。
security.debian.org が apt-line に存在する場合は stable カーネルに対するセキュリティフィックスがすぐさま反映されるので、 セキュリティの問題でアップグレードを検討する必要はありません。

(あくまで私見だが、そもそも stable リリースでサポートされているカーネルは 公式のインストーラで使用されているカーネルのバージョンのみではないかと思われます。 おそらく、stable の kernel-package に対し、「上述の件」に関して BTS にバグとして報告しても CLOSE されるかもしれません。)

make xconfig (menuconfig, gconfig) が動かない

追加パッケージが必要です。こちらを参照してください。

make menuconfig 時にエラーメッセージが出た

Your display is too small to run Menuconfig!
It must be at least 19 lines by 80 columns.
make[1]: *** [menuconfig] エラー 1

メッセージの通り、端末の画面の大きさを 80x19 以上に設定して下さい。

構築時に lguest のビルドでエラーが出た

lguest.c:16: error: sys/mman.h: No such file or directory.

lguest.c:37:18: error: zlib.h: No such file or directory. (2.6.23-rc12.6.34-rc1 のみ)

メッセージの通り、ユーザランドヘッダがないのでインストールする。

# aptitude install libc-dev linux-libc-dev zlib1g-dev

Debian ソースパッケージの debian ディレクトリを利用する方法

参照:

要するに、通常のパッケージ構築と同じくソーストップディレクトリに debian/ を用意し、 dpkg-buildpackage を実行してやるわけです。

2010年 11 月現在この方法を用いると、

  • ビルド中に ccache を利用できます。(環境変数または dpkg-buildpackage に DEBIAN_KERNEL_USE_CCACHE=true を渡す)
  • debuild + lintian が使えます。
  • debian/changelog が変更可能になるので、上流ソースからの変更を記述したりして、変更の把握が容易になります。
  • プロセスの同時実行数は DEBIAN_KERNEL_JOBS= で指定可。
  • 公式と同じく linux-base, linux-libc-dev, linux-tools, linux-support, firmware-linux-free (ただし中身は本当に free とは限らない、firmware-linux-nonfree とも衝突の危険性あり) パッケージも作成されます。perf コマンドは現時点では make-kpkg では作成されません。
  • xen, openvz,vserver 等仮想化機能を有効化したカーネルも同時にビルドできます。(make-kpkg は現時点では作成不可能)

ただし、注意点もあり、

  • 以下に記載の通り、ビルドに手間が掛かる上、問題解決の為にスクリプト (sh/Makefile/python) をチェックする必要が出てきます。
  • make-kpkg コマンドの --config の様な手段はないので、事前に make *config をして .config を生成しておき、 debian/config 内の適切なディレクトリに放り込む必要があります。
  • make-kpkg コマンドとは異なり、ビルドディレクトリがソースのトップディレクトリではなく、debian/build ディレクトリを掘って そこに *.{k,}o や自動生成ヘッダーを溜め込む、というソース・ビルドディレクトリの分離を図っている為、 外部カーネルモジュールの再構築にはビルド済みソースが直接使用できません。 従ってカーネルヘッダーが必要ですが linux-kbuild-2.6.x パッケージがない場合はこれもビルドする必要があり、 ビルドの手間が増えます。
  • lguest はビルドされないので、適宜 Lguest userland tool in Debian に添付されているスクリプトを利用してください。
  • debian/ は常時更新されているので、手順が変化したり、そもそも本項目が常に正しいとは限りません...

手順例:

1. linux-2.6 ソースパッケージのビルド

1.各種ユーティリティをインストール

# aptitude install build-essential fakeroot debhelper devscripts
# aptitude install  svn git
# aptitude install  cpio rsync ccache

2. linux-2.6 ソースパッケージの構築依存パッケージをインストール

# apt-get build-dep linux-2.6

または apt-line に experimental を追加し

# apt-get -t experimental build-dep linux-2.6

3. カーネルソースを取得 (linux-source, kernel.org 由来ソース、パッチ適用済みソースなどカーネルソースならば何でもよい。)
"バージョン"は EXTRAVERSION も含めたカーネルバージョンを示す。但し、-rcN は ~rcN としないといけない。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd ./linux-2.6 && git archive --format=tar --prefix=linux-2.6-(バージョン)/ HEAD > \
 ../linux-2.6-(バージョン).tar # このファイルは linux-kbuild-2.6 パッケージビルド時に再利用する。
$ cd ..
$ tar -xpf linux-2.6-(バージョン).tar
$ cp -ar linux-2.6-(バージョン) linux-2.6-(バージョン).orig

4. svn.debian.org から debian/ ディレクトリを取得し、カーネルソース内にエクスポート

$ svn checkout svn://svn.debian.org/kernel/dists/trunk/linux-2.6/debian debian-tree
$ cd ./debian-tree && svn export . ../linux-2.6-(バージョン)/debian
$ cd ../linux-2.6-(バージョン)

5. 必須パッチを適用、その他使用するパッチもこの時点で適用

$ patch -p1 -s < ./debian/patches/debian/doc-build-parallel.patch # and patch *.rej manually.
$ patch -p1 -s < ./debian/patches/features/all/Kbuild-kconfig-Verbose-version-of-listnewconfig.patch # and patch *.rej manually.
$ patch -p1 -s < ./debian/patches/debian/scripts-kconfig-reportoldconfig.patch # and patch *.rej manually.
$ patch -p1 -s < ./debian/patches/debian/version.patch # and patch *.rej manually.

6. debian/config/ 以下の defines ファイルを適宜編集し、不要な項目を削除し、config ファイルを自ら生成したもので置換。
適切に削除しないと control ファイル生成時やビルド時にエラーが起きるので試行錯誤が必要...
(python スクリプトが理解できない...等の理由で) よく分からないときは config の置換以外は敢えて編集する必要もない。
しかし、パッケージが大量に生成され (10数GB) ディスクが溢れる可能性があるので覚悟すること。

例:

i386アーキテクチャ用のカーネルの場合、下記のファイルを除いて debian/config 以下を全て削除

debian/config/defines

内容:

[abi]
abiname:

[base]
arches:
 i386
compiler: gcc-4.4
featuresets:
 none

[image]
initramfs-generators: initramfs-tools initramfs-fallback
type: plain

[commands-image-initramfs-generators]
initramfs-tools: update-initramfs

[relations]
gcc-4.4: gcc-4.4
initramfs-fallback: linux-initramfs-tool
initramfs-tools: initramfs-tools (>= 0.55)

debian/config/i386/defines

内容:

[base]
featuresets:
flavours:
 custom
kernel-arch: x86

[image]
configs:
 kernelarch-x86/config
suggests: grub | lilo

[custom_description]
hardware: Custom PCs
hardware-long: Custom PCs

[custom_image]
configs:
 kernelarch-x86/config-arch-32
recommends: libc6-i686

[custom_image-dbg]
enabled: true

デバッグパッケージが不要な場合は、

[custom_image-dbg]
enabled: false

とする。

以下空のダミーファイルを作成

debian/config/config

debian/config/kernelarch-x86/config

debian/config/kernelarch-x86/config-arch-32

make oldconfig 等で作成した .config を以下の名前のファイルでコピー

debian/config/i386/none/config.custom

ビルド完了後、生成されるパッケージは、 linux-image-(メジャーバージョン)(-ABI)-custom_(メジャーバージョン)(~rcN)-(Debian リビジョン)_i386.deb となる。

7. debian/patches 以下を全て削除し、空のダミーファイル (ファイル名は任意) を作成

$ rm -rf ./debian/patches/*
$ touch ./debian/dummy

8. debian/changelog を適切なバージョンに修正

$ dch -i

9. debian/rules clean を一度起動して debian/control ファイルを自動生成させる。 (エラーが出る場合は、debian/config, debian/changelog, ディレクトリ名を要チェック。成功するまで修正と clean を行う。)

$ fakeroot make -f ./debian/rules clean

10. ビルド開始 && パッケージインストール

$ debuild --set-envvar=DEBIAN_KERNEL_USE_CCACHE=true --set-envvar=DEBIAN_KERNEL_JOBS=4 \
               --prepend-path=/usr/lib/ccache --preserve-envvar=CCACHE_* -uc -us
$ cd ..
# dpkg -i *.deb

unstable 等の *.diff.gz から生成した debian/ を利用する場合は、debian/abi/* ファイルがあると ABI の変更を検知してビルドが停止するかもしれない。
もちろん ABI の互換性が無くなるということを示しているが、自分自身で「問題がない」と分かっている場合は、 debian/abi を削除すればよい。
(もし「分からない」のであれば、このカーネルソースを使用するのは避けた方がよい。)
debian/abi 以下のファイルは全カーネルパッケージのシンボルテーブル (Module.symvers) のコピー。

1.2 linux-kbuild-2.6 ソースパッケージのビルド

こちらの通りだが、 svn 取得後にこちらのパッチを適用する必要あり。

参考:
linux-kbuild-2.6.33 - vdrめも(2010-04-16)

Debian Wiki のコマンド例では kernel.org からソースを取得しているが、linux-source-2.6.x でも linux-2.6.x にリネームすれば (要するにカーネルソースならば何でも) 生成可能。 問題が発生するのを避けたければ毎回 linux-2.6 ソースパッケージをビルドしたら そのソースで linux-kbuild-2.6 ソースパッケージをビルドするのが無難であろう。

1. svn.debian.org から debian/ ディレクトリを取得し、エクスポート

$ svn checkout svn://svn.debian.org/kernel/dists/trunk/linux-kbuild-2.6 linux-kbuild-2.6-tree
$ cd ./linux-kbuild-2.6-tree && svn export . ../linux-kbuild-2.6
$ cd ../linux-kbuild-2.6-tree

2. 修正適用

$ wget http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30\;filename=linux-kbuild-2.6_2.6.33.diff\;att=1\;bug=573176 -O \
genorig.patch
$ patch -p1 < genorig.patch # and patch *.rej manually.
$ rm -f genorig.patch

3. バージョン修正

$ dch -i

4. 既存の linux-(メジャーバージョン).tar.{gz,bz2} から linux-kbuild-2.6-(メジャーバージョン).orig.tar.gz を生成
"メジャーバージョン" は -rc1 とか 2.6.35.yの"y" の部分 (EXTRAVERSION) を取り除いたバージョン。ターゲットのアーカイブ名、展開後のディレクトリ名を事前にリネームしておくこと。

$ ./debian/bin/genorig.py /path/to/linux-(メジャーバージョン).tar

5. orig.tar.gz を展開し orig.tar.gz をビルドディレクトリに移動

$ cd ..
$ tar -xzpf orig/linux-kbuild-2.6_(メジャーバージョン).orig.tar.gz
$ mv orig/linux-kbuild-2.6_(メジャーバージョン).orig.tar.gz .
$ cd linux-kbuild-2.6-(メジャーバージョン)

6. linux-kbuild-2.6/* を linux-kbuild-2.6-(メジャーバージョン) にコピー

$ mv ../linux-kbuild-2.6/* .
$ rmdir ../linux-kbuild-2.6

7. debian/rules clean を一度起動して debian/control ファイルを自動生成させる。 (エラーが出る場合は、debian/changelog, ディレクトリ名を要チェック。成功するまで修正と clean を行う。)

$ fakeroot make -f ./debian/rules clean

8. ビルド開始 && パッケージインストール

$ debuild --prepend-path=/usr/lib/ccache --preserve-envvar=CCACHE_* -uc -us
$ cd ..
# dpkg -i linux-kbuild-2.6*.deb

Debian のソース (linux-source-2.6.x) を使うとあるドライバがビルドできない、またファームウェアがない

DFSG に合致しないコードは Debian のソースには含まれていません。 一部は non-free で配布されていますが、全部ではありません。
どうしても使用したい場合は (ライセンス上の問題を抱えているという認識の下で) kernel.org のソースでビルドして下さい。

initrd の処理でエラーが発生する

  • kernel-package でビルドしたカーネルの場合 make-kpkg --initrd でパッケージを生成したか確認する。 このオプションがなければ initrd は不要なカーネルとみなされ、 ルートファイルシステムが読み込めない (ファイルシステムがモジュールの場合) など 起動時に Kernel Panic になる可能性が高くなる。 make-kpkg --initrd でビルド、パッケージインストール後にブートローダーで initrd が読み込まれる設定になっていることを確認し、 再起動する。
    もしくは推奨されないが、initrd のみ生成させるには、対象カーネルインストール後次を実行する。
    # update-initramfs -k (対象カーネルのバージョン) -u
  • カーネルイメージインストール時に初期 RAM ディスク生成ツールが無いと言われる場合は、 linux-initramfs-tool 仮想パッケージから いずれかをインストールする。 etch 以降は initramfs-tools がデフォルトでインストールされているはず。 sarge 以前の古いシステムで使用されていた initrd-tools パッケージがインストールされている場合は必ず削除する
  • initramfs が大きすぎると LILO ではブートできない場合があります。 この様な場合は、/etc/initramfs-tools/initramfs.conf の以下の行

    MODULES=most

    MODULES=dep

    とし、update-initramfs -u すると起動できるかもしれません。 most は initramfs-tools が必要となるカーネルモジュールをすべて掻き集め、initramfs に格納します。 dep は動作中の H/W にのみ必要なモジュールのみを initramfs に格納します。 参考: リリースノート - 第4章 以前のリリースからアップグレードする 4.1.5. LILO 用 initramfs の準備

画面が表示されない/キーボードが効かない

Input device support などの項目が新設されてるからチェックしてみれ。

ビープが鳴らなくなった

カーネル側で新しい項目が新設されてるから確認してみれ

CONFIG_PCSPKR_PLATFORM

CONFIG_INPUT_PCSPKR

逆にビープがウザい人は、CONFIG_INPUT_PCSPKR=n か
CONFIG_INPUT_PCSPKR=m して、 /etc/modprobe.d ディレクトリ以下に pcspkr-blacklist.conf という中身が以下のファイルを作成。

blacklist pcspkr

そして、

# update-initramfs -k (対象のカーネルバージョン、インストール済みカーネル全部なら all) -u

を実行する。



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2012-04-14 (土) 18:46:08 (1810d)