ハンドブック:HPPA/インストール/カーネル

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:HPPA/Installation/Kernel and the translation is 100% complete.
HPPA ハンドブック
インストール
インストールについて
メディアの選択
ネットワーク設定
ディスクの準備
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) されたカーネルシンボルは、カーネルにロードされたときに、関連するファームウェアファイルをファイルシステムからロードすることに注意してください。モジュールとしてロードされるシンボルに関しては、デバイスのファームウェアファイルをカーネルのバイナリイメージに含める必要はありません。

SOF ファームウェア

重要
Use of this firmware requires enabling certain Kernel options and is only supported on AMD64 currently. Enabling these options are only necessary if a manual configuration is planned, as the Distribution Kernels have them enabled already. The necessary options are covered in architecture specific kernel configuration.

Sound Open Firmware (SOF) is a new open source audio driver meant to replace the proprietary Smart Sound Technology (SST) audio driver from Intel. 10th gen+ and Apollo Lake (Atom E3900, Celeron N3350, and Pentium N4200) Intel CPUs require this firmware for certain features and certain AMD APUs also have support for this firmware. SOF's supported platforms matrix can be found here for more information.

root #emerge --ask sys-firmware/sof-firmware

マイクロコード

個別のグラフィックスハードウェアやネットワークインターフェースに加えて、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 カーネルです。カーネルレイヤーはユーザのプログラムとハードウェアの間に存在します。ハンドブックではカーネルソースについていくつかの可能な選択肢を提供しますが、より詳しい説明付きで、より完全なカーネルソースのリストは、カーネルの概要のページで見ることができます。


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

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

hppa ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、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-3.16.5-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-3.16.5-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  --->

Optional: Signed kernel modules

To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:

カーネル Sign kernel modules 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) --->

Optionally change the hash algorithm if desired.

To enforce that all modules are signed with a valid signature, enable CONFIG_MODULE_SIG_FORCE as well:

カーネル Enforce signed kernel modules 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) --->

To use a custom key, specify the location of this key in CONFIG_MODULE_SIG_KEY, if unspecified the kernel build system will generate a key. It is recommended to generate one manually instead. This can be done with:

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

OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.

Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:

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

If this outputs anything other then the above, correct the permissions with:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
カーネル Specify signing key 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

To also sign external kernel modules installed by other packages via linux-mod-r1.eclass, enable the modules-sign USE flag globally:

ファイル /etc/portage/make.confEnable module signing
USE="modules-sign"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, when using custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate
MODULES_SIGN_HASH="sha512" # Defaults to sha512
メモ
The MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.

Optional: Signing the kernel image (Secure Boot)

When signing the kernel image (for use on systems with Secure Boot enabled) it is recommended to set the following kernel config options:

カーネル Lockdown for secureboot
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
</div>  

<div lang="en" dir="ltr" class="mw-content-ltr">
[*] 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) --->
</div>  

<div lang="en" dir="ltr" class="mw-content-ltr">
Security options  ---> 
[*] Integrity subsystem   
  [*] Basic module for enforcing kernel lockdown                                                                       
  [*]   Enable lockdown LSM early in init                                                                       
        Kernel default lockdown mode (Integrity)  --->
</div>            

  <div lang="en" dir="ltr" class="mw-content-ltr">
[*]   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

Where ""image"" is a placeholder for the architecture specific image name. These options, from the top to the bottom: enforces that the kernel image in a kexec call must be signed (kexec allows replacing the kernel in-place), enforces that kernel modules are signed, enables lockdown integrity mode (prevents modifying the kernel at runtime), and enables various keychains.

On arches that do not natively support decompressing the kernel (e.g. arm64 and riscv), the kernel must be built with its own decompressor (zboot):

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

After compilation of the kernel, as explained in the next section, the kernel image must be signed. First install app-crypt/sbsigntools and then sign the kernel image:

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
メモ
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second sperate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.

Then proceed with the installation.

To automatically sign EFI executables installed by other packages, enable the secureboot USE flag globally:

ファイル /etc/portage/make.confEnable Secure Boot
USE="modules-sign secureboot"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
メモ
The SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
メモ
When generating an Unified Kernel Image with systemd's ukify the kernel image will be signed automatically before inclusion in the unified kernel image and it is not necessary to sign it manually.


コンパイルおよびインストール

重要
64 ビットカーネルをコンパイルする場合、まず sys-devel/kgcc64 を emerge してください。64 ビットカーネルの実行はかつて推奨されていませんでしたが、今は安全になっているはずです。疑わしい場合は、システムが 4GB 以上の RAM を備えているか、サーバが必要とする場合 (つまり A500 上の場合) のみ 64 ビットカーネルを動作させてください。

カーネルのコンフィグレーションが完了し、コンパイルとインストールをする時がきました。コンフィグレーションを終了させ、コンパイル作業を開始しましょう:

root #make && make modules_install

If building a 64-bit kernel, do this instead (it's necessary even for native builds, see here):

root #CROSS_COMPILE=hppa64-unknown-linux-gnu- make && CROSS_COMPILE=hppa64-unknown-linux-gnu- make modules_install
メモ
make -jX とすることで、ビルドを並行処理させることができます( X には、並行処理を許可するビルドプロセスの数を指定します。 /etc/portage/make.conf の説明中の、 MAKEOPTS 変数についてと同様です。

カーネルのコンパイルが終了したら、カーネルイメージを/boot/にコピーしてください。カーネルの選択に適した名前を使い、また名前を覚えておいてください。後にブートローダの設定で必要です。kernel-3.16.5-gentooを、インストールされたカーネルの名前とバージョンに置換するのを忘れないでください。

root #cp vmlinux /boot/kernel-3.16.5-gentoo


カーネルのインストール

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.

If unsure, follow the 'Traditional layout' subsection below.

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

On systemd systems:

ファイル /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
# Needed for <systemd-254
sys-apps/systemd gnuefi
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

When systemd's kernel-install is used, it should be configured to use the grub layout, this is the default if the grub USE flag is enabled:

ファイル /etc/kernel/install.conf
layout=grub

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

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.


Building an 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=3.16.5-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:

For systemd systems:

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

For OpenRC systems:

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

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-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

Rebuilding external kernel modules

External kernel modules installed by other packages via linux-mod-r1.eclass must be rebuilt for each new kernel version. When the distribution kernels are used this may be automated by enabling the dist-kernel flag globally.

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

External kernel modules may also be rebuilt manually with:

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

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