第524回ではメインラインビルドのバイナリパッケージのインストール方法を紹介しました。今回はメインラインカーネルをできるだけそのままビルドする方法を紹介します。

Ubuntuのカーネル事情

改めて言うまでもないことではありますが，UbuntuはLinuxディストリビューションの一つです。カーネルにLinuxカーネルを採用し，ツールチェインやユーザーランドにGNU製を始めとするさまざまなFLOSS（Free/Libre Open Source Software）を利用したシステムです。UbuntuのベースとなっているDebianにはカーネルにFreeBSDを採用した「Debian GNU/kFreeBSD」があるものの，基本的にLinuxディストリビューションと言えばカーネルにLinuxを採用しています（※1）⁠。

※1

2年前にはFreeBSDのカーネルを採用したubuntuBSDなるコミュニティによるプロジェクトが始まりましたが，2年前にアナウンスと同時にベータ版がリリースされて以降は動きがないようです。

さてカーネルはコンピューターシステムにおいてハードウェアとアプリケーションを仲立ちする存在です。つまりあるハードウェアがUbuntuで動くかどうかを調べる場合，カーネルがサポートしているかどうかがひとつの指標となります。もちろん第524回でも紹介したように，ハードウェアによってはカーネルだけでなく適切なファームウェアが必要だったり，ユーザーランド側も対応が必要だったりすることもあります。逆にカーネル側には汎用のドライバがあれば良く，ユーザーランド側で適切に処理するタイプのデバイスもあります。いずれにせよ，「⁠カーネルがどうなっているか」をまず確認することになるでしょう。

最新のハードウェアのサポートという観点から考えると，一般的にはより新しいカーネルが好ましいです。しかしながらLinuxディストリビューションとしてのQAを考えると，常に最新版を追いかけるのはなかなか難しいものがあります。そこでUbuntuでは，リリースごとに「サポートするカーネルのバージョン」を固定化し，それに対してUpstreamによるマイナーリリースの取り込み，より新しいカーネルバージョンからの修正パッチのバックポート，Ubuntu独自修正の追加などを行っています。

たとえばここ数回のリリースにおけるUbuntuのバージョンとカーネルのリリース日の比較は次のとおりです。

このようにUbuntuの場合は，リリース予定日の2ヶ月ぐらい前までの最新版が目安となります（※2）⁠。

※2

16.10だけ例外的ではありますが，その理由については不明です。少なくとも4.7がまだリリースされていない5月頭には，4.8を採用することが決まっていたので「LTSではないから直近でもいい」という判断が働いただけかもしれません。

通常のリリースは9ヶ月のサポート期間なので，次のリリースまでの半年でリリース3回分，EOLまで使ったとしてもリリース5回分ぐらいしか離れていません。それに対してLTSは次のリリースまで2年，最大でも5年の利用期間になるため，おおよそリリース12回分から30回分ぐらい同じバージョンのカーネルを使い続けることになります。

そこで導入されているのがHWE（Hardware Enablement）の仕組みです。ざっくり言うと通常リリースで採用したカーネルは9ヶ月メンテナンスするのだから，それを直前のLTSでもインストールできるようにしておこうという仕組みになります。特により新しいハードウェアにUbuntuをインストールするためにはインストーラーの時点で新しいカーネルになっている必要があるため，LTSのポイントリリースのインストーラーにおいては，HWEカーネルが採用されます（※3）⁠。

※3

言い換えるとLTSで5年メンテナンスされるカーネルを使いたい場合は，LTSの最初のインストーラーを使うか，ポイントリリースのインストーラーでインストールしたあとに，オリジナルのカーネルパッケージをインストールし直す必要があります。もしHWEカーネルを使い続ける場合は，そのHWEカーネルのサポートが切れるまでに，次のHWEカーネルに更新されることになるでしょう。

HWEカーネルについては，若干古い情報ではありますが本連載の第278回でも紹介していますので，そちらも参照してください。

Ubuntu用のカーネルをビルドする方法

さて，そうは言ってもUbuntuのカーネルバージョンでは都合が悪いことも多々あります。第524回のような新しいGPUに対応していないのは最たる例でしょう。既存のUbuntuでより新しいカーネルを使う方法はいくつか存在します。

1. より新しいUbuntuカーネルがリリースされるのをおとなしく待つ
2. Ubuntuカーネルにパッチを当ててビルドし直す
3. Ubuntuのメインラインビルドを使う
4. Upstreamのソースコードをそのままビルドする

カーネルに詳しいと言い切れない人に対しておすすめするのは1.の「おとなしく待つ」選択肢です。UbuntuはあくまでUbuntuの公式リポジトリから提供しているカーネル上での動作を想定しています。独自ビルドを使っていて不具合が発生したときに独自ビルドしたカーネルのせいなのかUbuntuカーネルでも起きるのかを切り分けるところから始めなくてはなりません。また，独自ビルドのカーネルを利用する場合は，自分で設定しない限りセキュアブートは使えません。

ただし本当に単に待つだけでは，自身が抱えている問題が解決されるかどうかは運頼みになります。個々の抱えている問題ごとに，修正されるために必要な情報をUbuntuのカーネルチームやUpstreamに提供したり，メーリングリストやチケットに書き込むなど，解決に向けてのできることはたくさんあるのです。これを機にUbuntu以外のLinuxディストリビューションを使うというのもひとつの手です。

2.は本来のUbuntuカーネルを少し改変することで修正される不具合の場合に有効です。特にUpstreamなどではパッチが存在し取り込まれている場合に使える手でしょう。UbuntuカーネルのソースコードはパッケージリポジトリやカーネルチームのGitリポジトリからダウンロードできます。詳しい手順は第333回で紹介していますので，そちらを参照してください。

Ubuntuのリリースカーネル以外のバージョンを使いたい場合は，3.がお手軽です。Ubuntuのカーネルチームは個々のカーネルリリースとmasterブランチをそれぞれ毎日ビルドし，そのバイナリパッケージを公開しています。特に遭遇している不具合が，どのバージョンから発生するようになったのか，2分探索（bisect）したい場合に有効です。詳しい使い方は第524回を参照してください。

最後の4.はUbuntuカーネルではなくUpstreamのカーネルをそのまま使う方法です。ただしカーネルコンフィグはUbuntuのそれを使うことも可能です。たとえば仮想マシンの上など，ユーザーランドがUbuntuではない環境でLinuxオリジナルのカーネル（Vanilla Kernel）をそのまま使いたいケースなどが相当します。ちなみにカーネルそのもの開発に携わっている場合などにも有効ではあると思いますが，そういう人は本記事を読まなくてもわかっていると思いますので対象外とします。

前フリが長くなってしまいましたが，今回はこの4.のケースについて説明します。