ハンドブック:パート/インストール/カーネルの設定

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Installation/Kernel and the translation is 89% complete.


警告
Handbook:Parts 名前空間 (このページのことです!) の手順に直接従うべきではありません。以下に表示されている文章は、コンピュータアーキテクチャごとのハンドブックに情報をトランスクルードするための骨格として使用されるもので、そのため重要な情報が抜けています

対象のコンピュータアーキテクチャ向けの手順を読むには、ハンドブックのリストを確認してください。
Parts ハンドブック
インストール
インストールについて
メディアの選択
ネットワーク設定
ディスクの準備
stage ファイル
ベースシステムのインストール
カーネルの設定
システムの設定
ツールのインストール
ブートローダの設定
締めくくり
Gentoo の操作
Portage について
USE フラグ
Portage の機能
Init スクリプトシステム
環境変数
Portage の操作
ファイルとディレクトリ
変数
ソフトウェアブランチの併用
追加ツール
カスタムパッケージリポジトリ
高度な機能
OpenRC ネットワーク設定
はじめに
高度な設定
モジュール式ネットワーク
無線
機能の追加
動的な管理


任意自由選択: ファームウェアとマイクロコードのインストール

ファームウェア

Linux ファームウェア

カーネルコンフィグの節へ進む前に知っておいたほうが良いこととして、一部のハードウェアデバイスは、それを適切に動作させるために追加の (時として FOSS ライセンスに準拠しない) ファームウェアをインストールする必要がある、ということがあります。これはデスクトップとラップトップの両方で広く見られる、無線ネットワークインターフェースで必要になることが多いです。AMD、Nvidia、Intel などのベンダによる最近のビデオチップも、完全に機能させるには外部のファームウェアが必要になることが多いです。最近のハードウェアデバイスのためのファームウェアの多くは sys-kernel/linux-firmware パッケージ内で見つかるかもしれません。

最初のシステムリブートの前に、もし必要だった場合にファームウェアを使えるようにしておくために、sys-kernel/linux-firmware パッケージをインストールしておくことが推奨されます:

root #emerge --ask sys-kernel/linux-firmware
メモ
一部のファームウェアパッケージのインストールには、関連するファームウェアライセンスを受諾する必要があることがよくあります。必要であれば、ライセンスの受諾についてはハンドブックのライセンスの取り扱いの節を確認してください。

モジュールとしてビルド (M) されたカーネルシンボルは、カーネルにロードされたときに、関連するファームウェアファイルをファイルシステムからロードすることに注意してください。モジュールとしてロードされるシンボルに関しては、デバイスのファームウェアファイルをカーネルのバイナリイメージに含める必要はありません。

Architecture specific firmware

メモ
Placeholder for architecture-specific firmware information

マイクロコード

個別のグラフィックスハードウェアやネットワークインターフェースに加えて、CPU もまたファームウェアアップデートを必要とすることがあります。こうしたファームウェアは典型的にはマイクロコードと呼ばれます。新しいリビジョンのマイクロコードは、動作の不安定さ、セキュリティ上の懸念、その他の CPU ハードウェアのさまざまなバグに対するパッチとして、必要になることがあります。

AMD CPU に対するマイクロコードアップデートは、先述の sys-kernel/linux-firmware パッケージとともに配布されます。Intel CPU に対するマイクロコードは sys-firmware/intel-microcode パッケージ内で見つかりますので、これを個別にインストールする必要があります。マイクロコードアップデートを適用する方法についてのさらなる情報は、マイクロコードの記事を確認してください。

カーネルのコンフィギュレーションとコンパイル

これで、カーネルソースを設定、コンパイルする準備が整いました。インストールの目的に応じてカーネルの管理のためのアプローチを 3 通り紹介しますが、インストール完了後はいつでも別のアプローチを採用し直すことができます。

簡単なものから込み入ったものへ、順に並べると:

完全自動アプローチ: ディストリビューションカーネル
ディストリビューションカーネルは、Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されている) initramfs ファイルを、設定、自動でビルド、インストールするために利用されます。将来のカーネル更新はパッケージマネージャを介して扱われるため、他のシステムパッケージとまったく同様に完全に自動で行われます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。これが最も簡単なプロセスで、すぐ動作するものが手に入りシステム管理者による関与を最小にできるため、新規の Gentoo ユーザには完璧です。
ハイブリッドアプローチ: Genkernel
新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。システム管理者は Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されていない) initramfs ファイルを、設定、ビルド、インストールするために Gentoo の genkernel ツールを使用することができます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。将来のカーネル設定、コンパイル、インストールには、アップデートのたびに eselect kernelgenkernel、およびもし必要であれば他のコマンドを実行する形で、システム管理者による関与が必要です。
完全手動アプローチ
新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。カーネルは eselect kernel と無数の make コマンドを利用して、手動で設定、ビルド、インストールされます。将来のカーネル更新はカーネルファイルの設定、ビルド、インストールの手動プロセスを繰り返して行います。これが最も込み入ったプロセスですが、カーネル更新プロセスに関して最大限の制御を行えます。

すべてのディストリビューションが構築されるその中心にあるのが Linux カーネルです。カーネルレイヤーはユーザのプログラムとハードウェアの間に存在します。ハンドブックではカーネルソースについていくつかの可能な選択肢を提供しますが、より詳しい説明付きで、より完全なカーネルソースのリストは、カーネルの概要のページで見ることができます。

ヒント
/boot または EFI システムパーティションへのカーネルイメージのコピー、initramfsUnified カーネルイメージの生成、ブートローダの設定の更新など、カーネルインストールのタスクは、installkernel で自動化することができます。先に進める前に、sys-kernel/installkernel をインストールして設定するとよいかもしれません。さらなる情報については下のカーネルインストールの節を参照してください。

ディストリビューションカーネル

ディストリビューションカーネルは、カーネルを展開、構成設定、コンパイル、インストールする完全なプロセスをカバーする ebuild です。この手法を利用する最大の利点は、@world アップグレードの一部として、パッケージマネージャによってカーネルが新しいバージョンに更新されることです。これは emerge コマンドを実行する以外にユーザの関与を必要としません。ディストリビューションカーネルはデフォルトでは、大部分のハードウェアをサポートするように構成されますが、カスタマイズするための 2 つの機構が提供されています: savedconfig とコンフィグスニペットです。設定についてのさらなる詳細はプロジェクトページを参照してください。

ディストリビューションカーネルをインストールする

カーネルパッケージをインストールする前に、/etc/portage/package.use 内でパッケージ sys-kernel/installkernel に対して dracut USE フラグを追加する必要があります:

ファイル /etc/portage/package.use/installkerneldracut サポートを有効化する
sys-kernel/installkernel dracut

この段階でさらに sys-kernel/installkernel の USE フラグを追加するのもよいでしょう。詳細については Installation/Kernel#Installkernel の節を参照してください。

Gentoo パッチが当てられたカーネルをソースからビルドするには、次をタイプしてください:

root #emerge --ask sys-kernel/gentoo-kernel

システムの管理者として、カーネルのソースをローカルでコンパイルするのを避けたい場合は、代わりにコンパイル済みのカーネルイメージを使用することができます:

root #emerge --ask sys-kernel/gentoo-kernel-bin
省略可能: 署名付きカーネルモジュール

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルモジュールは既に署名されています。ソースからビルドしたカーネルのモジュールに署名するためには、/etc/portage/make.confmodules-sign USE フラグを有効化し、署名のためにどの鍵を使用するかを任意で指定してください:

ファイル /etc/portage/make.confモジュールの署名を有効化する
USE="modules-sign"

# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です。

MODULES_SIGN_KEY が指定されない場合は、カーネルビルドシステムが鍵を生成し、鍵は /usr/src/linux-x.y.z/certs に保存されるでしょう。各カーネルリリースに対して同じ鍵が使用されることを確実にするためには、手動で鍵を生成することを推奨します。鍵は以下で生成することができます:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
メモ
MODULES_SIGN_KEYMODULES_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。

OpenSSL が鍵の生成についてのいくつか質問をしてくるでしょうが、できる限り詳細にこれらの質問に答えることを推奨します。

安全な場所に鍵を保存してください。最低限の措置として、鍵は root ユーザによる読み取りのみ可能にすべきです。このことを以下のようにして確認してください:

root #ls -l kernel_key.pem
 -r-------- 1 root root 3164 Jan  4 10:38 kernel_key.pem 

これが上と違ったものを出力する場合は、以下で権限を修正してください:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
省略可能: カーネルイメージに署名する (セキュアブート)

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルイメージは既にセキュアブート用に署名されています。ソースからビルドされたカーネルイメージに署名するには、/etc/portage/make.confsecureboot USE フラグを有効化し、署名のためにどの鍵を使用するかを任意で指定してください。セキュアブートとともに使用するためにカーネルイメージに署名するには、カーネルモジュールも署名する必要があることに注意してください。カーネルイメージとカーネルモジュールの両方に署名するために、同一の鍵を使用しても構いません:

ファイル /etc/portage/make.confカスタム署名鍵を有効化する
USE="modules-sign secureboot"

# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です。

# 任意で、セキュアブートを有効化してブートするために。署名鍵は同一でも別でも構いません。
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
メモ
SECUREBOOT_SIGN_KEYSECUREBOOT_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
メモ
この例では、カーネルイメージに署名するために、モジュールに署名するために生成されたのと同じ鍵が使用されています。カーネルイメージに署名するために、2 個目の別の鍵を生成して使用することも可能です。前節と同じ OpenSSL コマンドをもう一度使用することができます。

新しい鍵を生成する手順については上の節を参照してください。カーネルイメージを署名するために別の鍵を使用する場合は、同じ手順を繰り返すことができます。

セキュアブートを有効化して正しくブートさせるためには、使用するブートローダにも署名し、証明書が UEFI ファームウェアまたは Shim によって許可されなくてはなりません。これはハンドブック内で後で説明します。

アップグレードと後処理

一度カーネルがインストールされたら、パッケージマネージャが自動的にカーネルを新しいバージョンに更新するでしょう。古いバージョンは、パッケージマネージャに古いパッケージを片付けるように指示するまで残ります。ディスク容量を再利用するためには、定期的に --depclean オプション付きで emerge を実行することで、古いパッケージを片付けることができます:

root #emerge --depclean

あるいは、古いカーネルのバージョンだけを片付けるには:

root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin

インストール/アップグレード後タスク

ディストリビューションカーネルは、他のパッケージによってインストールされるカーネルモジュールの再ビルドに対応しています。linux-mod-r1.eclassdist-kernel USE フラグを提供し、これは virtual/dist-kernel に対するサブスロット依存関係を制御します。

sys-fs/zfssys-fs/zfs-kmod などのパッケージでこの USE フラグを有効化すると、パッケージが新しく更新されたカーネルに対して自動的に再ビルドされ、適用可能であれば、それに従って initramfs を再生成します。

手動で initramfs または Unified カーネルイメージを再ビルドする

必要であれば、カーネルアップグレード後に、以下を実行して手動で再ビルドを実行してください:

root #emerge --ask @module-rebuild

カーネルモジュール (ZFS 等) のうちいずれかが初期ブートで必要であれば、続けて次を利用して initramfs を再ビルドしてください:

root #emerge --config sys-kernel/gentoo-kernel
root #emerge --config sys-kernel/gentoo-kernel-bin

カーネルソースのインストール

メモ
この節の内容は、これ以降の部分で示す genkernel (ハイブリッド) アプローチか、マニュアルカーネル管理のアプローチを採用したときのみ関係があります。

sys-kernel/installkernel の使用は厳密には必須ではありませんが、強く推奨されます。このパッケージがインストールされるとき、カーネルのインストールプロセスが installkernel に委任されます。これにより、複数の異なるカーネルバージョンを併存させてインストールすることができ、後でハンドブック内で説明するカーネルインストールに関連する複数のタスクの管理と自動化も可能になります。以下でインストールしてください:

root #emerge --ask sys-kernel/installkernel

amd64 ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、Gentoo はsys-kernel/gentoo-sources パッケージを推奨しています。

適切なカーネルソースを選択して、emerge でインストールします:

root #emerge --ask sys-kernel/gentoo-sources

このコマンドはカーネルソースを /usr/src/ の下に、カーネルバージョン毎のパスを分けてインストールします。選択されたカーネルソースパッケージに対して symlink USE フラグが有効化されていなければ、シンボリックリンクは自動で作成されません。

現在実行しているカーネルに対応するソースを指すように、/usr/src/linux シンボリックリンクを維持することは慣例となっています。しかし、このシンボリックリンクはデフォルトでは作成されないでしょう。シンボリックリンクを作成する簡単な方法は、eselect の kernel モジュールを利用することです。

シンボリックリンクの目的と、それを管理する方法についてのさらなる情報は、Kernel/Upgrade を参照してください。

まず、インストールされているカーネルを一覧表示します:

root #eselect kernel list
Available kernel symlink targets:
  [1]   linux-6.6.21-gentoo

linux シンボリックリンクを作成するには、次を使用してください:

root #eselect kernel set 1
root #ls -l /usr/src/linux
lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo

別の方法: Genkernel

メモ
再掲ですが、この節はカーネルソースがインストールされていることを前提とします。適切なカーネルソースを取得していることを確認してから、ここに戻ってきてこの節の手順を進めてください。

すべてをマニュアルで設定することが困難だと思われる場合は、システム管理者はカーネル管理のためのハイブリッドアプローチとして、genkernel を使うことを考えてみるべきです。

Genkernel はジェネリックカーネルコンフィギュレーションファイルを提供し、カーネルと initramfs をコンパイルし、生成されたバイナリを適切な場所にインストールします。これによりシステムの初回起動のための最小限かつジェネリックなハードウェアサポートが得られ、さらなる更新の制御と、将来のカーネル設定のカスタマイズが可能になります。

注意: システム管理者はカーネルの保守のために genkernel を使うことで、システムのカーネル、initramfs、その他のオプションに関する更新をより制御できるようになります。その一方で、将来的に新しいソースがリリースされてカーネル更新を実施するときには、時間と労力をかけた献身が確実に必要となるでしょう。システム任せのカーネル保守アプローチを求めているのなら、ディストリビューションカーネルを使用するべきです。

もう一点明確にしておくと、genkernel が自動的に実行中のハードウェアのためにカスタマイズされたカーネルコンフィギュレーションを生成すると信じているなら、それは誤解です。genkernel は、大部分の汎用的なハードウェアをサポートするように事前に決定されたカーネルコンフィギュレーションを使用して、カーネル、関連するモジュール、そして initramfs ファイルをアセンブルしてインストールするために必要な make コマンドを、自動で操作します。

バイナリ再配布可能なソフトウェアのライセンスグループ

linux-firmware パッケージが以前にインストールされているなら、インストールの節に進んでください。

前提条件として、sys-kernel/genkernel パッケージの firwmare USE フラグがデフォルトで有効化されているため、パッケージマネージャは sys-kernel/linux-firmware パッケージを取り込もうとするでしょう。linux-firmware をインストールする前に、バイナリ再配布可能なソフトウェアライセンスを受諾する必要があります。

このライセンスグループは、/etc/portage/make.conf ファイル内で ACCEPT_LICENSE の値として @BINARY-REDISTRIBUTABLE を追加することで、すべてのパッケージに対してシステム全体で受諾することができます。/etc/portage/package.license/linux-firmware ファイルで個別の受諾を追加することで、linux-firmware パッケージのみに対して受諾することもできます。

必要であれば、ハンドブックのベースシステムのインストールの章で利用可能な、ソフトウェアライセンスを受諾する方法を再確認して、受け入れられるソフトウェアライセンスのために変更を加えてください。

分析麻痺に陥ってきたなら、次のようにすればよいでしょう:

root #mkdir /etc/portage/package.license
ファイル /etc/portage/package.license/linux-firmwarelinux-firmware パッケージのためにバイナリ再配布可能ライセンスを受諾する
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

インストール

説明や前提条件はさておき、sys-kernel/genkernel パッケージをインストールしてください:

root #emerge --ask sys-kernel/genkernel

生成

genkernel all を実行してカーネルソースをコンパイルしましょう。ただ、genkernel は多種多様に異なるコンピュータアーキテクチャのために、幅広いハードウェアをサポートするカーネルを生成するため、コンパイルが完了するまでにかなりの時間がかかることがあるということに注意しましょう。

メモ
もしルートパーティションまたはボリュームが ext4 以外のファイルシステムを使用している場合、おそらく genkernel --menuconfig all を使ってマニュアルでカーネルを設定し、その特定のファイルシステムのためのサポートを (モジュールとしてファイルシステムをビルドするのではなく) カーネルに組み込む必要があるでしょう。
メモ
LVM2 のユーザは以下の genkernel コマンドの引数に --lvm を加えるべきです。
root #genkernel --mountboot --install all

genkernel が完了したら、カーネルと初期 RAM ファイルシステム (initramfs) が生成され、/boot ディレクトリにインストールされていることでしょう。関連するモジュールは /lib/modules ディレクトリにインストールされるでしょう。initramfs は、(live ディスクイメージ環境でそうであるように) ハードウェアの自動検出を行うために、カーネルをロードした後すぐに開始されます。

root #ls /boot/vmlinu* /boot/initramfs*
root #ls /lib/modules

別の方法: マニュアル設定

はじめに

メモ
再掲ですが、この節はカーネルソースがインストールされていることを前提とします。適切なカーネルソースを取得していることを確認してから、ここに戻ってきてこの節の手順を進めてください。

カーネルのマニュアル設定は一般的に、システム管理者がしなければならない最も難しい手続きのひとつと見なされています。これは真実ではありません。カーネルを数回設定してみれば、それが難しいと言われていたことなど忘れてしまうでしょう!

しかし、一つだけ真実があります。カーネルをマニュアルで設定する時、ハードウェア情報を知ることはとても役に立ちます。ほとんどの情報は、lspciコマンドを含むsys-apps/pciutilsをインストールすることで得られます。

root #emerge --ask sys-apps/pciutils
メモ
chroot環境では、lspciが出力していると思われる(pcilib: cannot open /sys/bus/pci/devicesのような)pcilibの警告は、無視しても構いません。

システム情報を得るための別の方法は、lsmodを使ってインストールCDが使っているカーネルモジュールを把握することです。その情報は何を有効にすべきかとてもよいヒントを与えてくれるでしょう。

では、カーネルソースがあるディレクトリに移動して、make menuconfigを実行しましょう。このコマンドはメニューベースの設定画面を起動します。

root #cd /usr/src/linux
root #make menuconfig

Linux カーネルの設定はとても多くのセクションを持っています。まず最初にいくつかの必須オプションを述べましょう(そうでない場合、Gentoo は動作しない、もしくは追加の処置なしには正しく動作しません)。 Gentoo wiki の Gentoo カーネルコンフィギュレーションガイドには、さらに役立つ記述があるでしょう。

必須オプションを有効にする

もし sys-kernel/gentoo-sources を使用する場合は、Gentoo 固有のコンフィギュレーションオプションを有効化することを強く推奨します。これらは、正しく機能するために必要な最小限のカーネルの機能が有効化されることを確実にします:

カーネル Gentoo 固有オプションを有効化する
Gentoo Linux --->
  Generic Driver Options --->
    [*] Gentoo Linux support
    [*]   Linux dynamic and persistent device naming (userspace devfs) support
    [*]   Select options required by Portage features
        Support for init systems, system and service managers  --->
          [*] OpenRC, runit and other script based systems and managers
          [*] systemd

通常、最後の 2 行の選択は init システムの選択(OpenRCsystemd か)に依存します。両方の init システムへのサポートを有効化しても害はありません。

もし sys-kernel/vanilla-sources を使用する場合は、この init システムに関する追加の選択項目は利用できないでしょう。サポートを有効化することは可能ですが、このハンドブックの範囲からは外れることです。

典型的なシステムコンポーネントへのサポートを有効化する

システムのブートに必須となるドライバ (SATA コントローラ、NVMe ブロックデバイスサポート、ファイルシステムサポート等) は、モジュールではなく、カーネルの一部としてコンパイルしなければなりません。そうしないと、システムがまったくブートできない場合があります。

次に正確なプロセッサタイプを選択します。このとき、もし使えるのであればMCE機能を有効にすることが推奨されます。これによりハードウェアの異常が通知されるようになるでしょう。いくつかのアーキテクチャ(x86_64)で、これらのエラーはdmesgでは確認できませんが、/dev/mcelogにログが残ります。この機能を有効にするためにapp-admin/mcelogパッケージが必要になります。

また、Maintain a devtmpfs file system to mount at /devを選択することで、必須となるデバイスファイルがブートプロセスの初期段階で使えるようになります (CONFIG_DEVTMPFSCONFIG_DEVTMPFS_MOUNT):

カーネル devtmpfs サポートを有効にする (CONFIG_DEVTMPFS)
Device Drivers --->
  Generic Driver Options --->
    [*] Maintain a devtmpfs filesystem to mount at /dev
    [*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

SCSI ディスクサポートが有効になっているか確認してください(CONFIG_BLK_DEV_SD):

カーネル SCSI ディスクサポートを有効にする (CONFIG_SCSI, CONFIG_BLK_DEV_SD)
Device Drivers --->
  SCSI device support  ---> 
    <*> SCSI device support
    <*> SCSI disk support
カーネル 基本的な SATA および PATA サポートを有効化する (CONFIG_ATA_ACPI, CONFIG_SATA_PMP, CONFIG_SATA_AHCI, CONFIG_ATA_BMDMA, CONFIG_ATA_SFF, CONFIG_ATA_PIIX)
Device Drivers --->
  <*> Serial ATA and Parallel ATA drivers (libata)  --->
    [*] ATA ACPI Support
    [*] SATA Port Multiplier support
    <*> AHCI SATA support (ahci)
    [*] ATA BMDMA support
    [*] ATA SFF support (for legacy IDE and PATA)
    <*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)

基本的な NVMe サポートが有効になっているか確認してください:

カーネル Linux 4.4.x で基本的な NVMe サポートを有効化する (CONFIG_BLK_DEV_NVME)
Device Drivers  --->
  <*> NVM Express block device
カーネル Linux 5.x.x で基本的な NVMe サポートを有効化する (CONFIG_DEVTMPFS)
Device Drivers --->
  NVME Support --->
    <*> NVM Express block device

以下の追加の NVMe サポートを有効化しても害はありません:

カーネル 追加の NVMe サポートを有効化する (CONFIG_NVME_MULTIPATH, CONFIG_NVME_MULTIPATH, CONFIG_NVME_HWMON, CONFIG_NVME_FC, CONFIG_NVME_TCP, CONFIG_NVME_TARGET, CONFIG_NVME_TARGET_PASSTHRU, CONFIG_NVME_TARGET_LOOP, CONFIG_NVME_TARGET_FC, CONFIG_NVME_TARGET_FCLOOP, CONFIG_NVME_TARGET_TCP
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
  [*]   NVMe Target Passthrough support
  <M>   NVMe loopback device support
  <M>   NVMe over Fabrics FC target driver
  < >     NVMe over Fabrics FC Transport Loopback Test driver (NEW)
  <M>   NVMe over Fabrics TCP target support

次にFile Systemsで、システムが使用するファイルシステムに必要なサポートを選択しましょう。ルートファイルシステムに使われるファイルシステムをモジュールとしてコンパイルしてはいけません。モジュールにした場合、システムがパーティションをマウントできないおそれがあります。また、ここでVirtual memory/proc file systemも選択してください。システムの必要に応じて以下の選択肢から1個以上を選択してください:

カーネル ファイルシステムサポートを有効化する (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_BTRFS_FS, CONFIG_XFS_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS)
File systems --->
  <*> Second extended fs support
  <*> The Extended 3 (ext3) filesystem
  <*> The Extended 4 (ext4) filesystem
  <*> Btrfs filesystem support
  <*> XFS filesystem support
  DOS/FAT/NT Filesystems  --->
    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
  Pseudo Filesystems --->
    [*] /proc file system support
    [*] Tmpfs virtual memory file system support (former shm fs)

もしインターネットに接続するために、PPPoEもしくはダイヤルアップモデムを使う場合、次のオプションを有効にしてください (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):

カーネル PPPoE サポートを有効化する(PPPoE, CONFIG_PPPOE, CONFIG_PPP_ASYNC, CONFIG_PPP_SYNC_TTY
Device Drivers --->
  Network device support --->
    <*> PPP (point-to-point protocol) support
    <*> PPP over Ethernet
    <*> PPP support for async serial ports
    <*> PPP support for sync tty ports

2つの圧縮オプションは選択しても差し支えありませんが、必須というわけでもありません。PPP over Ethernetオプションも同様です。これはカーネルモードのPPPoEをするために設定された時だけにpppによって使用されるものです。

カーネルにネットワークカード(イーサネットもしくはワイヤレス)のサポートを組み込むことを忘れてはいけません。

多くのシステムではマルチコアを使用できます。Symmetric multi-processing supportを有効にすることは重要です (CONFIG_SMP):

カーネル SMP サポートを有効にする (CONFIG_SMP)
Processor type and features  --->
  [*] Symmetric multi-processing support
メモ
マルチコアシステムでは、それぞれのコアが1プロセッサとカウントされます。

USB接続の入力装置(キーボードやマウス)などのUSBデバイスを使用する場合、以下を必ず有効にしてください:

カーネル USB とヒューマンインプットデバイスのサポートを有効にする (CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, (CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, CONFIG_USB4)
Device Drivers --->
  HID support  --->
    -*- HID bus support
    <*>   Generic HID driver
    [*]   Battery level reporting for HID devices
      USB HID support  --->
        <*> USB HID transport layer
  [*] USB support  --->
    <*>     xHCI HCD (USB 3.0) support
    <*>     EHCI HCD (USB 2.0) support
    <*>     OHCI HCD (USB 1.1) support
  <*> Unified support for USB4 and Thunderbolt  --->

省略可能: 署名済みカーネルモジュール

自動的にカーネルモジュールに署名するためには、CONFIG_MODULE_SIG_ALL を有効化してください:

カーネル カーネルモジュールに署名する CONFIG_MODULE_SIG_ALL
[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Automatically sign all modules    
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

お望みであれば任意でハッシュアルゴリズムを変更してください。

すべてのモジュールが有効な署名で署名されていることを強制するためには、CONFIG_MODULE_SIG_FORCE も有効化してください:

カーネル 署名済みカーネルモジュールを強制する CONFIG_MODULE_SIG_FORCE
[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Require modules to be validly signed
    [*]     Automatically sign all modules
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

カスタム鍵を使用するためには、CONFIG_MODULE_SIG_KEY にこの鍵の場所を指定してください。指定されていない場合は、カーネルビルドシステムが鍵を生成するでしょう。それに任せずに手動で鍵を生成することが推奨されます。これは、以下で行えます:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem

OpenSSL は鍵を生成するユーザについて、いくつかの質問をしてくるでしょう。これらの質問にできる限り詳細に答えることが推奨されます。

鍵を安全な場所に保存してください。少なくとも、鍵は root ユーザによってのみ読み込み可能であるべきです。以下でこれを検証してください:

root #ls -l kernel_key.pem
 -r-------- 1 root root 3164 Jan  4 10:38 kernel_key.pem 

もしこれが上と何か違うものを出力する場合は、パーミッションを以下で訂正してください:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
カーネル 署名鍵を指定する CONFIG_MODULE_SIG_KEY
-*- Cryptographic API  ---> 
  Certificates for signature checking  --->  
    (/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key

linux-mod-r1.eclass を利用する他のパッケージによってインストールされた外部カーネルモジュールにも署名するには、グローバルに modules-sign USE フラグを有効化してください:

ファイル /etc/portage/make.confモジュールの署名を有効化する
USE="modules-sign"

# 任意で、カスタム署名鍵を使用する場合。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # 鍵 MODULES_SIGN_KEY が証明書を含まない場合のみ必須です
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です
メモ
MODULES_SIGN_KEYMODULES_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。

省略可能: カーネルイメージに署名する (セキュアブート)

(セキュアブートが有効化されたシステムで使用するために) カーネルイメージに署名する場合には、以下のカーネルコンフィグオプションを設定することが推奨されます:

カーネル セキュアブートのためのロックダウン
General setup  --->
  Kexec and crash features  --->   
    [*] Enable kexec system call                                                                                          
    [*] Enable kexec file based system call                                                                               
    [*]   Verify kernel signature during kexec_file_load() syscall                                                        
    [*]     Require a valid signature in kexec_file_load() syscall                                                        
    [*]     Enable ""image"" signature verification support  

[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Require modules to be validly signed
    [*]     Automatically sign all modules
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->  

Security options  ---> 
[*] Integrity subsystem   
  [*] Basic module for enforcing kernel lockdown                                                                       
  [*]   Enable lockdown LSM early in init                                                                       
        Kernel default lockdown mode (Integrity)  --->            

  [*]   Digital signature verification using multiple keyrings                                                            
  [*]     Enable asymmetric keys support                                                                                     
  -*-       Require all keys on the integrity keyrings be signed                                                              
  [*]       Provide keyring for platform/firmware trusted keys                                                                
  [*]       Provide a keyring to which Machine Owner Keys may be added                                                        
  [ ]         Enforce Machine Keyring CA Restrictions

ただし ""image"" はアーキテクチャ固有のイメージ名に対するプレースホルダです。これらのオプションは上から順に、kexec の呼び出し時にカーネルイメージが署名されていることを強制し (kexec はカーネルをその場で置き換えることを許可します)、カーネルモジュールが署名されていることを強制し、integrity ロックダウンモードを有効化し (実行時にカーネルを変更することを防止します)、各種キーチェーンを有効化します。

圧縮されたカーネルの展開をネイティブにサポートしていないアーキテクチャ (例: arm64 および riscv) では、カーネルは自身の展開プログラム (zboot) とともにビルドしなくてはなりません:

カーネル zboot CONFIG_EFI_ZBOOT
Device Drivers --->                                                                                                                           
  Firmware Drivers --->                                                                                                                       
    EFI (Extensible Firmware Interface) Support --->                                                                                               
      [*] Enable the generic EFI decompressor

カーネルのコンパイル後は、次の節で説明する通り、カーネルイメージに署名しなくてはなりません。まず app-crypt/sbsigntools をインストールして、次にカーネルイメージに署名してください:

root #emerge --ask app-crypt/sbsigntools
root #sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-image
メモ
この例では、カーネルイメージに署名するために、モジュールに署名するために生成されたのと同じ鍵が使用されています。カーネルイメージに署名するために、2 個目の別の鍵を生成して使用することも可能です。前節と同じ OpenSSL コマンドをもう一度使用することができます。

Then proceed with the installation.

他のパッケージによってインストールされる EFI 実行可能形式に自動的に署名するには、グローバルに secureboot USE フラグを有効化してください:

ファイル /etc/portage/make.confセキュアブートを有効化する
USE="modules-sign secureboot"

# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です

# 任意で、セキュアブートを有効化してブートするために。署名鍵は同一でも別でも構いません。
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
メモ
SECUREBOOT_SIGN_KEYSECUREBOOT_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
メモ
systemd の ukify を使用して Unified カーネルイメージを生成する場合は、カーネルイメージは unified カーネルイメージに含められる前に自動的に署名されるので、手動で署名する必要はありません。

Architecture specific kernel configurations

メモ
Placeholder for architecture-specific kernel build information

Compiling and installing

メモ
Placeholder for instructions for building and installing the kernel sources

カーネルのインストール

Installkernel

Installkernel は、カーネルのインストール、initramfs の生成、unified カーネルイメージの生成、そして何よりもブートローダの設定を自動化するために、使用することができます。sys-kernel/installkernel はこれを達成するための 2 通りの道を実装しています: Debian に由来する伝統的な installkernel と、 systemdkernel-install です。どちらを選ぶべきかは、何よりもシステムのブートローダによって変わります。デフォルトでは、systemd プロファイルでは systemd の kernel-install が使用される一方、それ以外のプロファイルでは伝統的な installkernel がデフォルトです。

よく分からない場合は、下の「伝統的なレイアウト」のサブ節に従ってください。

systemd-boot

ブートローダとして systemd-boot (旧 gummiboot) を使用している場合は、systemd の kernel-install を使用しなくてはなりません。そのため、sys-kernel/installkernel に対して systemd および systemd-boot USE フラグが有効化されていることを確認して、systemd-boot のための関連するパッケージをインストールしてください。

OpenRC システムでは:

ファイル /etc/portage/package.use/systemd-boot
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils

systemd システムでは:

ファイル /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #emerge --ask sys-apps/systemd

GRUB

Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel

伝統的なレイアウト、その他のブートローダ (lilo 等)

The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.


initramfs をビルドする

In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs. The default configuration of the Project:Distribution Kernel requires an initramfs.

Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.

重要
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass --kernel-config=/path/to/kernel.config to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.

Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut

Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:

root #emerge --ask sys-kernel/dracut
root #dracut --kver=6.6.21-gentoo

The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:

root #ls /boot/initramfs*

Optional: Building an Unified Kernel Image

An Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.

An unified kernel image requires a stub loader, currently the only one available is systemd-stub. To enable it:

systemd システムでは:

ファイル /etc/portage/package.use/systemd
sys-apps/systemd boot

OpenRC システムでは:

ファイル /etc/portage/package.use/systemd-utils
sys-apps/systemd-utils boot kernel-install

Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).

For dracut:

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut uki
ファイル /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

For ukify:

ファイル /etc/portage/package.use/installkernel
sys-apps/systemd ukify          # For systemd systems
sys-apps/systemd-utils ukify    # For OpenRC systems
sys-kernel/installkernel dracut ukify uki
ファイル /etc/kernel/cmdline
some-kernel-command-line-arguments

Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.

Generic Unified Kernel Image

The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:

ファイル /etc/portage/package.use/generic-uki
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki

セキュアブート

The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.

For dracut:

ファイル /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"

For ukify:

ファイル /etc/kernel/uki.conf
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

外部のカーネルモジュールを再ビルドする

linux-mod-r1.eclass を介して他のパッケージによってインストールされた外部のカーネルモジュールは、新しいカーネルバージョンごとに、再ビルドしなくてなりません。ディストリビューションカーネルを使用している場合は、dist-kernel フラグをグローバルに有効化することで、これを自動化することができます。

ファイル /etc/portage/package.use/module-rebuild
*/* dist-kernel

外部のカーネルモジュールは手動で再ビルドすることもできます:

root #emerge --ask @module-rebuild

カーネルモジュール

利用可能なカーネルモジュールを一覧表示する

メモ
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、udev は接続を検出したハードウェアのモジュールを自動でロードします。ですが、自動でロードされるであろうモジュールを列挙することは特に有害ではありません。モジュールが二度ロードされることはありません。モジュールの状態は、ロードされているかいないか、どちらかしかありません。時として変なハードウェアは、ドライバをロードするのにこうした手助けが必要になることがあります。

/etc/modules-load.d/*.conf ファイルに、ブート時に毎回ロードしなければならないモジュールを、1 行ごとに 1 モジュールのフォーマットで追加することができます。モジュールに追加のオプションを与える必要があれば、ここではなく /etc/modprobe.d/*.confファイルで設定すべきです。

特定のカーネルバージョンで利用可能なすべてのモジュールを把握するためには、次の find コマンドを実行してください。"<kernel version>" を検索したいカーネルのバージョンで適切に置き換えることを忘れないでください:

root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less

特定のカーネルモジュールのロードを強制する

3c59x.ko モジュール (これは特定の 3Com ネットワークカードファミリのためのドライバです) をロードするようにカーネルに強制するには、/etc/modules-load.d/network.conf 内にモジュール名を記載してください。

root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf

モジュールの .ko ファイル拡張子はロード機構にとって重要ではなく、設定ファイルから除かれるということに注意してください:

ファイル /etc/modules-load.d/network.conf強制的に3c59x モジュールをロードする
3c59x

では、システムの設定に進み、インストールを続けましょう。