ハンドブック:SPARC/インストール/カーネル
任意自由選択: ファームウェアとマイクロコードのインストール
ファームウェア
提案: 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
カーネルのコンフィギュレーションとコンパイル
最初のブートでは dist-kernel を使用するのが懸命な選択かもしれません。システムの問題とカーネルコンフィグの問題を除外するための、とても簡潔な手法を提供しているからです。機能すると分かっているカーネルをフォールバックとして常に持っておくことは、デバッグの効率を高め、更新時にシステムがブートできなくなるかもという不安を緩和させるでしょう。
これで、カーネルソースを設定、コンパイルする準備が整いました。インストールの目的に応じてカーネルの管理のためのアプローチを 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、およびもし必要であれば他のコマンドを実行する形で、システム管理者による関与が必要です。この選択肢は、自分は 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.pemMODULES_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.pemroot #chmod 400 kernel_key.pem
ディストリビューションカーネルをインストールする
Gentoo パッチが当てられたカーネルをソースからビルドするには、次をタイプしてください:
root #emerge --ask sys-kernel/gentoo-kernelシステムの管理者として、カーネルのソースをローカルでコンパイルするのを避けたい場合は、代わりにコンパイル済みのカーネルイメージを使用することができます:
root #emerge --ask sys-kernel/gentoo-kernel-binsys-kernel/gentoo-kernel および sys-kernel/gentoo-kernel-bin のようなディストリビューションカーネルは、デフォルトでは、initramfs とともにインストールされることを想定しています。カーネルをインストールするために emerge を実行する前に、installkernel の節の記載に従って、initramfs ジェネレータ (Dracut など) を利用するように sys-kernel/installkernel が設定されていることを確認するべきです。
アップグレードと後処理
一度カーネルがインストールされたら、パッケージマネージャが自動的にカーネルを新しいバージョンに更新するでしょう。古いバージョンは、パッケージマネージャに古いパッケージを片付けるように指示するまで残ります。ディスク容量を再利用するためには、定期的に --depclean オプション付きで emerge を実行することで、古いパッケージを片付けることができます:
root #emerge --depcleanあるいは、古いカーネルのバージョンだけを片付けるには:
root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin設計として、emerge はカーネルビルドディレクトリのみを削除します。カーネルモジュールや、インストールされたカーネルイメージは削除しません。古いカーネルを完全に削除するためには、app-admin/eclean-kernel ツールを使用することができます。
インストール/アップグレード後タスク
ディストリビューションカーネルのアップグレードは、他のパッケージ (例: sys-fs/zfs-kmod または x11-drivers/nvidia-drivers) によってインストールされた外部カーネルモジュールに対して、自動的な再ビルドを発動させることができます。この自動化された挙動は dist-kernel USE フラグによって有効化されます。このフラグはまた、必要に応じて initramfs の再生成も発動させるでしょう。
ディストリビューションカーネルを使用する場合は、このフラグを /etc/portage/make.conf から有効化しておくことが強く推奨されます:
/etc/portage/make.confUSE=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
ディストリビューションカーネルを正常にインストールできたら、次の節に進むときです: 次はシステムの設定です。
カーネルソースのインストール
sparc ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、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
カーネルに対して利用可能な make の引数の一覧を確認するには、
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 ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。
アーキテクチャ固有のオプション
Activate the correct bus-support:
Console drivers --->
Frame-buffer support --->
[*] SBUS and UPA framebuffers
[*] Creator/Creator3D support (Only for UPA slot adapter used in many Ultras)
[*] CGsix (GX,TurboGX) support (Only for SBUS slot adapter used in many SPARCStations)
Of course enable support for the OBP:
Misc Linux/SPARC drivers --->
[*] /dev/openprom device support
Enable SCSI-specific support:
SCSI support --->
SCSI low-level drivers --->
<*> Sparc ESP Scsi Driver (Only for SPARC ESP on-board SCSI adapter)
<*> PTI Qlogic, ISP Driver (Only for SBUS SCSI controllers from PTI or QLogic)
<*> SYM53C8XX Version 2 SCSI support (Only for Ultra 60 on-board SCSI adapter)
To support the network card, select one of the following:
Network device support --->
Ethernet (10 or 100Mbit) --->
<*> Sun LANCE support (Only for SPARCStation, older Ultra systems, and as Sbus option)
<*> Sun Happy Meal 10/100baseT support (Only for Ultra; also supports "qfe" quad-ethernet on PCI and Sbus)
<*> DECchip Tulip (dc21x4x) PCI support (For some Netras, like N1)
Ethernet (1000Mbit) --->
<*> Broadcom Tigon3 support (Modern Netra, Sun Fire machines)
With a 4-port Ethernet machine (10/100 or 10/100/1000) the port order is different from the one used by Solaris. Use sys-apps/ethtool to check the port link status.
When using a qla2xxx disk controller, install sys-block/qla-fc-firmware and add support for loading external firmware.
Device Drivers --->
Generic Driver Options --->
() External firmware blobs to build into the kernel binary
() Firmware blobs root directory
Set "External firmware blobs" to ql2200_fw.bin and "Firmware blobs root directory" to /lib/firmware/.
コンパイルおよびインストール
カーネルのコンフィグレーションが完了し、コンパイルとインストールをする時がきました。コンフィグレーションを終了させ、コンパイル作業を開始しましょう:
root #make && make modules_installIt is possible to enable parallel builds using make -j N with N being the integer number of parallel tasks that the build process is allowed to launch. This is similar to the instructions about /etc/portage/make.conf earlier, with the MAKEOPTS variable.
When the kernel has finished compiling, check the size of the resulting file:
root #ls -lh arch/sparc/boot/image-rw-r--r-- 1 root root 2.4M Oct 25 14:38 image
If the (uncompressed) size is bigger than 7.5 MB, reconfigure the kernel until it doesn't exceed these limits. One way of accomplishing this is by having most kernel drivers compiled as modules. Ignoring this can lead to a non-booting kernel.
Also, if the kernel is just a tad too big, try stripping it using the strip command:
root #strip -R .comment -R .note arch/sparc/boot/imageFinally copy the kernel image to /boot/.
root #cp arch/sparc/boot/image /boot/kernel-6.6.21-gentoo
非推奨: 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
では、システムの設定に進み、インストールを続けましょう。