ハンドブック:IA64/インストール/カーネル
任意自由選択: ファームウェアとマイクロコードのインストール
ファームウェア
提案: Linux ファームウェア
多くのシステムでは、特定のハードウェアが正しく機能するための非 FOSS なファームウェアが必要です。sys-kernel/linux-firmware パッケージは、すべてではありませんが、多くのデバイスのためのファームウェアを含んでいます。
ほとんどの無線カードと GPU は、機能するためにファームウェアを必要とします。
root #emerge --ask sys-kernel/linux-firmware一部のファームウェアパッケージのインストールには、関連するファームウェアライセンスを受諾する必要があることがよくあります。必要であれば、ライセンスの受諾についてはハンドブックのライセンスの取り扱いの節を確認してください。
ファームウェアのロード
ファームウェアファイルは、典型的には、それに関連付けられたカーネルモジュールがロードされたときにロードされます。これはつまり、カーネルモジュールが M ではなく Y に設定されている場合、ファームウェアは CONFIG_EXTRA_FIRMWARE を使用してカーネルに組み込まれていなくてはならないということです。ほとんどの場合、ファームウェアを必要とするモジュールの組み込みは、ロードを複雑にしたり、失敗の原因になったりすることがあります。
sys-kernel/installkernel
Installkernel は、カーネルのインストール、initramfs の生成、unified カーネルイメージの生成、そして何よりもブートローダの設定を自動化するために、使用することができます。sys-kernel/installkernel はこれを達成するための 2 通りの道を実装しています: Debian に由来する伝統的な installkernel と、 systemd の kernel-install です。どちらを選ぶべきかは、何よりもシステムのブートローダによって変わります。デフォルトでは、systemd プロファイルでは systemd の kernel-install が使用される一方、それ以外のプロファイルでは伝統的な installkernel がデフォルトです。
ブートローダ
今こそ、システムでどのブートローダを使いたいかについて考えるときです。よく分からない場合は、下の「伝統的なレイアウト」のサブ節に従ってください。
GRUB
GRUB を使用する場合は、systemd の kernel-install または伝統的な Debian installkernel のいずれかを使用することができます。systemd USE フラグはこれらの実装の切り換えを行います。カーネルをインストールするときに自動的に grub-mkconfig を実行するためには、grub USE フラグを有効化してください。
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel
伝統的なレイアウト、他のブートローダ (例: (e)lilo、syslinux 等)
grub、systemd-boot、efistub または uki USE フラグが有効化されていない場合は、伝統的な /boot レイアウト (例えば (e)LILO、syslinux 等向けの) がデフォルトで使用されます。追加の操作は必要ありません。
Initramfs
システムがブートするために、初期 RAM ファイルシステム (initial ram-based file system)、または initramfs が必要になる場合があります。必要になるケースは様々なものがありますが、よくあるのは以下の場合です:
- ストレージ/ファイルシステムのドライバーがモジュールになっているカーネル。
- /usr/ または /var/ が分離されたパーティション上にあるレイアウト。
- 暗号化されたルートファイルシステム。
ディストリビューションカーネルは、多くのストレージとファイルシステムのドライバがモジュールとしてビルドされるので、initramfs とともに使用するように設計されています。
ルートファイルシステムのマウントに加えて、initramfs は以下のような他のタスクも行うことができます:
- 正常でないシステムシャットダウンの発生時にファイルシステムの一貫性を確認し修復するためのツールである、file system consistency check fsck を実行する。
- ブート後期での失敗時に回復環境を提供する。
Installkernel は、dracut または ugrd USE フラグが有効化されている場合、カーネルのインストール時に initramfs を自動的に生成することができます:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
root #emerge --ask sys-kernel/installkernel
カーネルのコンフィギュレーションとコンパイル
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.
簡単なものから込み入ったものへ、順に並べると:
- 完全手動アプローチ
- 新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。カーネルは eselect kernel と無数の make コマンドを利用して、手動で設定、ビルド、インストールされます。将来のカーネル更新はカーネルファイルの設定、ビルド、インストールの手動プロセスを繰り返して行います。これが最も込み入ったプロセスですが、カーネル更新プロセスに関して最大限の制御を行えます。
- ハイブリッドアプローチ: Genkernel
- ここでハイブリッドという語を使用しましたが、ディストリビューションカーネルと手動ソースは、どちらも同じゴールを達成するための手法を含んでいることに注意してください。新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。システム管理者は Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されていない) initramfs ファイルを、設定、ビルド、インストールするために Gentoo の genkernel ツールを使用することができます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。将来のカーネル設定、コンパイル、インストールには、アップデートのたびに eselect kernel、genkernel、およびもし必要であれば他のコマンドを実行する形で、システム管理者による関与が必要です。この選択肢は、自分は genkernel が必要だと知っているユーザのみ考慮すべきです。
すべてのディストリビューションが構築されるその中心にあるのが Linux カーネルです。カーネルレイヤーはユーザのプログラムとハードウェアの間に存在します。ハンドブックではカーネルソースについていくつかの可能な選択肢を提供しますが、より詳しい説明付きで、より完全なカーネルソースのリストは、カーネルの概要のページで見ることができます。
/boot または EFI システムパーティションへのカーネルイメージのコピー、initramfs や Unified カーネルイメージの生成、ブートローダの設定の更新など、カーネルインストールのタスクは、installkernel で自動化することができます。先に進める前に、sys-kernel/installkernel をインストールして設定するとよいかもしれません。さらなる情報については下のカーネルインストールの節を参照してください。
カーネルソースのインストール
ia64 ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、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 listAvailable kernel symlink targets: [1] linux-6.6.21-gentoo
linux シンボリックリンクを作成するには、次を使用してください:
root #eselect kernel set 1root #ls -l /usr/src/linuxlrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
別の方法: マニュアル設定
再掲ですが、この節はカーネルソースがインストールされていることを前提とします。適切なカーネルソースを取得していることを確認してから、ここに戻ってきてこの節の手順を進めてください。
カーネルのマニュアル設定は一般的に、システム管理者がしなければならない最も難しい手続きのひとつと見なされています。これは真実ではありません。カーネルを数回設定してみれば、それが難しいと言われていたことなど忘れてしまうでしょう！ Gentoo ユーザが手動でカーネルシステムを管理するための方法は 2 通りあり、その両方を以下に示します:
Modprobed-db プロセス
カーネルを管理するための非常に簡単な方法のひとつは、まず sys-kernel/gentoo-kernel-bin をインストールし、システムが必要とするものについての情報を収集するために sys-kernel/modprobed-db を使用するという方法です。modprobed-db は crontab を介してシステムを監視し、システムが使用されている間のすべてのデバイスのすべてのモジュールを追加し、ユーザが必要とするものすべてがサポートされていることを確実にするツールです。例えば、インストール後に Xbox コントローラが追加されたら modprobed-db は、カーネルが次回再ビルドされるときにビルドされる対象としてそのモジュールを追加するでしょう。この話題についてさらに詳しくは、Modprobed-db の記事で読むことができます。
手動プロセス
この方法では、外部ツールの利用を望む限り最小限にすることによって、カーネルのビルド方法を完全に管理することができます。人によってはこの方法のことを、わざわざ難しくやっていると思うかもしれません。
しかし、この選択肢を取る場合でも一つだけ真実があります。カーネルを手動で設定する時、ハードウェア情報を知ることはとても役に立ちます。ほとんどの情報は、lspci コマンドを含む sys-apps/pciutils をインストールすることで得られます。
root #emerge --ask sys-apps/pciutilschroot環境では、lspciが出力していると思われる(pcilib: cannot open /sys/bus/pci/devicesのような)pcilibの警告は、無視しても構いません。
システム情報を得るための別の方法は、lsmodを使ってインストールCDが使っているカーネルモジュールを把握することです。その情報は何を有効にすべきかとてもよいヒントを与えてくれるでしょう。
では、カーネルソースがあるディレクトリに移動しましょう。
root #cd /usr/src/linux
To view the full list of make arguments available for the kernel, run
make help.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 localmodconfigIt's now time to configure using nconfig:
root #make nconfigLinux カーネルの設定はとても多くのセクションを持っています。まず最初にいくつかの必須オプションを述べましょう（そうでない場合、Gentoo は動作しない、もしくは追加の処置なしには正しく動作しません）。 Gentoo wiki の Gentoo カーネルコンフィギュレーションガイドには、さらに役立つ記述があるでしょう。
必要なオプションを有効化する
もし sys-kernel/gentoo-sources を使用する場合は、Gentoo 固有のコンフィギュレーションオプションを有効化することを強く推奨します。これらは、正しく機能するために必要な最小限のカーネルの機能が有効化されることを確実にします:
Gentoo Linux --->
[*] 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 システムに関する追加の選択項目は利用できないでしょう。サポートを有効化することは可能ですが、このハンドブックの範囲からは外れることです。
典型的なシステムコンポーネントへのサポートを有効化する
システムのブートに必須となるドライバ (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):
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):
Device Drivers --->
SCSI device support --->
<*> SCSI device support
<*> SCSI disk support
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 サポートが有効になっているか確認してください:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
以下の追加の NVMe サポートを有効化しても害はありません:
[*] 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個以上を選択してください:
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):
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):
Processor type and features --->
[*] Symmetric multi-processing support
マルチコアシステムでは、それぞれのコアが１プロセッサとカウントされます。
USB接続の入力装置（キーボードやマウス）などのUSBデバイスを使用する場合、以下を必ず有効にしてください:
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 を有効化してください:
[*] 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 も有効化してください:
[*] 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.pemOpenSSL は鍵を生成するユーザについて、いくつかの質問をしてくるでしょう。これらの質問にできる限り詳細に答えることが推奨されます。
鍵を安全な場所に保存してください。少なくとも、鍵は 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
-*- 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 ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
アーキテクチャ固有のカーネルコンフィグ
正しいシステム種別とプロセッサ種別を選択してください。DIG-compliant はデフォルトの良い選択肢です。SGI システムにインストールするときは、SGI システム種別を選択しているか確認してください。さもないと、カーネルが動かずブートに失敗するかもしれません。
System type --->
(システムに応じて変更してください)
DIG-compliant
Processor type --->
(システムに応じて変更してください)
Itanium 2
コンパイルおよびインストール
カーネルのコンフィグレーションが完了し、コンパイルとインストールをする時がきました。コンフィグレーションを終了させ、コンパイル作業を開始しましょう:
root #make && make modules_installmake -jN とすることで、ビルドを並行処理させることができます（N には、並行処理を許可するビルドプロセスの数を指定します。/etc/portage/make.conf の説明中の、MAKEOPTS 変数についてと同様です。
カーネルのコンパイルが終了したら、カーネルイメージを / にコピーしてください。カーネルの選択に適した名前を使い、また名前を覚えておいてください。後にブートローダの設定で必要です。vmlinuz をインストールされたカーネルの名前とバージョンに置換するのを忘れないでください。
root #cp vmlinux.gz /boot/vmlinuz
非推奨: Genkernel
Genkernel は、Genkernel だけが満たすことができるニーズを持つ場合のみ検討されるべきです。そうでない場合は、ディストリビューションカーネルを使用するか自身で手動でコンパイルすることで Gentoo システムの維持がずっと単純になるので、そうすることが推奨されます。genkernel のほうが管理しづらい理由の例のひとつは、sys-kernel/installkernel との統合の欠如です。これは、他の手法によって提供されるのと同じレベルの自動化を得られないだろうということを意味します; 例えば、Genkernel を使用する場合には Unified カーネルイメージを手動で作成する必要があるでしょう。
まだ Genkernel を使うことを希望するユーザは、さらなる情報に関しては Genkernel の記事を参照するべきです。
カーネルモジュール
利用可能なカーネルモジュールを一覧表示する
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、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
では、システムの設定に進み、インストールを続けましょう。