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

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 56% complete.
Outdated translations are marked like this.


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

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


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

ファームウェア

Linux ファームウェア

On many systems, non-FOSS firmware is required for certain hardware to function. The sys-kernel/linux-firmware package contains firmware for many, but not all, devices.

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

Firmware files are typically loaded when the associated kernel module is loaded. This means the firmware must be built into the kernel using CONFIG_EXTRA_FIRMWARE if the kernel module is set to Y instead of M. In most cases, building-in a module which required firmware can complicate or break loading.

Architecture specific firmware

メモ
Placeholder for architecture-specific firmware information

{{#switch: amd64 | amd64 | x86 =

マイクロコード

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

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

sys-kernel/installkernel

Installkernel may be used to automate the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default, systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.

Bootloader

Now is the time to think about which bootloader the user wants for the system, if unsure, follow the 'Traditional layout' subsection below.

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

systemd-boot

When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.

On OpenRC systems:

ファイル /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 sys-kernel/installkernel

On systemd systems:

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

The kernel command line to use for new kernels should be specified in /etc/kernel/cmdline, for example:

ファイル /etc/kernel/cmdline
quiet splash

EFI stub

UEFI-based computer systems technically do not need secondary bootloaders in order to boot kernels. Secondary bootloaders exist to extend the functionality of UEFI firmware during the boot process. That being said, using a secondary bootloader is typically easier and more robust because it offers a more flexible approach for quickly modifying kernel parameters at boot time. Note also that UEFI implentations strongly differ between vendors and between models and there is no guarantee that a given firmware follows the UEFI specification. Therefore, EFI Stub booting is not guaranteed to work on every UEFI-based system, and hence the USE flag is stable masked and testing keywords must be accepted for installkernel to use this feature.

ファイル /etc/portage/package.accept_keywords/installkernel
sys-kernel/installkernel
sys-boot/uefi-mkconfig
app-emulation/virt-firmware
ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel efistub
root #emerge --ask sys-kernel/installkernel
root #mkdir -p /efi/efi/gentoo

Traditional layout, other bootloaders (e.g. (e)lilo, syslinux, etc.)

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

initramfs をビルドする

An initial ram-based file system, or initramfs, may be required for a system to boot. A wide of variety of cases may necessitate one, but common cases include:

  • Kernels where storage/filesystem drivers are modules.
  • Layouts with /usr/ or /var/ on separate partitions.
  • Encrypted root filesystems.
ヒント
Distribution kernels are designed to be used with an initramfs, as many storage and filesystem drivers are built as modules.

In addition to mounting the root filesystem, an initramfs may also perform other tasks such as:

  • Running file system consistency check fsck, a tool to check and repair consistency of a file system in such events of uncleanly shutdown a system.
  • Providing a recovery environment in the event of late-boot failures.

Installkernel は、dracut USE フラグが有効化されている場合、カーネルのインストール時に initramfs を自動的に生成することができます:

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

{{#switch: amd64 | amd64 | arm64 | x86 =

省略可能: Unified カーネルイメージをビルドする

Unified カーネルイメージ (UKI) は、まず何よりもカーネル、そして initramfs、それとカーネルコマンドラインを単一の実行可能形式に合成したものです。カーネルコマンドラインは unified カーネルイメージ内に埋め込まれるので、unified カーネルイメージを生成する前に指定するべきです (下を参照してください)。セキュアブートを有効化してブートする場合、ブートローダまたはファームウェアによってブート時に提供されるあらゆるカーネルコマンドライン引数は無視されることに注意してください。

unified カーネルイメージはスタブローダを必要とします。現時点で唯一利用可能なのは systemd-stub です。これを有効化するには:

systemd システムでは:

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

OpenRC システムでは:

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

Installkernel は、それぞれ対応するフラグを有効化することで、dracut または ukify のいずれかを使用して自動的に unified カーネルイメージを生成することができます。生成された unified カーネルイメージを EFI システムパーティション (ESP) 上の $ESP/EFI/Linux ディレクトリにインストールするために、uki USE フラグも有効化すべきです。

dracut を使用する場合は:

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

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
root #emerge --ask sys-kernel/installkernel

dracut は initramfs と unified カーネルイメージの両方を生成することができる一方で、ukify は後者しか生成できないので、initramfs は dracut を使用して個別に生成しなくてはならないことに注意してください。

重要
In the above configuration examples (for both Dracut and ukify) it is important to specify at least an appropriate root= parameter for the kernel command line to ensure that the Unified Kernel Image can find the root partition. This is not required for systemd based systems following the Discoverable Partitions Specification (DPS), in that case the embedded initramfs will be able to dynamically find the root partition.

ジェネリック Unified カーネルイメージ

ビルド済みの sys-kernel/gentoo-kernel-bin は任意で、ほとんどの systemd ベースのシステムをブートすることができるジェネリックな initramfs を含む、ビルド済みのジェネリック unified カーネルイメージをインストールすることができます。これは、generic-uki USE フラグを有効化して、installkernel をカスタムの initramfs または unified カーネルイメージを生成しないように設定することで、インストールすることができます:

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

セキュアブート

警告
If following this section and manually compiling your own kernel, then make sure to follow the steps outlined in Signing the kernel

sys-kernel/gentoo-kernel-bin によって任意に配布されているジェネリック Unified カーネルイメージは事前署名済みです。ローカルで生成された unified カーネルイメージに署名する方法は dracut または ukify のどちらを使用するかで異なります。鍵と証明書の場所は /etc/portage/make.conf 内で指定された SECUREBOOT_SIGN_KEY および SECUREBOOT_SIGN_CERT と同一であるべきということに注意してください。

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"

ukify を使用する場合は:

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

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

ヒント
It can be a wise move to use the dist-kernel on the first boot as it provides a very simple method to rule out system issues and kernel config issues. Always having a known working kernel to fallback on can speed up debugging and alleviate anxiety when updating that your system will no longer boot.

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

メモ
During the installation phase of Gentoo, only one kernel type should be installed i.e. either the sys-kernel/gentoo-kernel-bin or sys-kernel/gentoo-sources.

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

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

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

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

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

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

省略可能: 署名付きカーネルモジュール

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルモジュールは既に署名されています。ソースからビルドしたカーネルのモジュールに署名するためには、/etc/portage/make.conf で 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_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_KEY と MODULES_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.conf で 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_KEY と SECUREBOOT_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
メモ
この例では、カーネルイメージに署名するために、モジュールに署名するために生成されたのと同じ鍵が使用されています。カーネルイメージに署名するために、2 個目の別の鍵を生成して使用することも可能です。前節と同じ OpenSSL コマンドをもう一度使用することができます。

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

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

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

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

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

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

root #emerge --ask sys-kernel/gentoo-kernel-bin
重要
Distribution Kernels, such as sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin, by default, expect to be installed alongside an initramfs. Before running emerge to install the kernel users should ensure that sys-kernel/installkernel has been configured to utilize an initramfs generator (for example Dracut) as described in the installkernel section.

アップグレードと後処理

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

root #emerge --depclean

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

root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin
ヒント
By design, emerge only removes the kernel build directory. It does not actually remove the kernel modules, nor the installed kernel image. To completely clean-up old kernels, the app-admin/eclean-kernel tool may be used.

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

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

ディストリビューションカーネルを使用する場合、この USE フラグは /etc/portage/make.conf 内でグローバルに適用されるべきです。そうすることで、sys-fs/zfs や x11-drivers/nvidia-drivers などのパッケージは新しく更新されたカーネルに対して自動的に再ビルドされ、適用可能であれば、それに従って initramfs が再生成されるでしょう。

ファイル /etc/portage/make.confEnabling USE=dist-kernel
USE="dist-kernel"
手動で initramfs または Unified カーネルイメージを再ビルドする

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

root #emerge --ask @module-rebuild

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

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

After installing the Distribution Kernel successfully, it is now time to proceed to the next section: Configuring the system.

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

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

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

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

Manually configuring a kernel is commonly seen as one of the most difficult procedures a system administrator has to perform. Nothing is less true - after configuring a few kernels no one remembers that it was difficult! There are two ways for a Gentoo user to manage a manual kernel system, both of which are listed below:

Modprobed-db process

A very easy way to manage the kernel is to first install sys-kernel/gentoo-kernel-bin and use the sys-kernel/modprobed-db to collect information about what the system requires. modprobed-db is a tool which monitors the system via crontab to add all modules of all devices over the system's life to make sure it everything a user needs is supported. For example, if an Xbox controller is added after installation, then modprobed-db will add the modules to be built next time the kernel is rebuilt. More on this topic can be found in the Modprobed-db article.

Manual process

This method allows a user to have full control of how their kernel is built with as minimal help from outside tools as they wish. Some could consider this as making it hard for the sake of it.

しかし、一つだけ真実があります。カーネルをマニュアルで設定する時、ハードウェア情報を知ることはとても役に立ちます。ほとんどの情報は、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

The kernel has a method of autodetecting the modules currently being used on the installcd which will give a great starting point to allow a user to configure their own. This can be called by using:

root #make localmodconfig

It's now time to configure using nconfig:

root #make nconfig

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

Enabling required options

もし 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 システムの選択（OpenRC か systemd か）に依存します。両方の init システムへのサポートを有効化しても害はありません。

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

Enabling support for typical system components

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

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

また、Maintain a devtmpfs file system to mount at /devを選択することで、必須となるデバイスファイルがブートプロセスの初期段階で使えるようになります (CONFIG_DEVTMPFS と CONFIG_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
メモ
マルチコアシステムでは、それぞれのコアが１プロセッサとカウントされます。

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_KEY と MODULES_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 コマンドをもう一度使用することができます。

それではインストールを続行してください。

他のパッケージによってインストールされる 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_KEY と SECUREBOOT_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

Deprecated: Genkernel

Genkernel should only be considered by users with a required need that only Genkernel can meet. For others, it is recommended to use the Distribution kernel or manually compile their own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods; for example, Unified Kernel Images will need to be created manually when using Genkernel.

Users still wishing to use Genkernel should see the Genkernel article for more information.

カーネルモジュール

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

メモ
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、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

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


← Gentooベースシステムのインストール Home システムの設定 →


Retrieved from "https://wiki.gentoo.org/index.php?title=Handbook:Parts/Installation/Kernel/ja&oldid=1352251"