Gentoo Linux x86 ハンドブック: Gentoo をインストールする

This page is a translated version of the page Handbook:X86/Full/Installation and the translation is 100% complete.

はじめに

ようこそ

Gentoo へようこそ！ Gentoo は、ほぼすべてのアプリケーションまたはニーズに応じて自動的に最適化してカスタマイズできる、Linux ベースの自由なオペレーティングシステムです。Gentoo は自由なソフトウェアのエコシステムの上に成り立っており、内部をユーザに隠匿することがありません。

オープンさ

Gentoo の主要なツールはシンプルなプログラミング言語から構成されています。Gentoo のパッケージ管理システムである Portage は、Python で書かれています。Portage のためにパッケージ定義を提供する ebuild は、bash で書かれています。Gentoo ユーザは、Gentoo のすべての部分のソースコードを自由に確認、変更、向上させることができます。

デフォルトでは、バグ修正または Gentoo 内での相互運用性のために必要なときだけ、パッケージにパッチが当てられます。上流のプロジェクトが提供するソースコードをバイナリ形式にコンパイルすることによって、パッケージがインストールされます (コンパイル済みバイナリパッケージにも対応はしていますが)。Gentoo の設定はテキストアフィルによって行われます。

上述の理由などから: オープンさは設計原則として組み込まれています。

選択

選択もまた Gentoo の設計原則のひとつです。

Gentoo のインストール中、ハンドブック全体を通して選択は明らかにされます。システム管理者は、完全にサポートされているふたつの init システム (Gentoo 自身による OpenRC と Freedesktop.org の systemd)、ストレージディスクのためのパーティション構造、そのディスクで使うファイルシステム、ターゲットシステムのプロファイル、USE フラグを利用した、グローバルな (システム全体の) レベルまたはパッケージ単位レベルでの機能の削除と追加、ブートローダ、ネットワーク管理ユーティリティ、などなど非常に多くのことに関して選択権を持っています。

開発思想として、Gentoo 開発者はユーザを特定のシステムプロファイルまたはデスクトップ環境を押し付けることが無いように努めています。GNU/Linux のエコシステム内で提供されるものは、Gentoo でもおそらく利用可能です。そうでない場合は、是非確認させてください。新しいパッケージのリクエストのためには、バグレポートを開くか、自身の ebuild リポジトリを作成してください。

性能

Gentoo はソースベースのオペレーティングシステムなので、新しいコンピュータ命令セットアーキテクチャにも移植することができ、かつインストールされたすべてのパッケージを調整された状態にすることができます。この強みはもうひとつの Gentoo の設計原則、性能の表れでもあります。

Gentoo のインストールとカスタマイズを完了することができれば、システム管理者はソースコードからコンパイルして調整されたオペレーティングシステムを得られます。Portage の make.conf ファイル内に含まれている仕組みを通じて、オペレーティングシステム全体をバイナリレベルで調整することができます。のぞむなら、パッケージ単位またはパッケージグループ単位での調整も行えます。実際のところ、すべての機能は USE フラグを利用して追加または削除することができます。

これらの設計原則が Gentoo をユニークにしているものであることを、ハンドブック読者が理解していることは、きわめて重要です。この優れた性能、多数の選択肢、そして究極のオープンさを強調しているため、Gentoo を使用するときは、注意力、熟慮、そして明確な意図を持って行うべきです。

インストール作業の順序

Gentoo のインストール作業工程は、次章以降で説明する10のステップに分けられます。それぞれの段階を適切に完了させましょう。

ステップ	結果
1	Gentoo をインストール可能な作業環境にします。
2	Gentoo をインストールするためのインターネット接続の準備が完了します。
3	インストールする Gentoo をホストするハードディスクを初期化します。
4	インストールする環境を準備し、新たな環境にユーザーが chroot 可能にします。
5	Gentoo をインストールする全ての場合に共通する中核的なパッケージをインストールします。
6	Linux カーネルをインストールします。
7	Gentoo システムの設定ファイルの大部分が作成されます。
8	必要なシステムツールをインストールします。
9	適切なブートローダーもインストールし設定します。
10	インストールしたての Gentoo Linux 環境に繰り出す準備が完了します。

このハンドブックでは、一定の選択肢を提示したときには必ず、賛否両論の併記に努めます。デフォルトの選択肢で進める記載をした際にも（見出しに「デフォルト:」と記載）、他に取りうる選択肢も記載します（見出しに「代替案:」と記載）。決して、「デフォルトは Gentoo のお勧めだ」と考えないでください。デフォルトはあくまでも、多くのユーザーが採用すると思われる選択肢にすぎません。

ときには、追加可能な手順が続くことがあります。そのような手順は「追加可能:」と記載します。つまりこの手順は、Gentoo のインストール自体には必須ではありません。とはいえ、以前にした決断によっては必須になる追加手順もあります。その際には、その追加手順の説明の直前に、この旨を明記するとともに、原因となった決断をした時期も記載します。

Gentoo のインストール方法

Gentoo は、さまざまな方法でインストールすることができます。ダウンロードしてインストールすることも、起動可能なISOイメージのような公式インストールメディアからインストールすることもできます。インストールメディアは USB メモリにインストールすることも、ネットワークブートすることもできます。さらには、インストール済の異なるディストリビューション環境や、（例えば Knoppix のような）Gentoo 以外のブータブルディスクといった非公式メディアからインストールすることも可能です。

この文書が扱っているのは、公式の Gentoo インストールメディアを用いる方法と、場合によってはネットワークブートによる方法です。

メモ
Gentoo 以外の起動可能なメディアを用いる場合などの、ほかのインストール方法については、代替のインストールガイドを読んでください。

また、我々が提供している Gentoo インストールのヒントとトリックという文書も役にたつかもしれません。

トラブルがあったときは

インストール中に (またはインストールを説明しているハンドブックに) 何か問題を見つけたら、バグトラッキングシステムで既知のバグとして報告されていないかどうか、確認してみてください。もし無いようであれば、私たちが対応できるように、その問題をバグ報告してください。その (あなたが報告した) バグを担当する開発者たちを恐れないでください。取って喰われるようなことは (滅多に) ありませんから。

あなたが今読んでいる文書は、特定のアーキテクチャ向けということになっていますが、他のアーキテクチャの情報も、その中に紛れ込んでしまっているかもしれない、ということを一応、先に言っておきます。これはGentooハンドブックの多くの部分が、全てのアーキテクチャに共通のテキストを使用していることに因ります (重複作業を減らすため)。混乱しないように、このような参照は最小限に抑えています。

その問題が、ユーザーの問題 (文書をよく読んだにもかかわらず起きたあなたのミス) なのか、ソフトウェアの問題 (インストール/文書をよくテストしたにもかかわらず起きた私たちのミス) なのか、はっきりしないときには、irc.libera.chat の #gentoo (webchat) チャンネルに気軽に参加してみてください。そんなときじゃなくても全然かまわないんですけどね。

そういえば、Gentoo について何か分からないことがあったら、よくある質問を見てみてください。Gentoo Forums 上にある FAQs もあります。

ハードウェア要件

インストールのプロセスに進む前に、x86 システムアーキテクチャに対して首尾よく Gentoo をインストールするためには、最小ハードウェア要件を満たすべきです。

	Minimal CD	LiveDVD
CPU	i486 以降	i686 以降
メモリ	256 MB	512 MB
ディスク領域	2.5 GB (スワップ領域を除く)
スワップ領域	少なくとも 256 MB

X86 project は、Gentoo の x86 対応についての詳細を知るのに良い場所です。

Gentoo Linux インストールメディア

ヒント
インストール時には公式の Gentoo ブートメディアを使用することが推奨されますが、他のインストール環境を使用することもできます。ですが、それらに必要なコンポーネントが含まれる保証はありません。異なるインストール環境を使用する場合は、ディスクの準備に移動してください。

Minimal インストール CD

Gentoo Minimal インストール CDは、自己完結した Gentoo 環境である、小さなブート可能イメージです。このイメージは Gentoo 開発者たちによって保守されており、インターネット接続さえあれば誰でも Gentoo をインストールできるように設計されています。ブートプロセス中に、接続されているハードウェアが検出され、適切なドライバが自動的にロードされます。

Minimal インストール CD のリリースは、install-<アーキテクチャ>-minimal-<リリース時刻>.iso のフォーマットで命名されています。

Gentoo LiveGUI

ユーザの中には、KDE デスクトップ環境を提供する LiveGUI を使用して Gentoo をインストールするほうが、簡単だと思うユーザもいるかもしれません。LiveGUI は、便利なグラフィカル環境を提供しているのに加えて、現代の Wi-Fi チップセットを使用する助けとなるかもしれない、より多くのカーネルモジュールとファームウェアを備えています。

メモ
Gentoo LiveGUI USB イメージは amd64 および arm64 プラットフォーム向けに週ごとにビルドされています。

stage ファイルとは?

stage ファイルは、Gentoo 環境のための種として機能するアーカイブです。

stage 3 ファイルは、公式 Gentoo ミラーのいずれかのreleases/x86/autobuilds/からダウンロードできます。stage は頻繁に更新されるので、公式 live イメージの中には含まれていません。

ヒント
今のところ、stage ファイルは無視して構いません。後で必要に応じてより詳細に説明します。

メモ
歴史的には、ハンドブックは 3 より低いバージョンの stage ファイルのインストール手順について記述していました。これらの stage は典型的なシステムのインストールには適さない環境を含んでおり、今はハンドブックでは取り扱っていません。

ダウンロード

メディアの入手

Gentoo Linux が使う既定のインストールメディアは Minimal インストール CD で、とても小さいブータブル Gentoo Linux 環境を提供しています。この環境は Gentoo をインストールするために必要なツールを含んでいます。このイメージは、ダウンロードページから（推奨）か、たくさんの利用可能なミラーのいずれかを自分で選び、そのミラー上で ISO が置いてある場所を訪れることで、ダウンロードできます。

Gentoo ミラーに移動する

ミラーからダウンロードするなら、次のようにして Minimal インストール CD を見つけられます:

典型的には Gentoo source mirrors で見つかる利用地域のミラーを使用して、ミラーに接続する。
releases/ディレクトリに行く。
関連するターゲットアーキテクチャのディレクトリ（例えばx86/）を選択する。
autobuilds/ディレクトリを選択する。
amd64とx86アーキテクチャでは、それぞれcurrent-install-amd64-minimal/ or current-install-x86-minimal/のどちらかを選択する。他のすべてのアーキテクチャでは、current-iso/ディレクトリへ進む。

メモ
arm、mips、s390 のような一部のターゲットアーキテクチャには、Minimal インストール CD がありません。現時点では、Gentoo Release Engineering project はこれらのターゲット向けの .iso ファイルの作成をサポートしていません。

この場所の中では、インストールメディアファイルは.isoという接尾辞 (拡張子) を持ちます。例えば、以下の一覧を見てみてください。

コード releases/amd64/autobuilds/current-install-amd64-minimal/ でダウンロード可能なファイルの一覧の例

[TXT]	install-amd64-minimal-20231112T170154Z.iso.asc	        2023-11-12 20:41        488
[TXT]	install-amd64-minimal-20231119T164701Z.iso.asc	        2023-11-19 18:41        488
[TXT]	install-amd64-minimal-20231126T163200Z.iso.asc	        2023-11-26 18:41        488
[TXT]	install-amd64-minimal-20231203T170204Z.iso.asc	        2023-12-03 18:41        488
[TXT]	install-amd64-minimal-20231210T170356Z.iso.asc	        2023-12-10 19:01        488
[TXT]	install-amd64-minimal-20231217T170203Z.iso.asc	        2023-12-17 20:01        488
[TXT]	install-amd64-minimal-20231224T164659Z.iso.asc	        2023-12-24 20:41        488
[TXT]	install-amd64-minimal-20231231T163203Z.iso.asc	        2023-12-31 19:01        488
[ ]     install-amd64-minimal-20240107T170309Z.iso              2024-01-07 20:42        466M
[ ]     install-amd64-minimal-20240107T170309Z.iso.CONTENTS.gz	2024-01-07 20:42        9.8K
[ ]     install-amd64-minimal-20240107T170309Z.iso.DIGESTS      2024-01-07 21:01        1.3K
[TXT]   install-amd64-minimal-20240107T170309Z.iso.asc	        2024-01-07 21:01        488
[ ]     install-amd64-minimal-20240107T170309Z.iso.sha256       2024-01-07 21:01        660
[TXT]	latest-install-amd64-minimal.txt                        2024-01-08 02:01        653

上記の例では、install-amd64-minimal-20240107T170309Z.isoというファイルが Minimal インストール CD そのものです。しかし見て分かりますが、他の関係ファイルも存在しています:

.CONTENTS.gz ファイルは、インストールメディアで利用可能な全てのファイルの一覧を含む、gz 圧縮されたテキストファイルです。このファイルは、インストールメディアをダウンロードする前に、特定のファームウェアまたはドライバが含まれているかどうか調べるために使用できます。
.DIGESTS ファイルは、様々なハッシュ形式とアルゴリズムで計算した ISO ファイルのハッシュ値を含んでいます。このファイルは、ISO ファイルの完全性を検証するために使用できます。
.asc ファイルは、ISO ファイルのデジタル署名です。これはイメージの完全性と真正性 (Gentoo リリースエンジニアリングチームによって実際に提供されたものであり、改竄されていないこと) を検証するために使用できます。

今のところ、この場所で利用可能な他のファイルは無視してください。インストールがもっと進んだ後に再登場しますので。.isoファイルをダウンロードし、もしダウンロードの検証が必要であれば、.isoファイル用の.iso.ascファイルも同じようにダウンロードします。

ヒント
.DIGESTS ファイルは .iso.asc ファイル内の署名を検証しない場合のみ必要です。

ダウンロードしたファイルを検証する

メモ
これは任意自由選択なステップで、Gentoo Linux をインストールするために必須なものではありません。しかしながら、ダウンロードしたファイルが破損していないことを確かめ、Gentoo インフラストラクチャチームから実際に提供されていることを保証するため、推奨されます。

.asc ファイルは ISO のデジタル署名を提供します。これを検証することで、インストール・ファイルが Gentoo リリースエンジニアリングチームによって提供された状態のまま、変更されていないということを確認できます。

Microsoft Windows 上での検証

まずデジタル署名を検証するには、例えばGPG4Winのようなツールを利用できます。インストール後、Gentooリリースエンジニアリングチームの公開鍵をインポートする必要があります。鍵の一覧は署名のページで提供されています。インポート後、ユーザは.ascファイル内の署名を検証できるようになります。

Linux 上での検証

Linuxシステムでは、デジタル署名を検証する最も一般的な方法はapp-crypt/gnupgソフトウェアを使うことです。このパッケージがインストールされていると、.ascファイル内のデジタル署名を検証するために以下のコマンドが使えます。

ヒント
Gentoo 鍵をインポートするときには、フィンガープリント (BB572E0E2D182910) が合致していることを検証してください。

Gentoo 鍵は、署名のページで利用可能なフィンガープリントを使用して、hkps://keys.gentoo.org からダウンロードすることができます:

user $gpg --keyserver hkps://keys.gentoo.org --recv-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910

gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

代わりに、WKD を使用してダウンロードすることも可能です:

user $gpg --auto-key-locate=clear,nodefault,wkd --locate-key releng@gentoo.org

gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
pub   dsa1024 2004-07-20 [SC] [expires: 2025-07-01]
      D99EAC7379A850BCE47DA5F29E6438C817072058
uid           [ unknown] Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>
sub   elg2048 2004-07-20 [E] [expires: 2025-07-01]

または、公式 Gentoo リリースメディアを使用している場合は、(sec-keys/openpgp-keys-gentoo-release によって提供される) /usr/share/openpgp-keys/gentoo-release.asc から鍵をインポートしてください:

user $gpg --import /usr/share/openpgp-keys/gentoo-release.asc

gpg: directory '/home/larry/.gnupg' created
gpg: keybox '/home/larry/.gnupg/pubring.kbx' created
gpg: key DB6B8C1F96D8BF6D: 2 signatures not checked due to missing keys
gpg: /home/larry/.gnupg/trustdb.gpg: trustdb created
gpg: key DB6B8C1F96D8BF6D: public key "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" imported
gpg: key 9E6438C817072058: 3 signatures not checked due to missing keys
gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported
gpg: key BB572E0E2D182910: 1 signature not checked due to a missing key
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: key A13D0EF1914E7A72: 1 signature not checked due to a missing key
gpg: key A13D0EF1914E7A72: public key "Gentoo repository mirrors (automated git signing key) <repomirrorci@gentoo.org>" imported
gpg: Total number processed: 4
gpg:               imported: 4
gpg: no ultimately trusted keys found

次にデジタル署名を検証します:

user $gpg --verify install-x86-minimal-20240107T170309Z.iso.asc

gpg: assuming signed data in 'install-x86-minimal-20240107T170309Z.iso'
gpg: Signature made Sun 07 Jan 2024 03:01:10 PM CST
gpg:                using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D
gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910
     Subkey fingerprint: 534E 4209 AB49 EEE1 C19D  9616 2C44 695D B9F6 043D

すべてが確実であることを完全に確かめるために、表示された指紋がGentooの署名のページ上にある指紋かどうかを調べます。

メモ
インポートされた鍵が信頼に足ると確証が持てたら、その鍵を信頼されたものとしてマークすることは、一般的に良いプラクティスです。信頼された鍵が検証されるときには、gpg は unknown とは表示せず、署名が信頼済みでないという警告も発さないでしょう。

ブートメディアを書き込む

もちろん、ISO ファイルをダウンロードしただけでは、Gentoo Linux のインストールは始められません。ISO ファイルはブート可能なメディアに書き込む必要があります。このためには通常、イメージをファイルシステムに展開する、あるいはデバイスに直接書き込む必要があります。

ブータブル USB を書き込む

現代的なシステムの多くは、USB デバイスからのブートをサポートしています。

Linux で書き込む

dd は典型的に多くの Linux ディストリビューションで利用可能であり、Gentoo ブートメディアを USB ドライブに書き込むために使用することができます。

USB デバイスパスを決定する

書き込む前に、書き込みたいストレージデバイスへのパスを決定する必要があります。

dmesg は、ストレージデバイスがシステムに追加されるのに応じて、デバイスを記述する詳細な情報を表示するでしょう:

root #dmesg

[268385.319745] sd 19:0:0:0: [sdd] 60628992 512-byte logical blocks: (31.0 GB/28.9 GiB)

または、lsblk を使用して利用可能なストレージデバイスを表示することができます:

root #lsblk

sdd           8:48   1  28.9G  0 disk
├─sdd1        8:49   1   246K  0 part
├─sdd2        8:50   1   2.8M  0 part
├─sdd3        8:51   1 463.5M  0 part
└─sdd4        8:52   1   300K  0 part

デバイス名が決定されたら、その前にパス接頭辞 /dev/ を追加して、デバイスパス /dev/sdd を得ることができます。

ヒント
Gentoo ブートメディアは GPT パーティションスキームを完全に含むため、ベースデバイスパス (sdd1 ではなく sdd) を使用することが推奨されます。

dd で書き込む

警告
ターゲットは上書きされるので、dd を実行する前に、ターゲット (of=target) のパスを確認するようにしてください。

デバイスパス (/dev/sdd) とブートメディア install-amd64-minimal-<release timestamp>.iso の準備ができたら:

root #dd if=install-amd64-minimal-<release timestamp>.iso of=/dev/sdd bs=4096 status=progress && sync

メモ
if= は入力ファイルを指定し、of= は出力ファイルを指定します。この場合では出力ファイルはデバイスです。

ヒント
転送を高速化するため、多くの場合 bs=4096 が使用されます。 status=progress は転送の統計情報を表示します。

ディスクに書き込む

関連
より詳しい手順は CD/DVD/BD_writing#Image_writing で見つけられます。

Microsoft Windows 7 以降での書き込み

Microsoft Windows 7 以降のバージョンでは、サードパーティ製のソフトウェアを必要とすることなく、ISO イメージをマウントし書き込むことができます。単純に書き込み可能なディスクを挿入し、ダウンロードした ISO ファイルをブラウズし、右クリックして「ディスクイメージの書き込み」を選択してください。

Linux での書き込み

Linuxでは、app-cdr/cdrtoolsパッケージにあるcdrecordユーティリティで、ISOイメージを書き込みことができます。

/dev/sr0デバイス（これはシステム上の1番目のCDデバイスです。必要ならば正しいデバイスに置き換えてください）のCDにISOファイルを書き込むには：

user $cdrecord dev=/dev/sr0 install-x86-minimal-20141204.iso

GUIを好むユーザーはkde-apps/k3bパッケージの一部であるK3Bを使うことができます。K3Bでは、ToolsメニューからBurn CD Imageを選択してください。

起動する

Booting the installation media

Once the installation media is ready, it is time to boot it. Insert the media in the system, reboot, and enter the motherboard's firmware user interface. This is usually performed by pressing a keyboard key such as DEL, F1, F10, or ESC during the Power-On Self-Test (POST) process. The 'trigger' key varies depending on the system and motherboard. If it is not obvious use an internet search engine and do some research using the motherboard's model name as the search keyword. Results should be easy to determine. Once inside the motherboard's firmware menu, change the boot order so that the external bootable media (CD/DVD disks or USB drives) are tried before the internal disk devices. Without this change, the system will most likely reboot to the internal disk device, ignoring the newly attached bootable media.

重要
When installing Gentoo on a system with an UEFI firmware interface, ensure the live image has been booted in UEFI mode. In the accidental event that DOS/legacy BIOS boot was initiated, then it will be necessary to reboot in UEFI mode before finalizing the Gentoo Linux installation.

Ensure that the installation media is inserted or plugged into the system, and reboot. A GRUB boot prompt should be shown with various boot entries. At this screen, Enter will begin the boot process with the default boot options. To boot the installation media with customized boot options, such as passing additional kernel parameters or the following hardware options, highlight a boot entry, then press the e key to edit the boot entry. Make the necessary modification(s), then press ctrl+x or F10 to boot the modified entry.

メモ
In all likelihood, the default gentoo kernel, as mentioned above, without specifying any of the optional parameters will work just fine. For boot troubleshooting and expert options, continue on with this section. Otherwise, just press Enter and skip ahead to Extra hardware configuration.

At the boot prompt, users get the option of displaying the available kernels (F1) and boot options (F2). If no choice is made within 15 seconds (either displaying information or using a kernel) then the installation media will fall back to booting from disk. This allows installations to reboot and try out their installed environment without the need to remove the CD from the tray (something well appreciated for remote installations).

Specifying a kernel was mentioned. On the Minimal installation media, only two predefined kernel boot entries are provided. The default option is called gentoo. The other being the -nofb variant; this disables kernel framebuffer support.

The next section displays a short overview of the available kernels and their descriptions:

Kernel choices

gentoo: Default kernel with support for K8 CPUs (including NUMA support) and EM64T CPUs.
gentoo-nofb: Same as gentoo but without framebuffer support.
memtest86: Test the system RAM for errors.

Alongside the kernel, boot options help in tuning the boot process further.

Hardware options

acpi=on: This loads support for ACPI and also causes the acpid daemon to be started by the CD on boot. This is only needed if the system requires ACPI to function properly. This is not required for Hyperthreading support.
acpi=off: Completely disables ACPI. This is useful on some older systems and is also a requirement for using APM. This will disable any Hyperthreading support of your processor.
console=X: This sets up serial console access for the CD. The first option is the device, usually ttyS0, followed by any connection options, which are comma separated. The default options are 9600,8,n,1.
dmraid=X: This allows for passing options to the device-mapper RAID subsystem. Options should be encapsulated in quotes.
doapm: This loads APM driver support. This also requires that acpi=off.
dopcmcia: This loads support for PCMCIA and Cardbus hardware and also causes the pcmcia cardmgr to be started by the CD on boot. This is only required when booting from PCMCIA/Cardbus devices.
doscsi: This loads support for most SCSI controllers. This is also a requirement for booting most USB devices, as they use the SCSI subsystem of the kernel.
sda=stroke: This allows the user to partition the whole hard disk even when the BIOS is unable to handle large disks. This option is only used on machines with an older BIOS. Replace sda with the device that requires this option.
ide=nodma: This forces the disabling of DMA in the kernel and is required by some IDE chipsets and also by some CDROM drives. If the system is having trouble reading from the IDE CDROM, try this option. This also disables the default hdparm settings from being executed.
noapic: This disables the Advanced Programmable Interrupt Controller that is present on newer motherboards. It has been known to cause some problems on older hardware.
nodetect: This disables all of the autodetection done by the CD, including device autodetection and DHCP probing. This is useful for debugging a failing CD or driver.
nodhcp: This disables DHCP probing on detected network cards. This is useful on networks with only static addresses.
nodmraid: Disables support for device-mapper RAID, such as that used for on-board IDE/SATA RAID controllers.
nofirewire: This disables the loading of Firewire modules. This should only be necessary if your Firewire hardware is causing a problem with booting the CD.
nogpm: This disables gpm console mouse support.
nohotplug: This disables the loading of the hotplug and coldplug init scripts at boot. This is useful for debugging a failing CD or driver.
nokeymap: This disables the keymap selection used to select non-US keyboard layouts.
nolapic: This disables the local APIC on Uniprocessor kernels.
nosata: This disables the loading of Serial ATA modules. This is used if the system is having problems with the SATA subsystem.
nosmp: This disables SMP, or Symmetric Multiprocessing, on SMP-enabled kernels. This is useful for debugging SMP-related issues with certain drivers and motherboards.
nosound: This disables sound support and volume setting. This is useful for systems where sound support causes problems.
nousb: This disables the autoloading of USB modules. This is useful for debugging USB issues.
slowusb: This adds some extra pauses into the boot process for slow USB CDROMs, like in the IBM BladeCenter.

Logical volume/device management

dolvm: This enables support for Linux's Logical Volume Management.

Other options

debug: Enables debugging code. This might get messy, as it displays a lot of data to the screen.
docache: This caches the entire runtime portion of the CD into RAM, which allows the user to umount /mnt/cdrom and mount another CDROM. This option requires that there is at least twice as much available RAM as the size of the CD.
doload=X: This causes the initial ramdisk to load any module listed, as well as dependencies. Replace X with the module name. Multiple modules can be specified by a comma-separated list.
dosshd: Starts sshd on boot, which is useful for unattended installs.
passwd=foo: Sets whatever follows the equals as the root password, which is required for dosshd since the root password is by default scrambled.
noload=X: This causes the initial ramdisk to skip the loading of a specific module that may be causing a problem. Syntax matches that of doload.
nonfs: Disables the starting of portmap/nfsmount on boot.
nox: This causes an X-enabled LiveCD to not automatically start X, but rather, to drop to the command line instead.
scandelay: This causes the CD to pause for 10 seconds during certain portions the boot process to allow for devices that are slow to initialize to be ready for use.
scandelay=X: This allows the user to specify a given delay, in seconds, to be added to certain portions of the boot process to allow for devices that are slow to initialize to be ready for use. Replace X with the number of seconds to pause.

メモ
The bootable media will check for no* options before do* options, so that options can be overridden in the exact order specified.

Now boot the media, select a kernel (if the default gentoo kernel does not suffice) and boot options. As an example, we boot the gentoo kernel, with dopcmcia as a kernel parameter:

boot:gentoo dopcmcia

Next the user will be greeted with a boot screen and progress bar. If the installation is done on a system with a non-US keyboard, make sure to immediately press Alt+F1 to switch to verbose mode and follow the prompt. If no selection is made in 10 seconds the default (US keyboard) will be accepted and the boot process will continue. Once the boot process completes, the user is automatically logged in to the "Live" Gentoo Linux environment as the root user, the super user. A root prompt is displayed on the current console, and one can switch to other consoles by pressing Alt+F2, Alt+F3 and Alt+F4. Get back to the one started on by pressing Alt+F1.

例外的なハードウェア構成

インストールメディアが起動するとき、すべてのハードウェア機器を検出して適切なカーネルモジュールを読み込もうとします。これは非常に多くの場合、とても良い仕事をします。しかしある場合において、システムに必要なカーネルモジュールを自動で読み込まないかもしれません。PCI自動検出機能がシステムのハードウェアを見逃した場合、適切なカーネルモジュールを手動で読み込む必要があります。

次の例は、(ある種類のネットワークインタフェイスをサポートする) 8139tooモジュールを読み込みます:

root #modprobe 8139too

追加可能: ユーザアカウント

インストール環境に他の人たちがアクセスする必要があったり、インストールメディア上で非rootユーザでコマンドを実行する（例えば、セキュリティ上の理由から、root権限無しでirssiを使ってチャットする）必要があるなら、別のユーザアカウントを作成し、強いrootパスワードを設定する必要があります。

rootパスワードを変更するには、passwdユーティリティを使ってください:

root #passwd

New password: (新しいパスワードを入力)
Re-enter password: (もう一度新しいパスワードを入力)

ユーザーアカウントを作成するためには、まずアカウントの資格情報を、次にパスワードを入力します。このために、useraddとpasswdコマンドを使います。

次の例では、johnというユーザが作成されます:

root #

useradd -m -G users john

root #passwd john

New password: (Enter john's password)
Re-enter password: (Re-enter john's password)

現在のrootユーザから新しく作成したユーザアカウントに切り替えるには、suコマンドを使ってください:

root #su - john

追加可能：インストール中のドキュメント閲覧

TTY

インストール中に Gentoo ハンドブックを TTY から見るには、最初に上記の方法でユーザアカウントを作成し、Alt+F2 を押すことで新しい端末 (TTY) に移動し、新しく作成したユーザとしてログインしてください。最小権限の原則に従って、必要以上に高い権限で web をブラウズしたり、一般的に任意のタスクを実行したりするのは避けるのがベストプラクティスです。root アカウントはシステムの完全な制御を行うことができるので、慎重に使用しなくてはなりません。

インストール中、links web ブラウザで Gentoo ハンドブックを閲覧できます。もちろん、インターネット接続が機能し始めた瞬間からですけど。

user $links https://wiki.gentoo.org/wiki/Handbook:X86/ja

元々の端末に戻るには、Alt+F1を押してください。

ヒント
Gentoo minimal または Gentoo 管理環境にブートすると、7 つの TTY が利用できるでしょう。Alt を押しながらファンクションキー F1-F7 を押すことで切り換えることができます。作業が完了するのを待ちながらドキュメントを開きたいときなどは、ターミナルを切り換えると便利でしょう。

GNU Screen

公式 Gentoo インストールメディアにはデフォルトで Screen ユーティリティがインストールされています。熟練の Linux ファンにとっては、上に書いた複数の TTY を使う方法よりも、ペインを分割してインストール指示を読むために screen を使うほうが効率がいいかもしれません。

追加可能：SSH デーモンの開始

インストール中に他のユーザーがシステムにアクセスできるようにする (インストール中の援助を提供したり受け取ったり、あるいは全て遠隔操作で行う) ためには、(前述の通り) ユーザーアカウントを作成し、SSH デーモンを起動する必要があります。

OpenRC 上で SSH デーモンを始動させるためには、次のコマンドを実行します:

root #rc-service sshd start

メモ
ユーザーがシステムにログオンすると、(指紋・fingerprint と呼ばれるもので) ホスト鍵を確認するようメッセージが表示されると思います。これはSSHサーバーへの最初の接続では期待される典型的な挙動です。ところが、この後の手順でシステムのセットアップが完了した後、改めてログオンしようとすると、SSHクライアントはホスト鍵が変更されていると警告します。SSH的には別のサーバー (現在インストールに使っているLive環境ではなく、新しくインストールされた Gentoo システム) にログオンしようとしているように見えるのです。この場合は画面上の指示に従い、クライアント側で記憶しているホスト鍵を更新しましょう。

sshd を使えるようにするには、ネットワークを適切に機能させる必要があります。ネットワーク設定の章を参照してください。

← Gentoo Linux のインストールについて Home ネットワーク設定 →

ネットワークの自動構成

もしかすると、もう機能していますか？

もしあなたのシステムが、IPv6 ルータか DHCP サーバを持つ Ethernet ネットワークに接続されているなら、おそらくシステムのネットワークは自動的に構成されているでしょう。追加の高度な構成が必要でない場合は、インターネット接続をテストすることができます。

DHCP を使う

DHCP (Dynamic Host Configuration Protocol) は、ネットワークの構成を支援し、IPアドレス、ネットワークマスク、ルート、DNS サーバ、NTP サーバ等を含む、さまざまなパラメータのための構成を自動で提供することができます。

DHCP は、クライアントがリースを要求するために、同一のレイヤ 2 (Ethernet) セグメント上でサーバが実行中である必要があります。DHCP はよく RFC1918 (プライベート) ネットワーク上で使用されますが、ISP からパブリック IP 情報を取得するためにも使用されます。

ヒント
公式 Gentoo ブートメディアは起動時に dhcpcd を自動的に実行します。この挙動は、ブートメディアのカーネルコマンドラインに nodhcp 引数を追加することで、無効化することができます。

すでに実行されていない場合は、以下で dhcpcd を enp1s0 に対して開始することができます:

root #dhcpcd enp1s0

DHCP サーバが提供するホスト名とドメイン名をシステムで使うようにと、ネットワーク管理者から要求されている場合もあるでしょう。そのような場合には:

root #dhcpcd -HD enp1s0

dhcpcd を停止するには、-x を使用することができます:

root #dhcpcd -x

sending signal Term to pid 10831
waiting for pid 10831 to exit

ネットワークのテスト

デフォルトルートが適切に構成されていることは、インターネット接続の重要な構成要素です。ルート構成は以下で確認できます:

root #ip route

default via 192.168.0.1 dev enp1s0

デフォルトルートが定義されていないと、インターネット接続は利用できず、追加の構成が必要になります。

基本的なインターネット接続は ping で確認することができます:

root #ping -c 3 1.1.1.1

ヒント
ホスト名ではなく、既知の IP アドレスに ping することから始めるとよいでしょう。これにより、DNS の問題を他の基本的なインターネット接続の問題から切り分けることができます。

外向きの HTTPS アクセスと DNS 解決は、次で確認することができます:

root #curl --location gentoo.org --output /dev/null

curl がエラーを報告したり、他のテストが失敗したりしない場合は、インストールプロセスをディスクの準備から続けることができます。

curl がエラーを報告するのに、インターネットへの ping が機能する場合は、DNS を構成する必要があるかもしれません。

インターネット接続が確立されていない場合は、まずインターフェース情報を検証すべきです。そして:

net-setup を使用してネットワーク構成を支援することができます。
アプリケーション固有の構成が必要かもしれません。
手動でのネットワーク構成を試すことができます。

インターフェースの情報を取得する

そのままの状態でネットワークが機能していない場合は、インターネット接続を有効化するために追加の段階を踏む必要があります。一般的に、最初の段階はホストのネットワークインターフェースを列挙することです。

sys-apps/iproute2 パッケージに含まれる ip コマンドは、システムネットワークの情報の問い合わせと、構成のために使用することができます。

link 引数を使用して、ネットワークインターフェースのリンクを表示することができます:

root #ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff

address 引数を使用して、デバイスのアドレス情報を問い合わせることができます:

root #ip address

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<pre>
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.77/22 brd 10.0.23.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::ea40:f2ff:feac:257a/64 scope link 
       valid_lft forever preferred_lft forever

このコマンドの出力は、システム上の各ネットワークインターフェースごとの情報を含んでいます。エントリはデバイスのインデックス番号で始まり、デバイス名 (enp1s0) が続きます。

ヒント
lo (loopback) 以外のインターフェースが表示されない場合は、ネットワークハードウェアに問題があるか、そのインターフェースのためのドライバがカーネルにロードされていないかです。どちらの状況も、このハンドブックの対象範囲を外れています。#gentoo (webchat) に助けを求めてください。

一貫性のために、このハンドブックではメインのネットワークインターフェース名は enp1s0 であると仮定します。

メモ
predictable network interface names へ移行した結果、システム上のインターフェース名は古い命名規則による eth0 とはかなり違うものになっているかもしれません。現代的な Gentoo ブートメディアは、eno0 や ens1 や enp5s0 などで始まるインターフェース名を使用します。

追加可能: アプリケーション固有の構成

以下の手法は一般的に必要ではありませんが、インターネット接続のために追加の構成が必要な状況では、役に立つことがあります。

web プロキシを設定する

web プロキシを経由してインターネットにアクセスしている場合は、Portage が対応している各プロトコルごとに正しくプロキシにアクセスできるように、プロキシ情報を定義する必要があります。Portage は wget および rsync の取得手法を介してパッケージをダウンロードするために、http_proxy、ftp_proxy、および RSYNC_PROXY 環境変数を参照します。

links など、特定のテキストモード web ブラウザも、web プロキシ設定を定義する環境変数を利用することができます。特に、HTTPS アクセスのために https_proxy 環境変数も定義する必要があるでしょう。Portage は追加の実行時パラメータを渡さなくても影響を受けますが、links にはプロキシ設定のパラメータを設定する必要があるでしょう。

ほとんどの場合、プロキシサーバのホスト名を使って環境変数を定義するだけで十分です。以下の例では、プロキシサーバのホスト名は proxy.gentoo.org、ポート番号は 8080 であるとしましょう。

メモ
以下のコマンド中の # 記号はコメントです。これらは説明のためだけに追加されているもので、コマンドを入力するときに打ち込む必要はありません。

HTTP プロキシ (HTTP と HTTPS 通信のため) を定義するには:

root #

export http_proxy="http://proxy.gentoo.org:8080" #  Portage と Links に適用されます

root #

export https_proxy="http://proxy.gentoo.org:8080" # Links にのみ適用されます

HTTP プロキシが認証を必要とする場合は、次の構文でユーザ名とパスワードを設定してください:

root #

export http_proxy="http://username:password@proxy.gentoo.org:8080" #  Portage と Links に適用されます

root #

export https_proxy="http://username:password@proxy.gentoo.org:8080" # Links にのみ適用されます

プロキシサポートのためには以下のパラメータを使用して links を開始します:

user $links -http-proxy ${http_proxy} -https-proxy ${https_proxy}

Portage と links のために FTP プロキシを定義するには:

root #export ftp_proxy="ftp://proxy.gentoo.org:8080" # Portage と Links に適用されます

FTP プロキシのためには以下のパラメータを使用して links を開始します:

user $links -ftp-proxy ${ftp_proxy}

Portage のために RSYNC プロキシを定義するには:

root #

export RSYNC_PROXY="proxy.gentoo.org:8080" # Portage に適用されます; Links は rsync プロキシをサポートしていません

ADSL のために pppoe-setup を使う

インターネットアクセスのために PPPoE が必要な場合、Gentoo ブートメディアには ppp 構成を簡単にするための pppoe-setup スクリプトが含まれています。

セットアップの中で、pppoe-setup は以下のことを聞いてくるでしょう:

ADSL モデムに接続されている Ethernet インターフェースの名前。
PPPoE ユーザ名とパスワード。
DNS サーバの IP。
ファイアウォールが必要かどうか。

root #

pppoe-setup

root #pppoe-start

失敗した場合は、/etc/ppp/pap-secrets または /etc/ppp/chap-secrets の証明書を検証すべきです。証明書が正しい場合は、PPPoE Ethernet インターフェースの選択を確認すべきです。

PPTP を使う

PPTP サポートが必要なら、インストール CD が提供する pptpclient を使用することができますが、使用の前に構成を行う必要があります。

/etc/ppp/pap-secrets または /etc/ppp/chap-secrets を編集して、正しいユーザ名/パスワードの組み合わせを設定してください:

root #nano /etc/ppp/chap-secrets

必要ならば/etc/ppp/options.pptpを修正してください：

root #nano /etc/ppp/options.pptp

構成が完了したら、pptp を (options.pptp で設定できないオプションがあれば、それもいっしょに付けて) 実行し、サーバに接続します:

root #pptp <server ipv4 address>

WEP を構成する

警告
WEP が唯一の選択肢でない限り、WEP を使用しないでください。WEP は基本的に、オープンネットワーク上に何のセキュリティも提供しません。

重要
iw コマンドは以下のアーキテクチャ上でのみ利用可能です: amd64、x86、arm、arm64、ppc、ppc64、および riscv。

無線(802.11)カードを使っている場合には、まず第一に無線の設定をする必要があります。無線カードの現在の設定を確認するためには、iwを使うことができます。iwはこのようなものを表示するでしょう:

root #iw dev wlp9s0 info

Interface wlp9s0
	ifindex 3
	wdev 0x1
	addr 00:00:00:00:00:00
	type managed
	wiphy 0
	channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
	txpower 30.00 dBm

現在の接続を確認するには:

root #iw dev wlp9s0 link

Not connected.

または

root #iw dev wlp9s0 link

Connected to 00:00:00:00:00:00 (on wlp9s0)
	SSID: GentooNode
	freq: 2462
	RX: 3279 bytes (25 packets)
	TX: 1049 bytes (7 packets)
	signal: -23 dBm
	tx bitrate: 1.0 MBit/s

メモ
無線カードのデバイス名は、wlp9s0 の代わりに wlan0 または ra0 のような名前かもしれません。正しいデバイス名を調べるには、ip link を実行してください。

ほとんどのユーザにとって、接続するのに必要な設定は、ESSID（無線ネットワーク名とも言います）と、場合によってはWEPキー、この2つだけです。

まず、インターフェースがアクティブになっていることを確認してください:

root #ip link set dev wlp9s0 up

GentooNodeという名前のオープンネットワークに接続するには:

root #iw dev wlp9s0 connect -w GentooNode

16進WEPキーを使って接続するには、キーの前にd:を付けてください:

root #iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd

ASCII WEPキーで接続するには:

root #iw dev wlp9s0 connect -w GentooNode key 0:some-password

メモ
無線ネットワークが WPA または WPA2 で設定されている場合には、wpa_supplicant を使う必要があります。Gentoo Linux でのネットワーク設定のさらなる情報については、Gentoo ハンドブックの無線ネットワークの章を読んでください。

iw dev wlp9s0 link を使って、無線の設定ができたか確認してください。無線が機能したら、次節（ネットワーク用語を理解する）に示す、IP レベルのネットワークオプションの設定に進むか、先に示した net-setup ツールを使ってください。

net-setup を使用する

自動ネットワーク構成が成功しない場合、Gentoo ブートメディアはネットワーク構成を支援するスクリプトを提供しています。net-setup を使用して、無線ネットワーク情報と静的 IP を構成することができます。

root #net-setup enp1s0

net-setup はネットワーク環境についていくつかの質問をし、その情報を使用して wpa_supplicant または静的アドレッシングを構成するでしょう。

重要
何らかの構成手順が取られた後は、ネットワークの状態をテストするべきです。構成スクリプトが機能しない場合は、手動でのネットワーク構成が必要です。

インターネットと IP の基礎

ここまでのすべてが失敗した場合、ネットワークは手動で構成しなくてはなりません。これは特に難しくはありませんが、よく考えて行うべきです。この節は、用語を明確にし、手動でのインターネット接続に関連する基礎的なネットワークの概念を紹介するためのものです。

ヒント
CPE (Carrier Provided Equipment) には、ルータ、アクセスポイント、モデム、DHCP サーバ、および DNS サーバの機能を、単一のユニットに組み合わせているものがあります。具体的な機器とデバイスの機能の区別を付けることは重要です。

インターフェースとアドレス

ネットワークインターフェースは、ネットワークデバイスの論理的な表現です。インターフェースは、ネットワーク上の他のデバイスと通信するためにアドレスを必要とします。単一のアドレスだけが必要である一方で、複数のアドレスを単一のインターフェースに割り当てることもできます。これはデュアルスタック (IPv4 + IPv6) 構成で特に有用です。

一貫性のために、この入門では、インターフェースは enp1s0 で、アドレス 192.168.0.2 を使用すると仮定します。

重要
IP アドレスは任意に設定することができます。その結果、複数のデバイスが同一の IP アドレスを使用する設定にすることができてしまいますが、これはアドレスの競合につながります。アドレスの競合は DHCP または SLAAC を使用して回避すべきです。

ヒント
IPv6 は、アドレス構成のために典型的には StateLess Address AutoConfiguration (SLAAC) を使用します。ほとんどの場合、手動で IPv6 アドレスを設定することはバッドプラクティスです。特定のアドレスサフィックスが好ましい場合は、インターフェース識別トークンを使用することができます。

ネットワークと CIDR

アドレスが選択された後、デバイスは、どのように他のデバイスと通信すればよいかを、どのようにして知るのでしょうか?

IP アドレスはネットワークと関連付けられています。IP ネットワークは、連続した論理的なアドレスの範囲です。

ネットワークのサイズを区別するために、Classless Inter-Domain Routing、略して CIDR 記法が使用されます。

CIDR 値はよく / で始まる表記をされ、ネットワークのサイズを表現します。
- ネットワークのサイズを計算するためには 2 ^ (32 - CIDR) の公式が使用できます。
- ネットワークのサイズが計算できたら、利用できるノード数はそこから 2 を引かなくてはなりません。
  - ネットワークの最初の IP はネットワークアドレスで、最後の IP は典型的にはブロードキャストアドレスです。これらのアドレスは特別であり、通常のホストによって使用することはできません。

ヒント
最もよく使用される CIDR 値は /24、および /32 です。それぞれ 254 ノードと単一ノードを表現します。

/24 の CIDR は事実上のデフォルトのネットワークサイズです。これはサブネットマスク 255.255.255.0 に対応し、最後の 8 ビットはネットワーク上のノードのための IP アドレスとして予約されます。

記法: 192.168.0.2/24 は次のように解釈することができます:

アドレスは 192.168.0.2
ネットワーク 192.168.0.0 上にある
ネットワークはサイズ 254 (2 ^ (32 - 24) - 2) を持つ
- 使用できる IP は 192.168.0.1 - 192.168.0.254 の範囲内にある
ブロードキャストアドレス 192.168.0.255 を持つ
- ほとんどの場合、ネットワーク上の最後のアドレスはブロードキャストアドレスとして使用されますが、これは変更することができます。

この構成を利用することで、デバイスは同一ネットワーク (192.168.0.0) 上のホストと通信できるようになるはずです。

インターネット

デバイスがネットワークに参加した後、デバイスは、どのようにインターネット上のデバイスと通信すればよいかを、どのようにして知るのでしょうか?

ローカルネットワークの外のデバイスと通信するには、ルーティングを使用しなくてはなりません。ルータは、単純に他のデバイスのためにトラフィックを転送するネットワークデバイスです。デフォルトルートまたはゲートウェイという用語は、典型的には、現在のネットワーク上で外部ネットワークへのアクセスのために使用されるデバイスを指します。

ヒント
ゲートウェイは、ネットワーク上の最初または最後の IP にするのが標準的です。

インターネットに接続されたルータが 192.168.0.1 で利用可能である場合、それをデフォルトルートとして使用して、インターネットアクセスを得ることができます。

まとめると:

インターフェースは、CIDR 値などの、アドレスとネットワーク情報を使って構成しなくてはなりません。
ローカルネットワークアクセスは、同一ネットワーク上のルータへのアクセスに使用されます。
デフォルトルートが構成されたら、外部のネットワークに向けたトラフィックはゲートウェイに転送され、インターネットへのアクセスが得られます。

ドメインネームシステム

IP を覚えるのは困難です。ドメイン名と IP アドレスの間のマッピングを行えるように、ドメインネームシステムが作成されました。

Linux システムは、DNS 解決のために使用されるネームサーバを定義するために、/etc/resolv.conf を使用します。

ヒント
多くのルータは DNS サーバとしても機能します。ローカルの DNS サーアを使用することで、プライバシーを向上させ、キャッシュによって問い合わせを高速化することができます。

多くの ISP は DNS サーバを運営していて、これは通常は DHCP を介してゲートウェイに広告されます。ローカル DNS サーバを使用することで問い合わせの遅延が改善されることが多いですが、ほとんどの公開 DNS サーバは同じ結果を返すでしょうから、サーバの使用は好みによるところが大きいです。

手動でのネットワーク設定

インターフェースアドレス構成

重要
手動で IP アドレスを構成するときは、ローカルネットワークトポロジを考慮する必要があります。IP アドレスは任意に設定することはできません; 衝突があるとネットワーク障害を発生させる場合があります。

enp1s0 にアドレス 192.168.0.2 と CIDR /24 を持たせるように構成するには:

root #ip address add 192.168.0.2/24 dev enp1s0

ヒント
このコマンドの先頭の部分は ip a と省略できます。

デフォルトルート構成

インターフェースに対してアドレスとネットワーク情報を構成することで link ルートが構成され、そのネットワークセグメントとの通信が可能になるでしょう:

root #ip route

192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2

ヒント
このコマンドは ip r と省略できます。

次で default ルートを 192.168.0.1 に設定することができます:

root #ip route add default via 192.168.0.1

DNS 構成

ネームサーバ情報は典型的には DHCP を使用して取得されますが、/etc/resolv.conf に nameserver エントリを追加することで、手動で設定することもできます。

警告
dhcpcd が実行中の場合、/etc/resolv.conf への変更は保持されないでしょう。ps x | grep dhcpcd で状態を確認することができます。

nano は Gentoo ブートメディアに含まれており、/etc/resolv.conf を編集するために使用できます:

root #nano /etc/resolv.conf

キーワード nameserver に続いて DNS サーバの IP アドレスを含む行が、定義された順で問い合わせられます:

ファイル /etc/resolv.confQuad9 DNS を使用する。

nameserver 9.9.9.9
nameserver 149.112.112.112

ファイル /etc/resolv.confCloudflare DNS を使用する。

nameserver 1.1.1.1
nameserver 1.0.0.1

DNS のステータスは、ドメイン名に対して ping することで確認できます:

root #ping -c 3 gentoo.org

接続が確認できたら、ディスクの準備から続けてください。

← 適切なメディアの選択 Home ディスクの準備 →

ブロックデバイスの概要

ブロックデバイス

Gentoo Linuxの、そしてLinux一般の、ブロックデバイス、パーティション、Linuxファイルシステムを含めた、ディスクやファイルシステム中心の考え方について詳しく見てみましょう。ディスクの入出力とファイルシステムについて理解することで、インストールのためのパーティションとファイルシステムを構築できるようになります。

まずはブロックデバイスについて見ていきます。SCSIドライブやシリアルATAドライブは両方とも/dev/sdaや/dev/sdb、/dev/sdcなどのようなデバイスハンドルとしてラベル付されます。更にモダンなマシンでは、PCI ExpressベースのNVMeソリッドステートディスクは、/dev/nvme0n1、/dev/nvme0n2などのようなデバイスハンドルを持ちます。

下の表は、各種のブロックデバイスがシステム上のどこにあるかを判断するのに役立つでしょう:

デバイスの種類	デフォルトのデバイスハンドル	編集者メモと、考慮すべき点
IDE、SATA、SAS、SCSI、または USB フラッシュメモリ	/dev/sda	2007 年頃から現在までに製造されたハードウェアで見られます。このデバイスハンドルはおそらく Linux 上でもっともよく使用されているものでしょう。この種のデバイスは SATA バス、SCSI、USB バスを介してブロックストレージとして接続されます。例えば、最初の SATA デバイス上の最初のパーティションは /dev/sda1 という名前になります。
NVM Express (NVMe)	/dev/nvme0n1	ソリッドステートテクノロジとして最新の NVMe ドライブは PCI Express バスに接続され、一般市場でもっとも高速な転送速度を持っています。2014 年頃以降のシステムは NVMe ハードウェアのサポートを備えているかもしれません。最初の NVMe デバイスの最初のパーティションは /dev/nvme0n1p1 という名前になります。
MMC、eMMC、および SD カード	/dev/mmcblk0	embedded MMC デバイス、SD カード、そして他の種類のメモリーカードはデータ用のストレージとして有用です。つまり、多くのシステムはこれらの種類のデバイスからのブートを許可していないかもしれません。これらのデバイスに Linux をインストールして常用するのはおすすめできません。それらの典型的な設計意図である、ファイルの交換用に使うものと考えてください。この種のストレージは短期的なファイルバックアップまたはスナップショットとして使用すると便利かもしれません。

上のブロックデバイスは、ディスクへの抽象的なインターフェースを表しています。ユーザープログラムはこれらのブロックデバイスを用いて、デバイスが SATA、SCSI、もしくは他のものであるかどうかを心配することなしにディスクと通信することができます。プログラムは容易にディスク上の記憶領域を、ランダムアクセスできる 4096 バイト (4K) ごとの連続領域としてアドレッシングできます。

パーティションテーブル

Linux システムを入れるために、（btrfs RAID を作成した場合のように）パーティショニングされていない生のディスクを使うことも理論上は可能ですが、実際にそのようなことを行うことはほとんどありません。代わりに、ディスク全体のブロックデバイスをより小さく扱いやすいブロックデバイスに分けて使います。x86 システムでは、この分けられたブロックデバイスのことをパーティションと呼びます。現在主流なパーティショニング技術は、MBR（DOS ディスクラベルとも呼ばれる）と GPT の 2 つがあります。これらは 2 種類のブートプロセスに関連しています: レガシー BIOS ブートと UEFIです。

GUID パーティションテーブル (GPT)

GUID パーティションテーブル (GPT) 構成 (GPT ディスクラベルとも呼ばれます) は、パーティションの識別子として 64 ビットの値を使います。パーティション情報を格納する領域は MBR パーティションテーブル (DOS ディスクラベル) の 512 バイトよりもずっと大きいため、パーティション数の制限はないようなものです。さらに、最大パーティションサイズもより大きいです (およそ 8 ZiB、そう、ゼタバイトです)。

オペレーティングシステムとファームウェアの間のソフトウェアインターフェースが（BIOS ではなく）UEFI ならば、DOS ディスクラベルでは互換性の問題が発生するので、GPT はほぼ必須となります。

GPTはまたチェックサムと冗長性も備えています。具体的にはヘッダやパーティションテーブルのエラーを検出するCRC32チェックサムや、ディスクの末尾にバックアップのGPTを持っています。もしディスク先頭にあるプライマリGPTに損害があっても、バックアップのGPTを使って回復できます。

重要
GPT にはいくつか注意点があります:

BIOS ベースのコンピュータで GPT を使うことは可能ではありますが、Microsoft Windows オペレーティングシステムとのデュアルブートを行うことはできません。理由は、Microsoft Windows は GPT パーティションラベルを検出すると UEFI モードで起動しようとするためです。
一部、バグのある（古い）マザーボードのファームウェアは、BIOS/CSM/legacy モードで起動するように設定されていると、GPT ラベルのディスクから起動する際に問題が発生する場合があります。

マスターブートレコード (MBR) あるいは DOS ブートセクタ

マスターブートレコードブートセクタ (DOS ブートセクタ、または DOS ディスクラベルとも呼ばれ、最近では GPT/UEFI 構成と対比してレガシー BIOS ブートとも呼ばれます) は、1983 年に PC DOS 2.x とともに最初に導入されました。MBR はパーティションの識別子として、32 ビットで、開始セクタとパーティションのセクタ数を使い、3 種類のパーティションタイプ (プライマリ、拡張、論理) を持っています。プライマリパーティションは、ディスク先頭のとても小さい領域 (ふつうは 512 バイト) にある MBR の中に、その情報が格納されます。この小ささのために、たった 4 つのプライマリパーティションしか使うことができません (例えば /dev/sda1 から /dev/sda4 まで)。

より多くのパーティションを使うために、プライマリパーティションのうちのひとつを拡張パーティションとしてマークすることができます。拡張パーティションは追加の論理パーティションを複数格納することができます（パーティションの中にパーティションが存在することになります）。

重要
まだほとんどのマザーボードメーカーがサポートしてはいるものの、MBR ブートセクタと、それに関連するパーティションの制限は既に過去のものと考えられます。2010 年以前のハードウェアを扱っているのでない限り、GUID パーティションテーブルでディスクをパーティショニングする方が良いでしょう。このセットアップを使って作業を続ける必要がある読者は、以下のことを認識しておいてください:

2010 年以降のほとんどのマザーボードは、MBR ブートセクタを利用するのを過去の(サポートはされているが理想的でない)ブートモードとみなします。
32 ビットの識別子を使用しているため、MBR のパーティションテーブルは 2 TiB を超えるサイズのストレージ空間のアドレスを指定することができません。
拡張パーティションを作成しない限り、MBR は最大で4つまでのパーティションしかサポートしません。
このセットアップではバックアップのブートセクタは一切提供されないので、何かがパーティションテーブルを上書きしてしまうとすべてのパーティション情報が失われます。

とはいえ、MBR とレガシー BIOS ブートは AWS などの仮想化されたクラウド環境ではいまだに使われていることがあります。

ハンドブックの著者たちは、可能であればいつでも、Gentoo をインストールするためには GPT を使うことを提案します。

高度なストレージ

公式 Gentoo ブートメディアは Logical Volume Manager (LVM) サポートを提供しています。LVM を使用すると、パーティションまたはディスク等の物理ボリュームを組み合わせてボリュームグループを構成することができます。ボリュームグループはパーティションと比較して高い柔軟性を持ち、RAID グループや、低速な HD に対して高速な SSD 上にキャッシュを定義するために使用することができます。ハンドブックではその使用法について取り扱いませんが、Gentoo で LVM は完全にサポートされています。

デフォルトのパーティション構成

これよりこのハンドブックでは、ふたつの場合を考察し説明します:

GUID パーティションテーブル (GPT) のディスクとともに、UEFI ファームウェアを使用する。
MBR パーティションテーブルのディスクとともに、MBR DOS/レガシー BIOS ファームウェアを使用する。

特定のマザーボードファームウェアではブートタイプを混ぜて組み合わせることも可能ではありますが、このハンドブックの対象範囲からは外れます。上述の通り、現代的なハードウェアに対するインストールでは、GPT ディスクラベルを持つディスクで UEFI ブートを使用することが強く推奨されます。

シンプルな例として以下のパーティション構造を使います。

重要
以下の表の一行目は、GPT ディスクラベルまたは MBR DOS/レガシー BIOS ディスクラベルのどちらか一方を選択したときの、それぞれに対応する排他的な情報を記載しています。疑わしい場合は、2010 年以降に製造された x86 マシンは一般的に UEFI ファームウェアと GPT ブートセクタをサポートしているので、GPT で進めてください。

パーティション	ファイルシステム	サイズ	説明
/dev/sda1	fat32 EFI システムパーティションのために必要なファイルシステム。常に GPT ディスクラベルと関連付けられます。	1 GiB	EFI システムパーティションの詳細。UEFI 実装をサポートするシステムファームウェアで適用可能です。これは典型的には 2010 年頃から現在までに製造されたシステムが該当します。
/dev/sda1	ext4 MBR パーティションテーブルのブートパーティションにおすすめのファイルシステム。DOS/レガシー BIOS ディスクラベルに制限された古いファームウェアと組み合わせて使用されます。	1 GiB	MBR DOS/レガシー BIOS ブートパーティションの詳細。レガシー BIOS マシンのファームウェアで適用可能です。この種のシステムは典型的には 2010 年<u>より前</u>に製造されたシステムが該当し、一般論として徐々に製造が中止されてきています。
/dev/sda2	linux-swap	RAM サイズ * 2	スワップパーティションの詳細。
/dev/sda3	xfs	ディスクの残り選択されたプロファイル、追加のパーティション (任意)、およびシステムの目的によって rootfs のサイズの見積もりの複雑さは高まるので、ハンドブックの作者は rootfs パーティションに対する「万能」の提案を提供することはできません。<br></br>そのディスクを使用する唯一の OS が Gentoo なら、ディスクの残りを選択するのが最も安全かつ提案される選択肢です。	ルートパーティションの詳細。

もしこの情報だけで十分なほど熟練した読者は、実際のパーティション作成に進んで構いません。

fdisk と parted はいずれも、公式 Gentoo live イメージ環境に含まれるパーティショニングのためのユーティリティです。fdisk はよく知られていて、安定した、MBR と GPT の両ディスクを扱うことができるツールです。parted は GPT パーティションをサポートした、最初期の Linux ブロックデバイスの管理ツールの一つです。読者が望むのであれば fdisk への代替として使用することができますが、ハンドブックでは、多くの Linux 環境で広く利用できる fdisk のための手順のみを提供します。

パーティションの生成方法に進む前に、以降の数セッションでパーティション構造がどのように生成されるのかについて、その詳細を述べ、いくつかの共通した落とし穴について触れておきます。

パーティション構成の設計

パーティション数とサイズ

ディスクのパーティションレイアウトの設計は、システムに対する要求と、デバイスに適用されるファイルシステムに大きく依存します。多数のユーザがいる場合、セキュリティを向上し、バックアップの作成とその他のメンテナンスを容易にするために、/home を分離されたパーティションに配置することが推奨されます。もしメールサーバとして動作する場合は、/var を分離されたパーティションとし、すべてのメールを /var ディレクトリに保存すべきでしょう。ゲームサーバでは、ほとんどのゲームサーバソフトウェアは /opt にインストールされるので、/opt を分離されたパーティションとすることができます。これらが推奨される理由は最初の /home ディレクトリと同様で、セキュリティ、バックアップ、そしてメンテナンスです。

Gentoo では多くの場合、/usr と /var は相対的に大きい容量を確保すべきです。/usr にはシステム上で利用可能なアプリケーションの大部分と、Linux カーネルソース (/usr/src 配下) が配置されます。デフォルトでは、/var には Gentoo ebuild リポジトリが (/var/db/repos/gentoo 配下に) 配置され、ファイルシステム依存ではあるものの通常 650 MiB ほどのディスク容量を消費します。この推定容量には /var/cache/distfiles と /var/cache/binpkgs ディレクトリは含まれていません。これらはそれぞれ、ソースファイルとバイナリパッケージ (使用している場合) を格納するディレクトリで、システムに追加すればするほど大きくなっていきます。

適切なパーティションの数とサイズは、システムを取り巻く環境と、トレードオフを考慮することで大きく変わります。パーティションやボリュームを分離することには下記の利点があります:

それぞれのパーティションまたはボリュームに対して、最も性能が高いファイルシステムを選択できます
ゾンビプロセスがパーティションまたはボリュームに継続的に書き込みをした場合でも、システム全体の空き領域を使い切ることはありません
必要ならば、複数のチェックを並行して実行することで、ファイルシステムチェックの時間を短縮できます (複数のパーティションよりも複数のディスクの方が効果を実感できます)
リードのみ、nosuid(setuidビット無効)、noexec(実行ビット無効)等のマウントオプションによって、セキュリティが向上します

しかし、複数パーティションにはデメリットもあります:

もし適切に設定されていないと、あるパーティションが空き領域をたくさん持ち、別のパーティションにはまったく空き領域がなくなるといったことが起こり得ます。
/usr/ を独立したパーティションにすると、他のブートスクリプトが動作する前にパーティションをマウントするために、initramfs を使ってブートする必要があるかもしれません。initramfs の生成と保守はこのハンドブックのスコープの範囲外ですので、慣れていない方が /usr を独立したパーティションとすることは推奨しません。
SCSI や SATA では仕様上の制約により、GPT ラベルを使用しない限りは 15 個までしかパーティションを作れません。

メモ
サービスおよび init システムとして systemd を使うつもりのインストールでは、/usr ディレクトリはルートファイルシステムの一部とするか、または initramfs によりマウントされるようにして、ブート時に利用できるようにしなくてはなりません。

スワップ領域について

スワップ領域サイズの推奨値
RAM サイズ	サスペンド対応時	ハイバネーション対応時
2 GB 以下	2 * RAM	3 * RAM
2 から 8 GB	RAM 容量	2 * RAM
8 から 64 GB	最小 8 GB、最大 16 GB	1.5 * RAM
64 GB 以上	最小 8 GB	ハイバネーションは推奨されません! 非常に大きな容量のメモリを持つシステムでは、ハイバネーションは推奨されません。可能ではありますが、正しくハイバネーションするためには、メモリの内容全体をディスクに書き込まなくてはなりません。数十 GB (またはそれ以上!) のデータをディスクに書き出すのには、回転式ディスクを使用する場合は特に、非常に長い時間がかかることがあります。この状況ではサスペンドするのが最善です。

スワップ領域のサイズについて完璧な値というものはありません。スワップ領域の目的は、メインメモリ（RAM）が逼迫した際、カーネルにディスク領域を提供するためにあります。スワップ領域があれば、カーネルは最近最も使われていないメモリページをディスクに書き出し（スワップもしくはページアウト）、現在のタスクのために RAM 上に置かれたメモリを開放します。もちろん、もしディスクにスワップされたページが急に必要になった場合は、これらのページはメモリに戻す（ページイン）必要があります。これには、RAM から読み込むより相当長い時間がかかります（メインメモリと比較してディスクはとても遅いためです）。

システムがメモリを大量に消費するアプリケーションを実行しないとき、またシステムが多くの RAM を持っているときは、それほど大きいスワップ領域は必要ではありません。しかし、ハイバネーションの際に、スワップ領域はメモリの内容すべてを保存するために使われる（サーバシステムよりも、デスクトップやラップトップシステムでよくあることです）ことに留意してください。システムにハイバネーションのサポートが必要な場合は、メモリの全体量以上のサイズのスワップ領域が必要です。

RAM 容量が 4GB より少ない場合の一般的なルールとして、スワップ領域のサイズは内部メモリ (RAM) の 2 倍であることが推奨されます。複数のハードディスクを備えるシステムでは、並列して読み込み/書き込み操作が行えるように、それぞれのディスクに 1 つずつスワップパーティションを作成するのが賢い方法です。スワップ空間内のデータにアクセスしなくてはならないときに、ディスクがより高速にスワップできるほど、システムもより高速に動作するでしょう。回転式ディスクとソリッドステートディスクを比較すると、ソリッドステートハードウェア上にスワップを置いたほうが高いパフォーマンスが発揮できます。

スワップパーティションの代わりに、スワップファイルを使用することができることも特筆に値します。これは主にディスク容量が非常に限られたシステムで役に立つものです。

EFI システムパーティション (ESP) とは

オペレーティングシステムを起動するのに (BIOS ではなく) UEFI を使うシステムに Gentoo をインストールするときは、EFI システムパーティションを作成することが必須です。この手順については後述の説明でも述べます。BIOS/レガシーモードで起動する場合には、EFI システムパーティションは不要です。

ESP は FAT 系列のファイルシステム (Linux システムでは vfat と表示することもあります) である必要があります。UEFI specification では、UEFI ファームウェアは FAT12、16、32 を認識すると書かれている一方で、ESP には FAT32 を推奨しています。パーティションを作成したら、ESP をフォーマットしてください:

root #mkfs.fat -F 32 /dev/sda1

重要
ESP が FAT 系列のファイルシステムでフォーマットされていないと、UEFI ファームウェアはブートローダー (か Linux カーネル) を見つけられず、おそらくシステムをブートすることができません！

BIOS ブートパーティションとは

BIOS ブートパーティションはとても小さい (1 - 2 MB) パーティションで、GRUB2 などのブートローダが、与えられた領域に収まらないようなデータを置くためのパーティションです。ディスクが GPT ディスクラベルを使ってフォーマットされているが、システムのファームウェアがレガシー BIOS/MBR DOS ブートモードの GRUB2 を利用してブートしようとしている場合にのみ、必要になります。EFI/UEFI モードで起動する場合には不要で、MBR/レガシー DOS ディスクラベルを使用する場合にも不要です。BIOS ブートパーティションはこのガイドでは使用しません。

UEFI 向けに GPT でディスクをパーティショニングする

以降の部分では、単一の GPT ディスクデバイスのためのパーティションレイアウト例を、UEFI 仕様書および Discoverable Partitions Specification (DPS) に準拠するように作成する方法を説明します。DPS は Linux Userspace API (UAPI) Group Specification の一部として提供されている仕様であり、準拠することが推奨されますが、必須ではありません。この仕様を、sys-apps/util-linux パッケージの一部である fdisk ユーティリティを使って実装します。

表は単純な Gentoo インストールのために推奨されるデフォルトを提供します。個人の好みやシステムの設計目的に応じて追加のパーティションを追加してもかまいません。

デバイスパス (sysfs)	マウントポイント	ファイルシステム	DPS UUID (`Type-UUID`)	説明
/dev/sda1	/efi	vfat	c12a7328-f81f-11d2-ba4b-00a0c93ec93b	EFI システムパーティション (ESP) の詳細。
/dev/sda2	なし。スワップはデバイスファイルのようにファイルシステムにマウントされることはありません。		0657fd6d-a4ab-43c4-84e5-0933c84b4f4f	スワップパーティションの詳細。
/dev/sda3	/	xfs	44479540-f297-41b2-9af7-d131d5f0458a	ルートパーティションの詳細。

現在のパーティションレイアウトを表示する

fdiskは、ディスクをパーティション分割するためのポピュラーでパワフルなツールです。ディスク（我々の例では/dev/sda）に対してfdiskを起動しましょう。

root #fdisk /dev/sda

pキーを使えば、現在のディスクのパーティション構成を表示できます。

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3E56EE74-0571-462B-A992-9872E3855D75

Device        Start        End    Sectors   Size Type
/dev/sda1      2048    2099199    2097152     1G EFI System
/dev/sda2   2099200   10487807    8388608     4G Linux swap
/dev/sda3  10487808 1953523711 1943035904 926.5G Linux root (x86-64)

このディスクは 2 つの Linux ファイルシステム ("Linux" と書かれているパーティションに対応します) と 1 つの swap パーティション ("Linux swap" と書かれているパーティション) で構成されているようです。

新しいディスクラベルを作成する / すべてのパーティションを削除する

g キーを押下するとすぐに、既存のパーティションがすべて削除され、新しい GPT ディスクラベルが作成されるでしょう:

Command (m for help):g

Created a new GPT disklabel (GUID: 3E56EE74-0571-462B-A992-9872E3855D75).

または、既存の GPT ディスクラベル (上の p の出力を確認してください) を保つために、代わりに既存のパーティションをひとつずつ削除することを検討してください。パーティションを削除するには d を押下します。例えば /dev/sda1 を削除するにはこのようにします:

Command (m for help):d

Partition number (1-4): 1

これで指定したパーティションの削除が予約されました。パーティションの一覧 (p) にはもう現れませんが、変更を保存するまで実際の消去は行われないので、間違えて操作してしまった場合は中止することができます。すぐに q を押して Enter を押せば、パーティションは削除されません。

p でパーティションの一覧を表示して d とパーティション番号を入力する、という作業を繰り返すと、パーティションテーブルは空っぽになります。

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3E56EE74-0571-462B-A992-9872E3855D75

さて、メモリ内のパーティションテーブルが空になり、パーティションを作る準備ができました。

EFI システムパーティション (ESP) を作成する

メモ
より小さい ESP にすることもできますが、推奨はされません。他の OS と共有するかもしれない場合は特に。

まずは、/boot としてマウントされることになる小さな EFI システムパーティションを作成します。新規パーティションを作るので n を入力し、1 で最初の基本パーティションを選択しましょう。開始セクタについて聞かれたら、2048 (ブートローダーのために必要になるかもしれません) になっていることを確認して Enter を押しましょう。終了セクタの指定では、1 GB のパーティションを作るので +1G と入力します:

Command (m for help):n

Partition number (1-128, default 1): 1
First sector (2048-1953525134, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525134, default 1953523711): +1G
 
Created a new partition 1 of type 'Linux filesystem' and of size 1 GiB.
Partition #1 contains a vfat signature.

Do you want to remove the signature? [Y]es/[N]o: Y
The signature will be removed by a write command.

パーティションを EFI システムパーティションとしてマークしてください:

Command (m for help):t

Selected partition 1
Partition type or alias (type L to list all): 1
Changed type of partition 'Linux filesystem' to 'EFI System'.

必須ではありませんが、ESP を Discoverable System Partition (DSP) 仕様に準拠させるためには、エキスパートモードに切り換えて、パーティションの UUID を設定するための以下の追加のステップを実行してください:

Command (m for help):x

Expert command (m for help):u

Selected partition 1

New UUID (in 8-4-4-4-12 format): c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Partition UUID changed from 10293DC1-DF6C-4443-8ACF-C756B81B4767 to C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

r キーを押してメインメニューに戻ります:

Expert command (m for help):r


Command (m for help):

スワップパーティションを作成する

次に、スワップパーティションを作成したいので、新規パーティション作成の n を押下し、2 で 2 番目のパーティション、/dev/sda2 を選択しましょう。開始セクタの指定ではそのまま Enter を押します。終了セクタの指定では、4 GiB のパーティションを作るので +4G (もしくはお好みの swap 領域のサイズ) と入力します。

Command (m for help):n

Partition number (2-128, default 2): 
First sector (2099200-1953525134, default 2099200): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2099200-1953525134, default 1953523711): +4G
 
Created a new partition 2 of type 'Linux filesystem' and of size 4 GiB.

この後、パーティションタイプを設定するために t を押下し、今作成したパーティション 2 を選択、そしてパーティションタイプ "Linux Swap" を意味する 19 を入力します。

Command (m for help):t

Partition number (1,2, default 2): 2
Partition type or alias (type L to list all): 19
 
Changed type of partition 'Linux filesystem' to 'Linux swap'.

必須ではありませんが、スワップパーティションを Discoverable System Partition (DSP) 仕様に準拠させるためには、エキスパートモードに切り換えて、パーティションの UUID を設定するための以下の追加のステップを実行してください:

Command (m for help):x

Expert command (m for help):u

Partition number (1,2, default 2): 2
Selected partition 2

New UUID (in 8-4-4-4-12 format): 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
Partition UUID changed from 7529CDF6-9482-4497-B021-576745648B2A to 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F..

r キーを押してメインメニューに戻ります:

Expert command (m for help):r


Command (m for help):

ルートパーティションを作成する

最後に、ルートパーティションを作成します。n で新規パーティション作成、3 番目のパーティションである /dev/sda3 を作成するために 3 を押下、最初のセクタはそのまま Enter を押します。最後のセクタを聞かれたら、ディスクの空き領域全てをこのパーティションに割り当てたいのでそのまま Enter を押しましょう。

Command (m for help):n

Partition number (3-128, default 3): 3
First sector (10487808-1953525134, default 10487808):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (10487808-1953525134, default 1953523711):

Created a new partition 3 of type 'Linux filesystem' and of size 926.5 GiB..

メモ
ルートパーティションのタイプを "Linux root (x86-64)" に設定する必要はなく、"Linux filesystem" タイプに設定されていてもシステムは通常通り機能するでしょう。このファイルシステムタイプは、それをサポートするブートローダ (つまり systemd-boot) を使用し、fstab ファイルを使用したくない場合のみ必要です。

ルートパーティションを作成したら、パーティションタイプを設定するために t を押下し、今作成したパーティション 3 を選択、そしてパーティションタイプ "Linux Root (x86-64)" を意味する 23 を入力します。

Command(m for help):t

Partition number (1-3, default 3): 3
Partition type or alias (type L to list all): 23

Changed type of partition 'Linux filesystem' to 'Linux root (x86-64)'

必須ではありませんが、ルートパーティションを Discoverable System Partition (DSP) 仕様に準拠させるためには、エキスパートモードに切り換えて、パーティションの UUID を設定するための以下の追加のステップを実行してください:

Command (m for help):x

Expert command (m for help):u

Partition number (1-3, default 3): 3

New UUID (in 8-4-4-4-12 format): 4f68bce3-e8cd-4db1-96e7-fbcaf984b709

Partition UUID changed from 40465382-FA2A-4846-9827-640821CC001F to 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709.

r キーを押してメインメニューに戻ります:

Expert command (m for help):r


Command (m for help):

これが終わったら、p で次のようなパーティションテーブルが表示されるはずです:

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3E56EE74-0571-462B-A992-9872E3855D75

Device        Start        End    Sectors   Size Type
/dev/sda1      2048    2099199    2097152     1G Linux filesystem
/dev/sda2   2099200   10487807    8388608     4G Linux swap
/dev/sda3  10487808 1953523711 1943035904 926.5G Linux root (x86-64)

Filesystem/RAID signature on partition 1 will be wiped.

パーティションのレイアウトを保存する

このパーティションレイアウトを保存して fdisk ユーティリティを終了するために、w を押下してください。

Command (m for help):w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

これでパーティションが利用可能になったので、次のインストール手順はここにファイルシステムを置いていくことです。

BIOS / legacy ブート向けに MBR でディスクをパーティショニングする

以下の表は、単純な MBR / レガシー BIOS ブートでのインストールに推奨されるパーティションレイアウトを提供します。個人の好みやシステムの設計目的に応じて追加のパーティションを追加してもかまいません。

デバイスパス (sysfs)	マウントポイント	ファイルシステム	DPS UUID (`PARTUUID`)	説明
/dev/sda1	/boot	ext4	なし	MBR DOS / レガシー BIOS ブートパーティションの詳細。
/dev/sda2	なし。スワップはデバイスファイルのようにファイルシステムにマウントされることはありません。		0657fd6d-a4ab-43c4-84e5-0933c84b4f4f	スワップパーティションの詳細。
/dev/sda3	/	xfs	44479540-f297-41b2-9af7-d131d5f0458a	ルートパーティションの詳細。

パーティションレイアウトはお好みで変更してください。

現在のパーティションレイアウトを表示する

ディスク（我々の例では/dev/sda）に対してfdiskを起動しましょう。

root #fdisk /dev/sda

pキーを使えば、現在のディスクのパーティション構成を表示できます。

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576

Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048    2099199    2097152     1G 83 Linux
/dev/sda2        2099200   10487807    8388608     4G 82 Linux swap / Solaris
/dev/sda3       10487808 1953525167 1943037360 926.5G 83 Linux

このディスクは現時点まで、GPT テーブルを使用して、2 つの Linux ファイルシステム ("Linux" と書かれているパーティションに対応します) と 1 つの swap パーティション ("Linux swap" と書かれているパーティション) で構成されているようです。

新しいディスクラベルを作成する / すべてのパーティションを削除する

o キーを押下するとすぐに、既存のパーティションがすべて削除され、新しい MBR ディスクラベル (DOS ディスクラベルとも呼ばれます) が作成されるでしょう:

Command (m for help):o

Created a new DOS disklabel with disk identifier 0xf163b576.
The device contains 'gpt' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

または、既存の DOS ディスクラベル (上の p の出力を確認してください) を保つために、代わりに既存のパーティションをひとつずつ削除することを検討してください。パーティションを削除するには d を押下します。例えば /dev/sda1 を削除するにはこのようにします:

Command (m for help):d

Partition number (1-4): 1

これで指定したパーティションの削除が予約されました。パーティションの一覧 (p) にはもう現れませんが、変更を保存するまで実際の消去は行われないので、間違えて操作してしまった場合は中止することができます。すぐに q を入力して Enter を押せば、パーティションは削除されません。

p でパーティションの一覧を表示して d とパーティション番号を押下する、という作業を繰り返すと、パーティションテーブルは空っぽになります。

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576

これで、新しいパーティションを作るためのディスクの準備ができました。

ブートパーティションを作成する

まずは、/boot としてマウントされることになる小さなパーティションを作成します。新規パーティションを作るので n を押下し、p で基本パーティションを選択、1 で最初の基本パーティションを選択しましょう。開始セクタについて聞かれたら、2048 (ブートローダーのために必要になるかもしれません) になっていることを確認して Enter を押しましょう。終了セクタの指定では、1 GB のパーティションを作るので +1G と入力します:

Command (m for help):n

Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-1953525167, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525167, default 1953525167): +1G

Created a new partition 1 of type 'Linux' and of size 1 GiB.

a キーを押して、Enter を押すことで、パーティションをブート可能としてマークしてください:

Command (m for help):a

Selected partition 1
The bootable flag on partition 1 is enabled now.

メモ: ディスク上で複数のパーティションが利用可能な場合は、ブート可能としてマークしたいパーティションを選択する必要があるでしょう。

スワップパーティションを作成する

次に、スワップパーティションを作成したいので、新規パーティション作成の n を押下し、p で基本パーティションを選択し、2 で 2 番目の基本パーティション、/dev/sda2 を選択しましょう。開始セクタの指定ではそのまま Enter を押します。終了セクタの指定では、4GB のパーティションを作るので +4G (もしくはお好みの swap 領域のサイズ) と入力します。

Command (m for help):n

Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2099200-1953525167, default 2099200):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2099200-1953525167, default 1953525167): +4G
 
Created a new partition 2 of type 'Linux' and of size 4 GiB.

ここまでできたら、パーティションタイプを設定するために t を押下し、今作成したパーティション 2 を選択、そしてパーティションタイプ "Linux Swap" を意味する 82 を入力します。

Command (m for help):t

Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 82

Changed type of partition 'Linux' to 'Linux swap / Solaris'.

ルートパーティションを作成する

最後に、ルートパーティションを作成します。n で新規パーティション作成、3 番目の基本パーティション、/dev/sda3 を作成するために p と 3 を押下、最初のセクタはそのまま Enter を押します。最後のセクタを聞かれたら、ディスクの空き領域全てをこのパーティションに割り当てたいのでそのまま Enter を押しましょう:

Command (m for help):n

Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3
First sector (10487808-1953525167, default 10487808):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (10487808-1953525167, default 1953525167):

Created a new partition 3 of type 'Linux' and of size 926.5 GiB.

これが終わったら、p で次のようなパーティションテーブルが表示されるはずです:

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576

Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048    2099199    2097152     1G 83 Linux
/dev/sda2        2099200   10487807    8388608     4G 82 Linux swap / Solaris
/dev/sda3       10487808 1953525167 1943037360 926.5G 83 Linux

パーティションのレイアウトを保存する

このパーティションレイアウトを書き込んで fdisk を終了するために、w を押下してください:

Command (m for help):w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

それでは、パーティション上にファイルシステムを作成していきましょう。

ファイルシステムを作成する

警告
SSD または NVMe ドライブを使用する場合は、ファームウェアアップグレードがあるかどうか確認するのが賢明です。特に一部の Intel SSDs (600p および 6000p) は、XFS の I/O 使用量パターンによって誘発されるデータ破損の可能性のためのファームウェアアップグレードが必要です。この問題はファームウェアレベルのもので、XFS ファイルシステムの欠陥ではありません。smartctl ユーティリティはデバイスのモデルとファームウェアバージョンを確認するのに役立ちます。

はじめに

パーティションが作成できたら、その上にファイルシステムを作成します。次の節ではLinuxがサポートする各種ファイルシステムを紹介します。どのファイルシステムを使うかをすでに決めているなら、パーティションにファイルシステムを適用するへ進みましょう。そうでなければ、次の節を読んで利用可能なファイルシステムについて知るのがよいでしょう。

ファイルシステム

Linux は多くのファイルシステムをサポートしていますが、それらの多くは特定の目的をもって配備するのが賢明なものです。特定のファイルシステムのみが x86 アーキテクチャ上で安定して動作するとされています - 重要なパーティションに実験的なファイルシステムを選択するときは、事前にファイルシステムのサポート状況を十分に知っておくことを推奨します。XFS はすべてのプラットフォームで、すべての目的で推奨されるファイルシステムです。以下は、網羅的ではないリストです:

btrfs: 次世代のファイルシステムです。スナップショット、チェックサムによる自己修復、透過的圧縮、サブボリューム、RAID の統合などの先進的な機能を提供します。RAID 5/6 とクオータグループは、btrfs のすべてのバージョンで安全ではありません。
ext4: ext4 は reflink などの現代的な機能を欠いてはいるものの、信頼性があり、全目的、全プラットフォームで使用できるファイルシステムです。
f2fs: Flash-Friendly File System はもともと、Samsung によって NAND フラッシュメモリで利用するために作られました。Gentoo を microSD カードや USB スティックや他のフラッシュベースの記憶装置にインストールする際にはすばらしい選択でしょう。
XFS: メタデータジャーナリングのあるファイルシステムで、堅牢な機能セットを持ち、スケーラビリティに最適化されています。新しい機能を取り入れながら継続的にアップグレードされ続けています。唯一の欠点は、現在対応中ではあるものの、 XFS パーティションはまだ縮小できないという点です。XFS の特筆すべき点として reflink とコピーオンライト (CoW) に対応しており、これは Gentoo システム上ではユーザが実施するコンパイル量の多さから特に有用です。XFS は全目的、全プラットフォームで利用できる、おすすめの現代的なファイルシステムです。パーティションは少なくとも 300MB ある必要があります。
VFAT: 別名 FAT32。Linux でサポートされていますが、標準的な UNIX パーミッションの設定をサポートしていません。ほとんど、他の OS (Microsoft Windows または Apple macOS) との相互運用性/交換のために使われていますが、いくつかのシステムブートローダーファームウェア (たとえば UEFI) でも必要になります。UEFI システムを使用している場合は、システムをブートするためには VFAT でフォーマットされた EFI システムパーティションが必要になるでしょう。
NTFS: この "New Technology" ファイルシステムは、Windows NT 3.1 以降の Microsoft Windows のフラッグシップファイルシステムです。VFAT と同様、BSD や Linux が正しく動作するために必要な UNIX パーミッション設定や拡張属性を保持しないため、ほとんどの場合ルートファイルシステムとして使うべきではありません。Microsoft Windows とデータ交換の相互運用のためにのみ使うべきです (のみの強調に注意してください)。

ファイルシステムについてのより広範な情報は、コミュニティによって維持されているファイルシステムの記事で見つけることができます。

パーティションにファイルシステムを適用する

メモ
再起動する前に、選択したファイルシステムに関連するユーザ空間ユーティリティを emerge しておいてください。インストールプロセスの終わりのあたりでまた、そうするように再通知します。

パーティションまたはボリュームの上にファイルシステムを作成するには、ファイルシステムごとに異なるユーザースペースのユーティリティが利用可能です。下表でファイルシステムの名前をクリックすると、それぞれに追加の情報が得られます：

ファイルシステム	作成コマンド	live 環境内にある？	パッケージ
btrfs	mkfs.btrfs	はい	sys-fs/btrfs-progs
ext4	mkfs.ext4	はい	sys-fs/e2fsprogs
f2fs	mkfs.f2fs	はい	sys-fs/f2fs-tools
xfs	mkfs.xfs	はい	sys-fs/xfsprogs
vfat	mkfs.vfat	はい	sys-fs/dosfstools
NTFS	mkfs.ntfs	はい	sys-fs/ntfs3g

重要
ハンドブックではインストールプロセスの一部として新しいパーティションを使用することを推奨しますが、重要なこととして、mkfs コマンドを実行すると、パーティションに含まれるすべてのデータは消去されることに注意してください。必要な場合は、新しいファイルシステムを作成する前に、中に存在する任意のデータが適切にバックアップされていることを確認してください。

例えば、パーティション構造例の通りに、ルートパーティション (/dev/sda3) を xfs として設定するには、次のコマンドが使えます:

root #mkfs.xfs /dev/sda3

EFI システムパーティションのファイルシステム

EFI システムパーティション (/dev/sda1) は FAT32 としてフォーマットする必要があります:

root #mkfs.vfat -F 32 /dev/sda1

レガシー BIOS ブートパーティションのファイルシステム

MBR/DOS ディスクラベルを持ち、レガシー BIOS を利用してブートするシステムは、ブートローダがサポートする任意のファイルシステムフォーマットを使用することができます。

例えば、XFS でフォーマットするには:

root #mkfs.xfs /dev/sda1

小さな ext4 パーティション

ext4 ファイルシステムを (8 GiB 未満の) 小さいパーティションに使用する場合は、十分な inode 数を確保できるように適切なオプションを指定してファイルシステムを作成するべきです。これは -T small オプションを使用して指定することができます:

root #mkfs.ext4 -T small /dev/<device>

こうすることで「inode あたりのバイト数」が 16kB から 4kB に減るので、ファイルシステムに 4 倍の inode 数を確保できます。

スワップパーティションを有効にする

mkswapはスワップパーティションを初期化するために使われるコマンドです：

root #mkswap /dev/sda2

スワップパーティションを有効化するには、swaponを使います：

root #swapon /dev/sda2

この「有効化」の手順は、このスワップパーティションが live 環境内に新しく作成されたという理由から必要になっているものです。システムのリブート後は、スワップパーティションが fstab またはその他のマウント機構で適切に定義されている限り、スワップ領域は自動的に有効化されるでしょう。

ルートパーティションのマウント

メモ
以前に開始したインストール手順を完了しなかった場合は、ハンドブックのこの時点からインストールを再開することができます。このリンクを permalink として使用してください: インストールの再開はここから。

一部の live 環境は、Gentoo のルートパーティションのために提案されているマウントポイント (/mnt/gentoo) や、パーティショニングの節で作成された追加のパーティションのためのマウントポイントを持たないかもしれません:

root #mkdir --parents /mnt/gentoo

EFI インストールの場合、ESP はルートパーティションの場所の下にマウントすべきです:

root #mkdir --parents /mnt/gentoo/efi

以前の手順で作成した追加の (カスタムの) パーティションがあれば、mkdir コマンドを使用して、追加で必要なマウントポイントの作成を続けてください。

マウントポイントが作成できたら、mount コマンドで、パーティションにアクセスできるようにしましょう。

ルートパーティションをマウントしてください:

root #mount /dev/sda3 /mnt/gentoo

必要に応じて、mount コマンドを使用して、追加の (カスタムの) パーティションのマウントを続けてください。

メモ
もし/tmp/を別のパーティションに置く必要があるなら、マウントしたあと権限の変更を忘れずに行ってください:

root #chmod 1777 /mnt/gentoo/tmp

/var/tmpについても同様です。

このあと解説の中で、proc ファイルシステム (仮想的なカーネルとのインターフェース) が、他のカーネル擬似ファイルシステムと同様にマウントされますが、まず最初は、Gentoo stage ファイルを展開する必要があります。

← ネットワーク設定 Home Gentoo インストールファイルをインストール →

stage ファイルを選択する

ヒント
デスクトップ (グラフィカル) OS 環境を目的にするユーザは、それがサポートされているアーキテクチャでは、名前に desktop の項を持つ stage ファイルを使用することが推奨されます。これらのファイルは sys-devel/llvm や dev-lang/rust-bin などのパッケージと、USE フラグのチューニングを含んでおり、インストール時間を大きく改善します。

stage ファイルは Gentoo インストールの種として機能します。stage ファイルはリリースエンジニアリングチームによって Catalyst を使用して生成されます。stage ファイルは、特定のプロファイルを基礎としており、ほぼ完全なシステムを含んでいます。

stage ファイルを選択するときには、所望のシステムの種別に応じたプロファイルターゲットを持つもの選ぶことが重要です。

重要
インストールが確立された後にメジャープロファイルを変更することは、技術的には可能ですが、変更にはかなりの労力と熟慮が必要で、このインストールマニュアルの範囲外です。init システムの切り換えは難しいですが、no-multilib から multilib への切り換えは Gentoo と低レベルツールチェーンについての深い知識を必要とします。

ヒント
大部分のユーザは、'advanced' な tarball を選択する必要は無いはずです。これらは、典型的でないあるいは高度な、ソフトウェアもしくはハードウェアのためのものです。

OpenRC

OpenRC は依存関係に基づく init システム (カーネルが起動した後にシステムサービスを開始するためのシステム) で、通常は /sbin/init にある、システムが提供する init プログラムとの互換性を保っています。Gentoo に由来するオリジナルの init システムですが、他の一部の Linux ディストリビューションや BSD システムでも採用されています。

OpenRC はデフォルトでは /sbin/init ファイルの代替としては機能せず、Gentoo の init スクリプトとは完全な互換性があります。つまり、Gentoo ebuild リポジトリにはデーモンを起動するソリューションがあるということです。

systemd

systemd は SysV スタイルの init と rc の、Linux システム向けの現代的な代替です。Linux ディストリビューションの大多数では、第一の init システムとして使用されています。systemd は Gentoo で完全にサポートされており、その意図した目的に合うように動作します。もし systemd インストールパスについて、何かがハンドブックから欠けているようであれば、助けを求める前に systemd の記事を確認してください。

multilib (32 ビットと 64 ビット)

メモ
すべてのアーキテクチャが multilib オプションを持っているわけではありません。多くは、ネイティブコードでしか動作しません。multilib が最もよく適用されているのは amd64 です。

multilib プロファイルは、可能な場合は 64 ビットのライブラリを使用し、互換性のために厳密に必要な場合のみ 32 ビットのライブラリにフォールバックします。これは将来のカスタマイズのために大きな柔軟性をもたらすので、ほとんどのシステムにとってすばらしい選択肢となります。

ヒント
multilib ターゲットを使用すると、no-multilibと比較して、後でプロファイルを切り換えるのが簡単になります。

非 multilib (64 ビットのみ)

警告
非 mutilib を必要とする明確な理由がなく、単に Gentoo を使いたいというケースでは、非 multilib を選択すべきではありません。no-multilib から mutilib システムへの変更は、Gentoo の深い知識と低レベルのツールチェーンが必要です (これはおそらく私たちの Toolchain developers を身震いさせるでしょう)。これは気の弱い人への警告ではなく、このガイドの範囲外になるということです。

システムのベースとして非 multilib の tarball を選択することで、32 ビットソフトウェアの無い、完全な 64 ビット環境を構築できます。これは事実上、multilib プロファイルへの変更を (技術的には可能ではありますが) 面倒なものにします。

stage ファイルをダウンロードする

stage ファイルをダウンロードする前に、インストールのために使用されるマウントポイントにカレントディレクトリを設定すべきです:

root #cd /mnt/gentoo

日時を設定する

stage アーカイブは一般的には HTTPS を使用して取得され、これには比較的正確なシステム時刻の設定が必要です。時刻がずれているとダウンロードができないことがあるほか、インストール後に大きくシステム時刻を修正すると、予測不可能なエラーを発生させることがあります。

date を使って、現在の日付と時刻を検証することができます:

root #date

Mon Oct  3 13:16:22 PDT 2021

表示された日時が 2、3 分以上ずれている場合は、以下に示す方法のうちいずれかに従って更新してください。

自動

時計のずれを修正するためには、手動でシステム時計を設定するよりも、典型的には NTP を使用するのがより簡単でより信頼できるでしょう。

net-misc/chrony の一部である chronyd は、システム時計を UTC と更新するために、次のようにして使用することができます:

root #chronyd -q

重要
動作するリアルタイムクロック (RTC) を持たないシステムは、システム開始のたびに、そしてその後は定期的に、システム時計を同期しなくてはなりません。RTC を持つシステムでも、バッテリが故障して時計のずれが蓄積することがあるため、これは有用です。

警告
標準的な NTP のトラフィックは認証されていません。ネットワークから取得した時刻データを検証することは重要です。

手動

NTP へのアクセスが利用できない場合は、date を使用してシステム時計を手動で設定することができます。

メモ
すべての Linux システムでは UTC で時刻を設定することが推奨されます。あとでシステムのタイムゾーンを定義して、時刻を表示するときのオフセットを変更します。

時刻を設定するためには、以下の引数フォーマットが使用されます: MMDDhhmmYYYY 構文 (Month (月)、Day (日)、hour (時)、minute (分)、Year (年))。

例えば、2021年の10月3日 13時16分に設定するには、以下を実行してください:

root #date 100313162021

グラフィカルブラウザ

完全なグラフィカルウェブブラウザがある環境を使っているひとには、stage ファイルの URL をメインウェブサイトのダウンロードセクションからコピーするのに何の問題も無いでしょう。単純に適切なタブを選択して、stage ファイルへのリンクを右クリックして、Copy Link してクリップボードにリンクをコピーして、コマンドライン上で wget ユーティリティにリンクをペーストして、stage ファイルをダウンロードします:

root #wget <PASTED_STAGE_FILE_URL>

コマンドラインブラウザ

伝統的な読者や'古参'の Gentoo ユーザで、コマンドラインのみで作業をする人たちは、グラフィカル環境を必要としないメニュー形式のブラウザである links (www-client/links) を使うほうを好むかもしれません。stage をダウンロードするために、Gentoo ミラーリストに飛んでください。

root #links https://www.gentoo.org/downloads/mirrors/

linksでHTTPプロキシを使うには、-http-proxyオプションにプロキシのURLを渡してください。

root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/

links に似た lynx (www-client/lynx) というブラウザもあります。links と同じくグラフィカル環境を必要としませんが、メニューはありません。

root #lynx https://www.gentoo.org/downloads/mirrors/

プロキシを定義する必要があるならば、http_proxyやftp_proxy変数をexportしてください。

root #

export http_proxy="http://proxy.server.com:port"

root #export ftp_proxy="http://proxy.server.com:port"

ミラーリストから、近くのミラーを選んでください。通常はHTTPミラーで十分ですが、他のプロトコルも使えます。releases/x86/autobuilds/ ディレクトリに移動してください。入手可能なすべてのstageファイルが列挙されています。ファイルは、サブアーキテクチャにちなんだ名前のサブティレクトリの中にあることもあります。ファイルを選び、dを押してダウンロードしてください。

stage ファイルのダウンロードが完了したら、整合性を検証して stage ファイルのコンテンツが正当か確認することができます。興味のあるひとは次節へ進んでください。

stage ファイルの検証と確認に興味が無いひとは、q を押すことでコマンドラインブラウザを終了して、stage ファイルを展開する節へすぐに進むことができます。

検証して確認する

メモ
今では、ほとんどの stage は init システムの種類に応じて明示的に (openrc または systemd と) 接尾辞が付けられていますが、アーキテクチャによっては、これらがまだ無いものもあります。

Minimal インストール CD のときと同じく、stage ファイルを検証して確認するためのファイルもダウンロードすることができます。これらの手順は飛ばしてもかまいませんが、ダウンロードしたファイルの整合性を気にするユーザのためにこれらのファイルが提供されています。これらの追加のファイルはミラーディレクトリのルートの下から取得できます。ハードウェアアーキテクチャとシステムプロファイルごとの適切な場所にブラウザで移動して、関連する .CONTENTS.gz、.DIGESTS、そして .sha256 ファイルをダウンロードしてください。

root #wget https://distfiles.gentoo.org/releases/

.CONTENTS.gz - stage ファイル内のファイル一覧を含む圧縮ファイル。
.DIGESTS - stage ファイルの、複数の暗号学的ハッシュアルゴリズムを用いたチェックサムを含みます。
.sha256 - stage ファイルの、PGP で署名された SHA256 チェックサムを含みます。このファイルはすべての stage ファイルで取得できるとは限りません。

openssl、sha256sum、または sha512sum などの暗号ツールおよびユーティリティを使用し、その出力を提供された .DIGESTS ファイルに含まれるチェックサムと比較することができます。

例えば、openssl で SHA512 チェックサムを検証するには:

root #openssl dgst -r -sha512 stage3-x86-<release>-<init>.tar.xz

dgst は openssl コマンドにメッセージダイジェストのサブコマンドを使うように指示し、-r はダイジェスト出力を coreutils フォーマットで印字し、-sha512 は SHA512 ダイジェストを選択します。

openssl で BLAKE2B512 チェックサムを検証するには:

root #openssl dgst -r -blake2b512 stage3-x86-<release>-<init>.tar.xz

チェックサムコマンドの出力を、.DIGESTS ファイルに含まれているハッシュとファイル名の値の組み合わせと比較してください。これらの値の組み合わせはチェックサムコマンドの出力と一致している必要があります。一致していない場合、ダウンロードしたファイルが破損しているため、削除して再ダウンロードするべきです。

sha256sum ユーティリティを使用して、関連する .sha256 ファイルに含まれる SHA256 ハッシュを検証するには:

root #sha256sum --check stage3-x86-<release>-<init>.tar.xz.sha256

--check オプションは sha256sum に期待されるファイルと対応するハッシュのリストを読み込ませ、各ファイルごとに、正しく計算できれば "OK" を、そうでない場合は "FAILED" を印字するように指示します。

ISO ファイルと同様に、tarball が改竄されていないことを確認するために、gpg を使って .tar.xz ファイルの電子署名を検証することもできます。

公式 Gentoo live イメージに関しては、自動化されたリリースのために sec-keys/openpgp-keys-gentoo-release パッケージが PGP 署名鍵を提供しています。鍵を検証に使用するためには、まずユーザのセッションに鍵をインポートする必要があります:

root #gpg --import /usr/share/openpgp-keys/gentoo-release.asc

非公式 live イメージでは、live 環境内で gpg と wget を提供していれば、Gentoo 鍵を含むバンドルを取得してインポートすることができます:

root #wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --import

tarball の署名と、追加で関連するチェックサムファイルを検証してください:

root #

gpg --verify stage3-x86-<release>-<init>.tar.xz.asc

root #

gpg --verify stage3-x86-<release>-<init>.tar.xz.DIGESTS

root #

gpg --verify stage3-x86-<release>-<init>.tar.xz.sha256

検証に成功した場合は、上のコマンドの出力に "Good signature from" が含まれるでしょう。

リリースメディアに署名するのに使用された OpenPGP 鍵のフィンガープリントは、リリースメディアの署名ページで確認できます。

stage ファイルをインストールする

stage ファイルのダウンロードと検証が完了したら、tar を使用してこれを展開することができます:

root #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner

展開する前に、オプションを確認してください:

x 展開 (extract)。アーカイブから内容を展開するように tar に指示します。
p パーミッションを保持します (preserve permissions)。
v 詳細な出力 (verbose output)。
f ファイル (file)。入力アーカイブの名前を tar に提供します。
--xattrs-include='*.*' アーカイブに保存されている拡張属性をすべての名前空間について保持します。
--numeric-owner (たとえ冒険的なユーザが公式 Gentoo live 環境を使わずにインストール作業をしている場合であっても) tarball から展開されるファイルのユーザ ID とグループ ID が Gentoo リリースエンジニアリングチームの意図通りになるようにします。

これでステージファイルは展開されました。この続きはコンパイルオプションを設定するで。

コンパイルオプションを設定する

はじめに

システムを最適化するために、Portage（Gentooの公式なパッケージマネージャ）の挙動に影響する変数を設定できます。これらの変数はすべて環境変数として（exportを使って）設定できますが、export による設定は永続的なものではありません。

メモ
シェルのプロファイルまたは rc ファイルを利用して変数を export することは技術的には可能ですが、これは基本的なシステム管理の方法としてはベストプラクティスではありません。

Portage は実行時に make.conf を読み、ファイルに保存された値に基づいて実行時の振る舞いを変えます。make.conf は Portage の第一の設定ファイルと見ることができますので、その内容には注意して取り扱ってください。

メモ
/mnt/gentoo/usr/share/portage/config/make.conf.exampleに、すべての利用可能な変数のリストが、コメント付きで記載されています。make.conf についてのさらなるドキュメンテーションは、man -LC 5 make.conf を実行することで確認できます。(訳注: 日本語版は 10 年以上更新されていません。-LC を付けて最新の英語版を参照してください。)

Gentoo のインストールを成功させるために最低限設定する必要がある変数は、以降で示すものだけです。

これから詳しく見ていく最適化変数を設定するために、エディタ（このガイドではnanoを使います）を起動してください。

root #nano /mnt/gentoo/etc/portage/make.conf

make.conf.example ファイルを読めば、記述形式は分かるでしょう。コメント行は # で始まり、他の行は「変数="内容"」の形式で変数を定義します。これらの変数のうちのいくつかについて、次の節で見ていきます。

CFLAGS と CXXFLAGS

CFLAGSとCXXFLAGS変数はそれぞれ、GCC CコンパイラとC++コンパイラのための最適化フラグを定義します。この2つの変数は通常ここで定義されますが、真に最高のパフォーマンスを発揮するためには、このフラグはプログラム毎に別々に設定する必要があるでしょう。すべてのプログラムは異なるからです。しかし、それでは管理が大変なので、make.confファイルでこれらのフラグを定義します。

make.confでは、一般にシステムの応答が速くなるように最適化フラグを設定するべきです。この変数に実験的な設定を書かないでください。過剰な最適化はプログラムの挙動をおかしくすることがあり、クラッシュや誤動作の元となります。

ハンドブックではすべての最適化オプションを説明することはしません。すべてを理解するためには、GNU オンラインマニュアルや GCC info ページ (info gcc) を読んでください。make.conf.example ファイルにはたくさんの設定例と情報が含まれているので、これを読むこともお忘れなく。

最初の設定は-march=または-mtune=フラグです。これはターゲットアーキテクチャの名前を指定します。可能な選択肢はmake.conf.exampleファイル内にコメントとして書かれています。nativeを指定すると、コンパイラは（Gentooをインストールしようとしている）現在のシステムのアーキテクチャをターゲットとして選択してくれるので、よく使われます。

ふたつめの設定は-Oフラグ（ゼロではなく大文字のオー）です。これはgcc最適化クラスフラグを指定します。可能なクラスは、s（サイズ最適化）、0（ゼロ、最適化無し）、1、2、3（速度最適化）です。速度最適化については、各クラスは1段階前のクラスが持つものと同じフラグに加えて、追加のフラグを持ちます。-O2は推奨されるデフォルト設定です。-O3をシステム全体で使うと問題を起こすことが知られているので、-O2にとどめることをおすすめします。

他によく使われる最適化フラグには-pipeがあります。これは、コンパイルステージ間での連絡方法として、一時ファイルではなくパイプを使うよう指定します。生成されるコードには影響しませんが、より多くのメモリを使うようになります。メモリの少ないシステムでは、gccが強制終了するかもしれません。そのような場合には、このフラグは使わないでください。

-fomit-frame-pointerを使うと、必要の無い場合にはフレームポインタをレジスタに保持しなくなります。これはアプリケーションのデバッグ時に深刻な影響を与えるかもしれません。

CFLAGS と CXXFLAGS 変数を定義するときには、最適化フラグは 1 つの文字列として結合してください。stage ファイルアーカイブに含まれるデフォルト値で十分でしょう。以下に例を示します:

コード CFLAGSとCXXFLAGS変数の設定例

# すべての言語において設定するコンパイラフラグ
COMMON_FLAGS="-O2 -march=i686 -pipe"
# 同じ設定を両方の変数に使用
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"

ヒント
各種コンパイルオプションがどのようにシステムに影響するかについては GCC の最適化の記事に詳しい情報がありますが、初心者がシステムの最適化を始めるには Safe CFLAGS の記事のほうがもっと実践的な場所かもしれません。

MAKEOPTS

MAKEOPTS 変数は、パッケージのインストール時にどれだけ並行してコンパイルを走らせるかを定義します。Portage バージョン 3.0.31^[1] 時点において、未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS の jobs の値は nproc が返すスレッド数と同じ数に設定されます。

さらに Portage 3.0.53 の時点では^[2]、未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS の load-average の値は nproc が返すスレッド数と同じ数に設定されます。

CPU のスレッド数か、システム全体の RAM 容量を 2 GiB で割った数のうち、小さい方を選択するのがよい選択とされています。

警告
ジョブ数を大きくすると、メモリ使用量にきわめて大きな影響を及ぼします。目安は、指定したジョブ数の各ジョブに対し、最低 2 GiB の RAM が割り当てられるようにすることです (つまり、例えば -j6 は最低でも 12 GiB を要求します)。メモリが枯渇しないようにするには、利用可能なメモリ容量に合うようにジョブ数を減らしてください。

ヒント
並列 emerge を使用する (--jobs) と、実効的なジョブ数が指数関数的に (make ジョブ数 × emerge ジョブ数まで) 増大することがあります。これに対しては、localhost-only distcc 構成によって、ホスト当たりのコンパイラインスタンス数を制限することで対処することができます。

ファイル /etc/portage/make.confMAKEOPTS 設定例

# 未定義のままの場合、Portage のデフォルトの挙動は以下の通りです:
# - MAKEOPTS の jobs 値を `nproc` が返すスレッド数と同じ数に設定する
# - MAKEOPTS の load-average 値を `nproc` が返すスレッド数よりわずかに大きい数に設定する (減衰された値であるため)
# '4' をシステムに応じて適切に (min(RAM/2GB, スレッド数) 置き換えるか、未設定のままにしておいてください。
MAKEOPTS="-j4 -l5"

さらなる詳細については man 5 make.conf 内で MAKEOPTS を検索してください。

よーい、ドン！

好みの設定に合わせて /mnt/gentoo/etc/portage/make.conf を変更し、保存してください。nano では Ctrl+o で変更を保存して、Ctrl+x で終了できます。

参照

← ディスクの準備 Home Gentooベースシステムのインストール →

chroot する

DNS 情報をコピーする

新しい環境に入る前に一つだけやるべきことが残っています。それは/etc/resolv.confに記載されているDNS情報をコピーすることです。これは新しい環境に入った後でネットワークを使うために必要です。/etc/resolv.confは、そのネットワークのネームサーバーの情報を含んでいます。

この情報をコピーするときは、cpコマンドに--dereferenceオプションを付与することを推奨します。これは/etc/resolv.confがシンボリックリンクのときに、シンボリックリンクをコピーするのではなく、シンボリックリンクのリンク先の実ファイルをコピーします。そうしないと新しい環境でシンボリックリンクが存在しないファイルを指し示すでしょう（新しい環境では、元の環境でリンク先に指定していたファイルはほぼ利用できません）。

root #cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

必要なファイルシステムをマウントする

もう少しで、Linux ルートは新しい場所に変わります。

使えるようにしなければならないファイルシステムは以下の通りです。

/proc/ は Linux カーネルから情報を引き出すための擬似ファイルシステムです。一見通常ファイルに見えますが、ファイルとしての実体はありません。
/sys/ は /proc/ 同様、擬似ファイルシステムです。{{Path|/proc/} }より構造化されており、一度は /proc/ を置き換えることを目的としていました。
/dev/ は、すべてのデバイスファイルを含む通常のファイルシステムです。一部は Linux のデバイス管理機構 (通常は udev) により管理されています。
/run/ は一時ファイルシステムです。PID ファイルやロックなど、実行時に生成されるファイルのために使用されます。

/proc/は、/mnt/gentoo/proc/にマウントされるでしょう。他はbindマウントされます。後者は、例えば/mnt/gentoo/sys/は事実/sys/となります（同じファイルシステムへの2番目のエントリです）。ここで/mnt/gentoo/proc/はファイルシステムの新しいエントリ（インスタンスとも言えるでしょう）となります。

ヒント
Gentoo のインストールメディアを使用している場合は、このステップは単に arch-chroot /mnt/gentoo として置き換えることができます。

root #

mount --types proc /proc /mnt/gentoo/proc

root #

mount --rbind /sys /mnt/gentoo/sys

root #

mount --make-rslave /mnt/gentoo/sys

root #

mount --rbind /dev /mnt/gentoo/dev

root #

mount --make-rslave /mnt/gentoo/dev

root #

mount --bind /run /mnt/gentoo/run

root #

mount --make-slave /mnt/gentoo/run

メモ
インストールの後半で出てくるsystemdを使う場合、--make-rslaveが必要です。

警告
Gentoo以外のインストールメディアを使う場合、これだけでは十分ではない場合があります。いくつかのディストリビューションは/run/shm/へのシンボリックリンクとして/dev/shmを作りますが、これはchroot後に無効になってしまいます。これに対応するためには、/dev/shm/をtmpfsとして適切にマウントしておくことが必要です：

root #

test -L /dev/shm && rm /dev/shm && mkdir /dev/shm

root #

mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm

そして確実にモード1777に設定してください：

root #chmod 1777 /dev/shm /run/shm

新しい環境に入る

ようやく、すべてのパーティションが初期化され、ベース環境がインストールされました。chroot を実行して新しいインストール環境に入りましょう。これは、セッションの root (アクセスできる最も上位レベルの場所) を、現状のインストール環境 (インストール CD もしくは他のインストールメディア) から、インストール対象システム (つまり初期化されたパーティション) に変更することを意味しています。これが change root もしくは chroot の意味です。

chrootは次の3ステップで実行されます。

chroot コマンド、または利用可能であれば arch-chroot コマンドによって、最上位ディレクトリを (インストールメディアの) / から (パーティションをマウントしている) /mnt/gentoo/ に変更する。
/etc/profile のいくつかの設定を source コマンドでリロードする。
chroot 環境であることを忘れないようするために、シェルのプロンプトを変更する。

root #

chroot /mnt/gentoo /bin/bash

root #

source /etc/profile

root #export PS1="(chroot) ${PS1}"

この時から、すべての操作は新しい Gentoo Linux 環境で実行されます。

ヒント
これ以降の時点で Gentoo インストールを中断しても、インストール作業をこのステップから「再開」することができるようになっているはずです。ディスクをまたパーティショニングする必要はありません！ただ単にルートパーティションをマウントして、上のステップを DNS 情報をコピーするところから実行すれば、作業中の環境に再び入ります。ブートローダの問題を解決するのにもこれが役に立ちます。さらなる情報は chroot の記事にあります。

ブートローダのための準備をする

新しい環境に入ることができたら、次はこの新しい環境をブートローダのために準備する必要があります。ブートローダをインストールするときには、正しいパーティションがマウントされていることが重要になるでしょう。

UEFI システム

UEFI システムでは、/dev/sda1 が FAT32 ファイルシステムでフォーマットされ、EFI システムパーティション (ESP) として使用されます。(まだ作成されていない場合は) 新しく /efi ディレクトリを作成して、そこに ESP をマウントしてください:

root #

mkdir /efi

root #

mount /dev/sda1 /efi

DOS/レガシー BIOS システム

DOS/レガシー BIOS システムでは、ブートローダは /boot ディレクトリにインストールされるので、次のようにマウントしてください:

root #mount /dev/sda1 /boot

Portage を設定する

Web から Gentoo ebuild リポジトリのスナップショットをインストールする

次にGentoo ebuildリポジトリのスナップショットをインストールします。このスナップショットには、インストール可能なパッケージの情報、システム管理者が選択するプロファイルの一覧、パッケージやプロファイルごとのお知らせなどをPortageに伝えるファイルが含まれます。

ここで紹介するemerge-webrsyncは、HTTP/FTPプロトコル以外でのダウンロードがファイアウォールで制限されるような環境や、ネットワーク帯域を節約したい場合にお薦めです。これらの制約がなければ、この手順は省いて次のセクションに進んでも構いません。

次のコマンドで、毎日更新される最新のスナップショットをGentooのミラーサイトから取得し、インストールします:

root #emerge-webrsync

メモ
この作業中、emerge-webrsync は /var/db/repos/gentoo/ がない旨のメッセージを出すかもしれません。これは想定内で、心配することはありません。このディレクトリは自動的に作成されます。

この時点で、Portageはいくつかのアップデートが推奨されていることを通知するかもしれません。これは、stageファイルでインストールされたシステム関連のパッケージについて、より新しいバージョンが利用可能であることを示しています。今回新しいリポジトリスナップショットがインストールされたことで、Portageがそれを認識したのです。このメッセージは今のところは無視して、Gentooのインストールが完了してから対応しても問題ありません。

任意自由選択: ミラーサーバーを選択する

ソースコードを短時間でダウンロードするために、高速で、地理的に近いミラーを選択することをおすすめします。Portage は make.conf の中の GENTOO_MIRRORS 変数に指定されたミラー群を使用します。Gentoo のミラー一覧をブラウザで開き、インストール対象のマシンに物理的に近い一つまたは複数のミラーを選択することができます (これらは高い頻度で最も高速になり得ます)。

mirrorselect というツールが、より手っ取り早く適したミラーを検索して選択するための素晴らしいテキストインターフェースを提供しています。単に選択したいミラーにカーソルを合わせて Spacebar を押し、一つまたは複数のミラーを選択してください。

root #emerge --ask --verbose --oneshot app-portage/mirrorselect

root #mirrorselect -i -o >> /etc/portage/make.conf

または、アクティブなミラーの一覧はオンラインでも確認できます。

任意自由選択: Gentoo ebuild リポジトリを更新する

Gentoo ebuildリポジトリを最新版にアップデートできます。先のemerge-webrsyncコマンドはほぼ最新の（通常は24時間以内に作成される）スナップショットをインストールするため、このステップは本当に任意です。

最新（一時間以内）のパッケージ更新があるかもしれません。その更新を取り込むためにemerge --syncを実行しましょう。このコマンドはGentoo ebuildリポジトリ（先程emerge-webrsyncコマンドで取得したもの）をアップデートするためにrsyncプロトコルを使用します。

root #emerge --sync

アップデートの時間を短縮するために、特定のフレームバッファもしくはシリアルコンソール等の遅いターミナルでは、--quietオプションを使うことをお薦めします。

root #emerge --sync --quiet

ニュースを読む

Gentoo ebuildリポジトリの更新時、Portage が次のような情報メッセージを出すことがあります。

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.

 * Use eselect news to read news items.

ニュース項目は、Gentoo ebuild リポジトリを通じて、ユーザーに重要なメッセージを通知するためのコミュニケーション手段です。これらニュース項目を管理するためにeselect newsを使用します。eselectはGentooに固有のユーティリティで、システム管理のための共通の管理インターフェースを提供します。この場合、eselectはnewsモジュールを使うことを指示されます。

newsモジュールに対しては、主に３つの操作が使用されます。

listを指定すると、現在有効なニュースアイテムの概要が表示されます。
readを指定すると、そのニュースアイテムを読むことができます。
purgeを指定すると、一度購読したニュースを削除することができます。これにより、それらのニュースを二度と目にすることはないでしょう。

root #

eselect news list

root #eselect news read

ニュースリーダーに関するほとんどの情報はマニュアルページを通じて得ることができます。

root #man news.eselect

適切なプロファイルを選ぶ

ヒント
デスクトッププロファイルはデスクトップ環境のためだけのものではありません。i3 や sway のようなミニマルなウィンドウマネージャにも適しています。

プロファイルはあらゆるGentooシステムの基礎を構成します。プロファイルはUSE、CFLAGS等の重要な変数の初期値を決めるだけではありません。プロファイルは、パッケージのバージョンを決まった範囲に固定する役目を持っています。プロファイルはGentooのPortage開発者によって完全にメンテナンスされています。

現在使用中のプロファイルを確認するには、eselect を profile モジュールを指定して実行してください:

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux/x86/23.0 *
  [2]   default/linux/x86/23.0/desktop
  [3]   default/linux/x86/23.0/desktop/gnome
  [4]   default/linux/x86/23.0/desktop/kde

メモ
コマンドの出力は一例で、常に更新されています。

メモ
systemd を使用するには、名前に "systemd" を含んだプロファイルを選択してください。逆もまた然りです。

いくつかのアーキテクチャでは、デスクトップ体験のために共通して必要なソフトウェアパッケージを含む、デスクトップ向けのサブプロファイルが見られるでしょう。

警告
プロファイルのアップグレードは軽々と行われるものではありません。初期プロファイルを選択する時、確実に stage ファイルがはじめに使用していたものと同じバージョン（例えば 23.0）を使用してください。新しいプロファイルのバージョンは、移行方法を含むニュース項目を通して発表されます; 新しいプロファイルに移行する前にはその説明に注意して従うようにしてください。

x86アーキテクチャで利用可能なプロファイルを確認後、別のプロファイルを選択できます。

root #eselect profile set 2

メモ
developerサブプロファイルはGentoo Linux開発向けの固有のプロファイルであり、通常のユーザーが使用するものではありません。

追加可能: バイナリパッケージホストを追加する

2023 年 12 月より、Gentoo のリリースエンジニアリングチームは、バイナリパッケージ (binpkg) の取得とインストールをコミュニティ全体が利用できるように、公式のバイナリパッケージホスト (略して "binhost") を提供しています。^[1]

バイナリパッケージホストを追加することで、Portage は、暗号論的に署名されたコンパイル済みパッケージをインストールすることができるようになります。多くの場合、バイナリパッケージホストを追加することでパッケージインストールのための平均時間が大幅に減少するため、古い、遅い、あるいは低消費電力のシステム上で Gentoo を動かすときには、大きな利益が得られるでしょう。

リポジトリの構成

binhost のためのリポジトリ構成設定は Portage の /etc/portage/binrepos.conf/ ディレクトリ内に見つけられ、これは Gentoo ebuild リポジトリの節で言及した構成設定と同じように動作します。

バイナリホストを定義するときに検討すべき重要な側面が 2 つあります:

sync-uri の値の中のアーキテクチャおよびプロファイルターゲットは非常に重要であり、対応するコンピュータアーキテクチャ (この場合は x86) と、適切なプロファイルを選択するの節で選択されたシステプロファイルに合わせるべきです。
一般的に、高速で地理的に近いミラーを選択することで、取得時間が短縮されるでしょう。任意自由選択: ミラーサーバーを選択するの節で言及している mirrorselect ツールを確認するか、URL 値を知ることができるオンラインのミラーリストを確認してください。

ファイル /etc/portage/binrepos.conf/gentoobinhost.confCDN ベースのバイナリパッケージホストの例

[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

バイナリパッケージをインストールする

Portage はデフォルトではソースコードからパッケージをコンパイルするでしょう。以下の方法で、バイナリパッケージを使用するように指示することができます:

emerge コマンドを呼び出すときに --getbinpkg オプションを渡すことができます。このバイナリパッケージインストール方法は、特定のバイナリパッケージのみをインストールするために有用です。
/etc/portage/make.conf ファイルを通して提示される Portage の FEATURES 変数を介して、システムのデフォルトを変更する。この設定変更を適用すると、Portage は要求されたパッケージをバイナリパッケージホストに問い合わせ、結果が見つからない場合にはローカルでコンパイルする方法にフォールバックするようになるでしょう。

例えば、Portage に利用可能なバイナリパッケージを常にインストールさせるには:

ファイル /etc/portage/make.confデフォルトでバイナリパッケージを使用するように Portage を設定する

# FEATURES 変数内の値のリストに getbinpkg を追加してください
FEATURES="${FEATURES} getbinpkg"
# 署名を要求する
FEATURES="${FEATURES} binpkg-request-signature"

Portage が検証のために必要なキーリングをセットアップするために、getuto も実行してください:

root #getuto

さらなる Portage の機能についてはハンドブックの次の章で取り扱います。

追加可能: USE 変数を設定する

USEは、Gentooがユーザに提供する最もパワフルな変数の一つです。多くのプログラムに対して、決められた追加機能を含めたり、もしくは含めずにコンパイルすることが可能です。例えば、いくつかのプログラムはGTK+サポートもしくはQtサポートを有効にしてコンパイルできます。別のプログラムにはSSLサポートを含めたり、もしくは含めずにコンパイルすることが可能です。いくつかのプログラムはX11サポート（Xサーバー）の代わりに、フレームバッファサポート（svgalib）と共にコンパイルできます。

多くのディストリビューションでは、各種のサポートを最大限含むようにコンパイルします。これはプログラムサイズと起動時間を増大させます。多くの依存関係を発生させることは言うまでもありません。Gentoo では、ユーザーはパッケージをコンパイルする時のオプションを定義できます。ここで USE が登場します。

USE変数を使って、ユーザーはコンパイルオプションにマップされるキーワードを指定します。例えば、sslキーワードはSSLをサポート可能なプログラムでSSLを有効にしてコンパイルします。-XキーワードはXサーバーのサポートを含まない（最初のマイナス記号で指定）ようにコンパイルします。gnome gtk -kde -qt5は、GNOME（とGTK+）サポートを有効にして、KDE（とQt）サポートを無効にします。これにより、（もし、アーキテクチャがGNOMEをサポートしていれば）システムはGNOME向けに最大限調整されます。

デフォルトの USE の設定は、システムによって使用される Gentoo プロファイルの make.defaults ファイルに記述されています。Gentoo はシステムプロファイルをサポートするために、複雑な継承システムを使用していますが、インストール作業中はこれについて深くは触れないことにします。現在有効な USE 設定を知るためのもっとも簡単な方法は、emerge --info を実行して USE で始まる行を抜き出すことです:

root #emerge --info | grep ^USE

USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."

メモ
上記の例は出力のほとんどを省略しています。実際には、USE 変数のリストはずっとずっと長いものです。

使用可能な USE フラグの完全な説明は、/var/db/repos/gentoo/profiles/use.desc にあります。

root #less /var/db/repos/gentoo/profiles/use.desc

lessコマンドでは、↑キーと↓キーを使ってスクロールすることができます。qを押すと終了します。

例として、DVD、ALSA、CD書き込みをサポートしたKDEベースのUSE設定を示します。

root #nano /etc/portage/make.conf

ファイル /etc/portage/make.confDVD、ALSA、CD書き込みをサポートしたKDE/Plasmaベースのフラグ設定

USE="-gtk -gnome qt5 kde dvd alsa cdr"

/etc/portage/make.conf で USE の値を定義すると、その値はシステムの USE フラグリストに追加されます。USE フラグは、リスト中の値の前に - マイナス記号を追加することで、グローバルに削除することができます。例えば、X グラフィカル環境のサポートを無効化するには、-X を設定することでこれを行えます:

ファイル /etc/portage/make.confデフォルトのUSEフラグを無視する

USE="-X acl alsa"

警告
-* を指定することで、make.conf 内で指定したもの以外のすべての USE 値を無効化することができますが、これはまったくおすすめできない、賢明でないことです。Ebuild の開発者たちは、競合を防止するため、セキュリティを向上させるため、エラーを回避するため等の理由によって、デフォルトの USE フラグを選択して ebuild で指定しています。すべての USE フラグを無効化することはデフォルトの振る舞いを否定し、重大な問題を引き起こすことがあります。

CPU_FLAGS_*

一部のアーキテクチャ (AMD64/X86、ARM、PPC を含みます) には、CPU_FLAGS_<ARCH> (<ARCH> は関連するシステムアーキテクチャ名に置き換えてください) と呼ばれる USE_EXPAND 変数があります。

重要
混乱しないで! AMD64 と X86 のシステムは共通のアーキテクチャを一部共有しているので、AMD64 システムのための正しい変数名は CPU_FLAGS_X86 です。

これは、通常手書きなどで書かれた特定のアセンブリコードや intrinsics 等を含めるようにビルドを構成するために使用されるもので、特定の CPU 機能のために最適化されたコードを出力するようにコンパイラに指示する (-march= 等) のとは異なります。

COMMON_FLAGS を希望に応じて設定するのに加えて、この変数も設定すべきでしょう。

これをセットアップするにはいくつかのステップが必要です:

root #emerge --ask --oneshot app-portage/cpuid2cpuflags

興味があるなら、出力を自分で確認してみてください:

root #cpuid2cpuflags

そして、出力を package.use にコピーしてください:

root #echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

VIDEO_CARDS

利用できる GPU に応じて、VIDEO_CARDS USE_EXPAND 変数を適切に構成するとよいでしょう。コンソールのみのシステムの場合は、VIDEO_CARDS を設定する必要はありません。

以下は適切に設定された VIDEO_CARDS 変数の例です。使用するドライバの名前の部分は置き換えてください。

ファイル /etc/portage/make.conf

VIDEO_CARDS="amdgpu radeonsi"

各種 GPU ごとの詳細は、AMDGPU、Intel、Nouveau (オープンソース)、または NVIDIA (プロプライエタリ) の記事で読むことができます。

追加可能: ACCEPT_LICENSE 変数を設定する

Gentoo Linux Enhancement Proposal 23 (GLEP 23) 以降、システム管理者が「インストールするソフトウェアをライセンスの観点から制限」^[2]できるようにする機構が作られました。「OSI によって承認されていないソフトウェアをまったく持たないシステムを求める人もいれば、どのライセンスを暗黙に受諾しているのか単に気になるという人もいます。」^[3]Gentoo システム上で実行するソフトウェアの種類をより細かく制御したいという動機から、ACCEPT_LICENSE 変数が生まれました。

インストールのプロセス中に、Portage は、要求されたパッケージが、システム管理者による受諾できるライセンスの決定を満たしているか判断するために、ACCEPT_LICENSE 変数に設定された値を考慮します。ここで問題があります: Gentoo ebuild リポジトリは数千もの ebuild からなり、数百もの異なるソフトウェアライセンスを持っています……。これは、新しいソフトウェアライセンスが出るたびに、システム管理者は個別にいちいち受諾を求められるということでしょうか? ありがたいことに、そうではありません; GLEP 23 はこの問題に対する解決策である、ライセンスグループの概念も規定しています。

システム管理上の利便性のために、法的に類似したソフトウェアライセンスをまとめて分類しています。ライセンスグループの定義はここで確認することができ、Gentoo Licenses プロジェクトによって管理されています。ライセンスグループは構文上 @ 記号が先頭に付けられ、一方で個々のライセンスはそうではないため、ACCEPT_LICENSE 変数内で容易に区別が付くようになっています。

よく使用されるライセンスグループには以下のものが含まれます:

名前	説明
`@GPL-COMPATIBLE`	フリーソフトウェア財団によって承認された、GPLと両立するライセンス (GPL compatible license) 群 ^{[a_license 1]}
`@FSF-APPROVED`	FSF (訳注: フリーソフトウェア財団) によって承認された自由ソフトウェアライセンス群 (`@GPL-COMPATIBLE` を含みます)
`@OSI-APPROVED`	Open Source Initiative によって承認されたライセンス群 ^{[a_license 2]}
`@MISC-FREE`	おそらく自由ソフトウェアであるその他のライセンス群。言い換えると、自由ソフトウェアの定義^{[a_license 3]}に従っているものの、FSF や OSI によって承認されていないライセンス
`@FREE-SOFTWARE`	`@FSF-APPROVED`、`@OSI-APPROVED`、および `@MISC-FREE` を組み合わせたもの。
`@FSF-APPROVED-OTHER`	FSF が承認した「自由な文書」および「ソフトウェアや文書以外の実用の著作物のライセンス」 (フォントを含む)
`@MISC-FREE-DOCS`	自由の定義^{[a_license 4]}に従っているが、`@FSF-APPROVED-OTHER`の一覧には載っていない、自由な文書およびその他の著作物。
`@FREE-DOCUMENTS`	`@FSF-APPROVED-OTHER` および `@MISC-FREE-DOCS` を組み合わせたもの。
`@FREE`	利用、共有、改変、および改変の共有の自由を持つ、すべてのライセンスからなるメタ集合。 `@FREE-SOFTWARE` および `@FREE-DOCUMENTS`を組み合わせたもの。
`@BINARY-REDISTRIBUTABLE`	少なくともソフトウェアのバイナリ形式での自由な再配布を認めているライセンス群。`@FREE` を含みます。
`@EULA`	あなたの権利を取り去ろうとするライセンス契約。これらは "all-rights-reserved" や明示的な承諾を必要とするものよりも拘束的です

システム全体で現在設定されている、受諾可能なライセンスの値は、以下で確認できます:

user $portageq envvar ACCEPT_LICENSE

@FREE

この出力で分かる通り、デフォルト値は、@FREE カテゴリに分類されるソフトウェアのみをインストールできるようになっています。

システム全体に関して、特定のライセンスまたはライセンスグループを以下の場所で定義することができます:

選択されたプロファイルによって、システム全体で - これはデフォルト値を設定します。
/etc/portage/make.conf ファイルによって、システム全体で。システム管理者はこのファイルで、プロファイルのデフォルト値を無視することができます。
/etc/portage/package.license ファイルによって、パッケージ単位で。
/etc/portage/package.license/ ディレクトリのファイルによって、パッケージ単位で。

/etc/portage/make.conf で、プロファイルによってシステム全体のデフォルトとなっているライセンス設定を無視することができます:

ファイル /etc/portage/make.confシステム全体で ACCEPT_LICENSE でライセンスを受諾する

# プロファイルの ACCEPT_LICENSE のデフォルト値を無視する
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"

必要であれば、次のファイル例を含むディレクトリで示すように、パッケージごとに受諾するライセンスを定義することもできます。package.license ディレクトリが存在しない場合は作成しておく必要があります:

root #mkdir /etc/portage/package.license

各 Gentoo パッケージに対するソフトウェアライセンスの詳細は、関連する ebuild の LICENSE 変数内に保存されています。パッケージによっては複数のパッケージを持つことがあり、そのため単一のパッケージに対して、受諾できるライセンスを複数指定する必要がある場合もあります。

ファイル /etc/portage/package.license/kernelパッケージ単位でライセンスを受諾する

app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode

重要
ebuild の LICENSE 変数は Gentoo の開発者やユーザにとってのガイドラインでしかありません。これは法的声明ではなく、これが現実を反映する保証はありません。ソフトウェアパッケージのライセンスに関する、ebuild 開発者の解釈だけを信用しないようにすることをおすすめします; パッケージそのものを、システムにインストールされるすべてのファイルを含めて徹底的にチェックしてください。

追加可能: @world 集合の更新

システムの @world 集合の更新は省略可能です。以下の追加手順のいずれかまたは両方が行われていない限り、おそらく機能的な変更は発生しないでしょう:

プロファイルのターゲットが、stage ファイルを選択したときのものと異なっている。
インストールされたパッケージに追加の USE フラグが設定されている。

「Gentoo インストールタイムアタック」を行っているなら、@world 集合の更新は、システムを新しい Gentoo 環境内に再起動させた後の時点まで安全に後回しにすることができます。

タイムアタックをしているのでなければ、パッケージ、プロファイル、現時点での USE フラグの変更に関して、Portage に更新を行わせることができます:

root #emerge --ask --verbose --update --deep --newuse @world

古いパッケージを削除する

システム更新後は、古くなったパッケージを削除するために、常に depclean しておくのが重要です。削除されることになるパッケージの中に、個人的に使用していて残すべきものが無いか確認するために、 emerge --depclean --pretend の出力を注意深く確認してください。depclean されそうなパッケージを残すためには、emerge --noreplace foo を使用してください。

root #emerge --ask --pretend --depclean

問題なければ、実際の depclean を進めてください:

root #emerge --ask --depclean

ヒント
非 desktop の stage ファイルから、デスクトップ環境プロファイルターゲットを選択した場合、@world 更新プロセスはインストール時間を格段に長くしてしまうかもしれません。時間に追われている人は次の経験則が成り立つでしょう。「名前が短く、特定のシステムを示さないプロファイルの @world 集合を選択する」。「もっとも一般的な @world 集合は、より少ないパッケージのアップデートですむ」。例えば:

default/linux/amd64/23.0 を選択すると、おそらくパッケージのアップデートは少なくて済むでしょう。
default/linux/amd64/23.0/desktop/gnome/systemd を選択すると、おそらくより多くのパッケージがインストールされるでしょう。なぜなら、プロファイルターゲットが、 GNOME デスクトップ環境をサポートするための依存パッケージを含む、より大きな @system および @profile 集合を持つからです。

タイムゾーン

メモ
このステップは musl libc を使う場合は適用されません。それがどういう意味か分からない場合は、このステップを実行すべきです。

警告
/usr/share/zoneinfo/Etc/GMT* のタイムゾーンは、その名前が期待されるゾーンを示していないため、避けましょう。たとえば、GMT-8 は実際には GMT+8 となります。

タイムゾーンを選択します。/usr/share/zoneinfo/から利用可能なタイムゾーンを探してください:

root #ls -l /usr/share/zoneinfo

total 352
drwxr-xr-x 2 root root   1120 Jan  7 17:41 Africa
drwxr-xr-x 6 root root   2960 Jan  7 17:41 America
drwxr-xr-x 2 root root    280 Jan  7 17:41 Antarctica
drwxr-xr-x 2 root root     60 Jan  7 17:41 Arctic
drwxr-xr-x 2 root root   2020 Jan  7 17:41 Asia
drwxr-xr-x 2 root root    280 Jan  7 17:41 Atlantic
drwxr-xr-x 2 root root    500 Jan  7 17:41 Australia
drwxr-xr-x 2 root root    120 Jan  7 17:41 Brazil
-rw-r--r-- 1 root root   2094 Dec  3 17:19 CET
-rw-r--r-- 1 root root   2310 Dec  3 17:19 CST6CDT
drwxr-xr-x 2 root root    200 Jan  7 17:41 Canada
drwxr-xr-x 2 root root     80 Jan  7 17:41 Chile
-rw-r--r-- 1 root root   2416 Dec  3 17:19 Cuba
-rw-r--r-- 1 root root   1908 Dec  3 17:19 EET
-rw-r--r-- 1 root root    114 Dec  3 17:19 EST
-rw-r--r-- 1 root root   2310 Dec  3 17:19 EST5EDT
-rw-r--r-- 1 root root   2399 Dec  3 17:19 Egypt
-rw-r--r-- 1 root root   3492 Dec  3 17:19 Eire
drwxr-xr-x 2 root root    740 Jan  7 17:41 Etc
drwxr-xr-x 2 root root   1320 Jan  7 17:41 Europe
...

root #ls -l /usr/share/zoneinfo/Europe/

total 256
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Amsterdam
-rw-r--r-- 1 root root 1742 Dec  3 17:19 Andorra
-rw-r--r-- 1 root root 1151 Dec  3 17:19 Astrakhan
-rw-r--r-- 1 root root 2262 Dec  3 17:19 Athens
-rw-r--r-- 1 root root 3664 Dec  3 17:19 Belfast
-rw-r--r-- 1 root root 1920 Dec  3 17:19 Belgrade
-rw-r--r-- 1 root root 2298 Dec  3 17:19 Berlin
-rw-r--r-- 1 root root 2301 Dec  3 17:19 Bratislava
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Brussels
...

選択したタイムゾーンが Europe/Brussels の場合は以下となります。

OpenRC

設定したいタイムゾーン名を /etc/timezone に記述します:

root #echo "Europe/Brussels" > /etc/timezone

最後に、sys-libs/timezone-data パッケージを設定しましょう - これは /etc/timezone のエントリを元に、/etc/localtime をアップデートします:

root #emerge --config sys-libs/timezone-data

メモ
/etc/localtime は、システムの C ライブラリが、自身が属するタイムゾーンを知るために使われます。

systemd

systemd を使用している場合は、多少異なるアプローチをとります。シンボリックリンクを生成します:

root #ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime

その後 systemd が起動してから、タイムゾーンとそれに関連する設定を timedatectl コマンドで設定することができます。

ロケールの設定

メモ
このステップは musl libc を使う場合は適用されません。それがどういう意味か分からない場合は、このステップを実行すべきです。

ロケールの生成

ほとんどのユーザは、一つもしくは二つのロケールを必要とします。

ロケールはシステムで使用する言語を指定するだけではなく、単語のソート順や日付、時間等のルールにも使用されます。ロケールは大文字小文字を区別するので、記載とまったく同じように表現する必要があります。利用可能なロケールの一覧は /usr/share/i18n/SUPPORTED ファイルで確認できます。

サポートされるシステムロケールは、/etc/locale.gen ファイルに定義する必要があります。

root #nano /etc/locale.gen

次のロケールの例では、英語（米国）とドイツ語（ドイツ）を（UTF-8のような）文字コードと共に指定しています。

ファイル /etc/locale.genUSとDEロケールを適切な文字コードと共に有効にする

en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8

警告
多くのアプリケーションは適切にビルドするのに少なくとも UTF-8 を必要とします。

次に locale-gen コマンドを実行します。このコマンドは /etc/locale.gen ファイルに記載されているすべてのロケールを生成します。

root #locale-gen

現在使用可能なすべてのロケールを確認するためには、locale -aを実行してください。

systemd を使用しているシステムでは、localectl を使用できます。localectl set-locale ... または localectl list-locales のように。

ロケールの選択

この時点で、システム全体で有効になるロケールを設定できます。eselect を locale モジュールと共に使いましょう。

eselect locale listを実行すると、利用可能なターゲットが表示されます。

root #eselect locale list

Available targets for the LANG variable:
  [1]  C
  [2]  C.utf8
  [3]  en_US
  [4]  en_US.iso88591
  [5]  en_US.utf8
  [6]  de_DE
  [7]  de_DE.iso88591
  [8]  de_DE.utf8
  [9] POSIX
  [ ]  (free form)

eselect locale set <番号> を実行することで、適切なロケールを選択することができます:

root #eselect locale set 2

手動で設定する場合は、/etc/env.d/02locale ファイルと、systemd の場合は /etc/locale.conf ファイルも編集してください。

ファイル /etc/env.d/02localeシステムのロケールをマニュアル設定する

LANG="de_DE.UTF-8"
LC_COLLATE="C.UTF-8"

ロケールを設定すると、後でカーネルをビルドしたり、他のソフトをコンパイルしたりするときに警告やエラーを回避できるでしょう。

ここで、環境をリロードします。

root #env-update && source /etc/profile && export PS1="(chroot) ${PS1}"

ロケール選択プロセス全体にわたる、さらなるガイドについては、ローカライゼーションガイドと UTF-8 ガイドもお読みください。

参照

← Gentoo インストールファイルをインストール Home カーネルの設定 →

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

ファームウェア

Linux ファームウェア

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

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

root #emerge --ask sys-kernel/linux-firmware

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

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

マイクロコード

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

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

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

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

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

完全自動アプローチ: ディストリビューションカーネル: ディストリビューションカーネルは、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 とコンフィグスニペットです。設定についてのさらなる詳細はプロジェクトページを参照してください。

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

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

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

sys-kernel/installkernel dracut

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

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

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

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

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

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

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルモジュールは既に署名されています。ソースからビルドしたカーネルのモジュールに署名するためには、/etc/portage/make.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 によって許可されなくてはなりません。これはハンドブック内で後で説明します。

アップグレードと後処理

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

root #emerge --depclean

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

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

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

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

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

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

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

root #emerge --ask @module-rebuild

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

root #

emerge --config sys-kernel/gentoo-kernel

root #

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

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

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

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

root #emerge --ask sys-kernel/installkernel

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

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

はじめに

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

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

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

カーネル 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 カーネルイメージに含められる前に自動的に署名されるので、手動で署名する必要はありません。

x86 アーキテクチャに関しては、64-bit kernel のオプションが設定されていない/無効化されている (CONFIG_64BIT=N) ことを確認して、プロセッサファミリをシステムのプロセッサに応じて適切に選択してください。

プロセッサファミリは次の 2 コマンドの出力を確認することで決定できます:

user $cat /proc/cpuinfo | grep -i vendor | uniq

user $cat /proc/cpuinfo | grep -i 'model name' | uniq

カーネル 64 ビットカーネルを選択解除して、プロセッサファミリを選択する

[ ] 64-bit kernel
Processor type and features  --->
    Processor family (Core 2/newer Xeon)  --->
        ( ) 486
        ( ) 586/K5/5x86/6x86/6x86MX
        ( ) Pentium-Classic
        ( ) Pentium-MMX
        ( ) Pentium-Pro
        ( ) Pentium-II/Celeron(pre-Coppermine)
        ( ) Pentium-III/Celeron(Coppermine)/Pentium-III Xeon
        ( ) Pentium M
        ( ) Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon
        ( ) K6/K6-II/K6-III
        ( ) Athlon/Duron/K7
        ( ) Opteron/Athlon64/Hammer/K8
        ( ) Crusoe
        ( ) Efficeon
        ( ) Winchip-C6
        ( ) Winchip-2/Winchip-2A/Winchip-3
        ( ) AMD Elan
        ( ) GeodeGX1
        ( ) Geode GX/LX
        ( ) CyrixIII/VIA-C3
        ( ) VIA C3-2 (Nehemiah)
        ( ) VIA C7
        (*) Core 2/newer Xeon
        ( ) Intel Atom

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

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

root #make && make modules_install

メモ
make -j N とすることで、ビルドを並行処理させることができます (N には、並行処理を許可するビルドプロセスの数を整数で指定します)。/etc/portage/make.conf の説明中の、MAKEOPTS 変数についてと同様です。

カーネルのコンパイルが完了したら、カーネルのイメージを /boot/ にコピーします。これは make install コマンドで行います。

root #make install

カーネルイメージとともに、System.map ファイルやカーネルコンフィグファイルも、 /boot/ にコピーされます。

別の方法: Genkernel

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

Genkernel は、Genkernel だけが満たすことができるニーズを持つ場合のみ検討されるべきです。そうでない場合は、ディストリビューションカーネルを使用するか自身で手動でコンパイルすることで Gentoo システムの維持がずっと単純になるので、そうすることが推奨されます。genkernel のほうが管理しづらい理由の例のひとつは、sys-kernel/installkernel との統合の欠如です。これは、Genkernel を使用する場合には Unified カーネルイメージを手動で作成する必要があるなどのように、他の手法によって提供されるのと同じレベルの自動化を得られないだろうということを意味します。

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 または XFS 以外のファイルシステムを使用している場合、おそらく 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

カーネルのインストール

Installkernel

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

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

systemd-boot

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

OpenRC システムでは:

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

sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot

root #emerge --ask sys-apps/systemd-utils

systemd システムでは:

ファイル /etc/portage/package.use/systemd

sys-apps/systemd boot
sys-kernel/installkernel systemd-boot

root #emerge --ask sys-apps/systemd

GRUB

GRUB を使用する場合は、systemd の kernel-install または伝統的な Debian installkernel のいずれかを使用することができます。systemd USE フラグはこれらの実装の切り換えを行います。カーネルをインストールするときに自動的に grub-mkconfig を実行するためには、grub USE フラグを有効化してください。

ファイル /etc/portage/package.use/installkernel

sys-kernel/installkernel grub

root #emerge --ask sys-kernel/installkernel

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

grub 、systemd-boot および uki USE フラグが有効化されていない場合、(LILO などのための) 伝統的な /boot レイアウトがデフォルトで使用されます。さらなる操作は必要ありません。

initramfs をビルドする

場合によっては、initramfs (初期 RAM ファイルシステム、initial ram-based file system) をビルドする必要があることがあります。最もよくある理由は、(/usr/ または /var/ などの) 重要のファイルシステムの場所が別のパーティション上にあるときです。initramfs を使用することで、これらのパーティションを initramfs 内で利用可能なツールを使用してマウントすることができます。Project:Distribution Kernel のデフォルトの構成は initramfs を必要とします。

initramfs がないと、ファイルシステムのマウントに責任を持つツールが、マウントされていないファイルシステム上にある情報を必要とするために、システムが正しくブートしないリスクがあります。initramfs は、カーネルがブートした直後、ただし制御が init ツールに移される前に使用されるアーカイブ内に、必要なファイルを持ち込みます。その後、initramfs 上のスクリプトは、システムがブートを継続する前に、パーティションが正しくマウントされていることを確実にします。

重要
genkernel を使用する場合は、カーネルおよび initramfs の両方をビルドするために使用するべきです。initramfs の生成のみのために genkernel を使用する場合、genkernel に --kernel-config=/path/to/kernel.config を渡すことが重要です。さもないと、生成された initramfs は手動でビルドされたカーネルとともに機能しないことがあります。手動でビルドされたカーネルは、ハンドブックのサポートの範囲外であることに注意してください。さらなる情報についてはカーネルコンフィギュレーションの記事を参照してください。

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

ファイル /etc/portage/package.use/installkernel

sys-kernel/installkernel dracut

または、initramfs を生成するために dracut を手動で呼び出してもかまいません。まず sys-kernel/dracut をインストールして、次に initramfs を生成させてください:

root #emerge --ask sys-kernel/dracut

root #dracut --kver=6.6.21-gentoo

initramfs は /boot/ に保存されるでしょう。結果のファイルは単に initramfs で始まるファイルを一覧表示することで確認できます:

root #ls /boot/initramfs*

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

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

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

systemd システムでは:

ファイル /etc/portage/package.use/systemd

sys-apps/systemd boot

OpenRC システムでは:

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

sys-apps/systemd-utils boot kernel-install

Installkernel は、それぞれ対応するフラグを有効化することで、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"

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

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

ジェネリック 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

セキュアブート

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

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

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

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

*/* dist-kernel

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

root #emerge --ask @module-rebuild

カーネルモジュール

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

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

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

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

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

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

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

root #

mkdir -p /etc/modules-load.d

root #

nano -w /etc/modules-load.d/network.conf

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

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

3c59x

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

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

ファイルシステムの情報

ファイルシステムラベルと UUID

MBR（BIOS）とGPTの両方が、ファイルシステムラベルとファイルシステムUUIDをサポートしています。これらの属性は、ブロックデバイスを探しマウントするために使用されるmountコマンドの代用として、/etc/fstab内で定義することができます。ファイルシステムラベルやファイルシステムUUIDはそれぞれLABELとUUID接頭辞で識別され、blkidコマンドで確認することができます：

root #blkid

警告
もし、パーティション内のファイルシステムが消滅すると、ファイルシステムのラベルとUUIDの値は後に変更されるか除去されます。

一意性のため、MBRスタイルのパーティションテーブルを使用している読者は、/etc/fstab内で、マウント可能なボリュームを定義するのにラベルよりもUUIDを用いることを推奨します。

重要
LVM ボリューム上に置かれたファイルシステムの UUID と、LVM ボリュームの LVM スナップショットの UUID は同じなので、LVM ボリュームをマウントするために UUID を使用するのは避けるべきです。

パーティションラベルと UUID

GPT ディスクラベルへのサポートを持つシステムでは、/etc/fstab でパーティションを定義するための '堅牢' な追加の選択肢が提供されます。パーティション自体にどのファイルシステムが使用されているかにかかわらず、ブロックデバイスの個々のパーティションを識別するのにパーティションラベルやパーティションの UUID を使うことができます。パーティションラベルとパーティションの UUID は PARTLABEL、PARTUUID 接頭辞で識別され、これらは端末で blkid コマンドを実行することで簡単に確認できます。

Discoverable Partition Specification の UUID を使用する amd64 EFI システムでの出力は、次のようになるでしょう:

root #blkid

/dev/sr0: BLOCK_SIZE="2048" UUID="2023-08-28-03-54-40-00" LABEL="ISOIMAGE" TYPE="iso9660" PTTYPE="PMBR"
/dev/loop0: TYPE="squashfs"
/dev/sda2: PARTUUID="0657fd6d-a4ab-43c4-84e5-0933c84b4f4f"
/dev/sda3: PARTUUID="1cdf763a-5b4c-4dbf-99db-a056c504e8b2"
/dev/sda1: PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"

パーティションラベルも絶対にとは言えないのに対し、fstab で UUID を使ったパーティション指定を使えば、たとえ将来ファイルシステムが変更されたり、再度書き込まれたりしても、ブートローダーがボリューム検出に迷うことはありません。従来のブロックデバイスファイル (/dev/sd*N) を使った指定は、SATA ブロックデバイスの追加または削除が日常的に行われるシステムでは危険です。

ブロックデバイスのファイル名は様々な要素 (ディスクがどんな順番でいくつ接続されているかを含む) によって変化します。またファイル名の順番についても、初期起動プロセス中にカーネルがどのデバイスを最初に検知するかによって変化します。つまり、システム管理者がディスクの順序を頻繁にいじったりしない限りは、デフォルトのブロックデバイスファイルを使うのがシンプルで素直な方法です。

fstab について

Linuxでは、システムで使用するすべてのパーティションは/etc/fstabに記載されていなければなりません。このファイルは、これらパーティションのマウントポイント（これらはファイルシステムに存在しなければなりません）、どのようにマウントされるべきか、また特別なオプション（自動マウントかそうでないか、ユーザー権限でマウントできるかどうか等）を定義します。

fstab ファイルを作成する

メモ
If the init system being used is systemd, the partition UUIDs conform to the Discoverable Partition Specification as given in Preparing the disks, and the system uses UEFI, then creating an fstab can be skipped, since systemd auto-mounts partitions that follow the spec.

/etc/fstabファイルは表のように記述します。それぞれの行はホワイトスペース（一つまたは複数のスペース、タブ、もしくはその 2 種の組み合わせ）で区切られる 6 つのフィールドを持ちます。それぞれのフィールドの意味は以下の通りです。

最初のフィールドはマウントされるブロックスペシャルデバイスやリモートファイルシステムを示します。デバイスファイルへのパスや、ファイルシステムラベルやファイルシステムUUID，そしてパーティションラベルやパーティションUUIDを含む、いくつかの種類のデバイスIDがブロックスペシャルデバイスノードとして使用可能です。
2番目のフィールドはそのパーティションがマウントされるマウントポイントを示します。
3番目のフィールドはそのパーティションのファイルシステムの種類を示します。
4番目のフィールドは、そのパーティションをマウントするmountコマンドが使用するオプションを示します。すべてのファイルシステムは、固有のマウントオプションを持っています。システム管理者はマウントコマンドのmanページ(man mount)を参照することですべてのオプションを確認できます。複数のマウントオプションを記述する場合はカンマで区切ります。
5番目のフィールドはそのパーティションをdumpでダンプするかどうかを示しています。このフィールドは通常0（ゼロ）のままにしておいてかまいません。
6番目のフィールドは、直前のシャットダウンが正常に完了しなかったときに、fsckが各パーティションをどの順番でチェックするか示しています。ルートファイルシステムは1であるべきです。残りのファイルシステムは2（ファイルシステムチェックが不要であれば0）に設定しましょう。

重要
Gentoo stage ファイルに含まれるデフォルトの /etc/fstab ファイルは有効な fstab ではなく、関連する値を入力するために使用できるテンプレートです。

root #nano /etc/fstab

DOS/レガシー BIOS システム

では、/boot パーティションをどのように記述すればよいか見てみましょう。これは一つの例です。実際はインストール手順の最初に決めたパーティション構成通りに修正しなければなりません。 x86 のパーティション構成の例として、/boot は通常は /dev/sda1 パーティションになり、推奨されるファイルシステムである xfs を使います。このパーティションはブート中にチェックされなければならないので、fstab は以下のようになるでしょう:

ファイル /etc/fstab/etc/fstab の DOS/レガシー BIOS boot 行の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
/dev/sda1   /boot     ext4    defaults        0 2

システム管理者によっては、セキュリティを向上させるために /boot パーティションを自動的にマウントしたくないかもしれません。その場合は defaults を noauto で置き換えてください。これは、そのパーティションを使いたいときは都度手動でマウントしなければならないことを意味します。

実際のパーティション構成にあわせたルールや、CD-ROMドライブのためのルールを追加してください。他にパーティションやドライブがあれば、それも忘れずに追加しておきましょう。

以下は、より詳細な/etc/fstabの例です。

ファイル /etc/fstabDOS/レガシー BIOS システム向けの完全な /etc/fstab の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
/dev/sda1   /boot        ext4    defaults    0 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            xfs    defaults,noatime              0 1

/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

UEFI システム

以下は UEFI ファームウェアを介してブートするシステムでの /etc/fstab ファイルの例です:

ファイル /etc/fstabUEFI システム向けの完全な /etc/fstab の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
/dev/sda1   /efi        vfat    umask=0077     0 2
/dev/sda2   none             sw                   0 0
/dev/sda3   /            xfs    defaults,noatime              0 1

/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

DPS UEFI PARTUUID

以下は、UEFI ファームウェア向けに GPT ディスクラベルと Discoverable Partition Specification (DPS) の UUID を使用してフォーマットされたディスクのための、/etc/fstab ファイルの例です:

ファイル /etc/fstabGPT ディスクラベル DPS PARTUUID fstab の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください。
# この例は Discoverable Partition Specification (DSP) UUID が設定された GPT ディスクラベルを示しています:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b   /efi        vfat    umask=0077                   0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f   none            sw                           0 0
PARTUUID=44479540-f297-41b2-9af7-d131d5f0458a   /           xfs    defaults,noatime              0 1

3番目のフィールドでautoを使う場合、mountコマンドはそのパーティションのファイルシステムが何かを推測します。これは様々なファイルシステムを使う可能性があるリムーバルメディアで推奨されます。4番目のuserオプションで、ルート権限を持たないユーザーがCDをマウントできるようになります。

パフォーマンスを改善するために、多くのユーザーはマウントオプションとして noatime オプションを付け加えたいと考えるでしょう。アクセス時間が記録されないので、結果としてより高速なシステムになります (一般的にこの記録はほとんど必要ありません)。ソリッドステートドライブ (SSD) を持つシステムでもこれはおすすめです。代わりに lazytime もまた考慮に値するかもしれません。

ヒント
パフォーマンスを低下させるため、/etc/fstab 内で discard マウントオプションを定義させるのは推奨されません。cron または timer (systemd) のようなジョブスケジューラを使用して、定期的にブロックの破棄をスケジュールするほうが、一般的により良い方法です。さらなる情報については、Periodic fstrim jobs を確認してください。

再度/etc/fstabを確認して、保存、エディタを終了します。

ネットワーク接続のための情報

重要な注意点として、このセクションは読者がシステムをローカルエリアネットワークに手っ取り早く参加させることができるように、提供しています。

OpenRC を動かしているシステムについては、ネットワーク設定のためのより詳細なリファレンスが、ハンドブックの終わりのほうの高度なネットワーク設定のセクションでカバーされています。より詳細なネットワーク要件のあるシステムは一度そちらへ飛んで、それからここに戻ってきて残りのインストール作業を続ける必要があるかもしれません。

より詳細な systemd のネットワーク設定については、systemd の記事のネットワークの箇所を確認してください。

ホスト名

さて、PCには名前をつけなければいけません。至極簡単に思えますが多くのシステム管理者はホスト名として適切な名前を付けるのに苦労しています。事を早く進めるために、選んだ名前は後で変更できることを知っておいてください。判りやすいように、ここでは単にマシンをtuxと呼ぶことにします。

ホスト名を設定する (OpenRC または systemd)

root #echo tux > /etc/hostname

systemd

現在実行中の systemd についてシステムのホスト名を設定するには、hostnamectl ユーティリティを使うことができます。しかしながらインストールプロセス中は、systemd-firstboot コマンドを代わりに使う必要があります (後でハンドブックの該当箇所を参照してください)。

ホスト名を "tux" に設定するためには、次のようにします:

root #hostnamectl hostname tux

hostnamectl --help または man 1 hostnamectl を実行することで、ヘルプを確認してください。

ネットワーク

ネットワークインターフェースを構成するために利用できる選択肢は多く存在します。この節ではそのうち一部の方法だけをカバーします。必要な構成に最適と思われるものをひとつ選んでください。

dhcpcd での DHCP (どんな init システムでも)

多くの LAN ネットワークは DHCP サーバは運用しています。その場合は、dhcpcd プログラムを使用して IP アドレスを取得するのがおすすめです。

インストールするには:

root #emerge --ask net-misc/dhcpcd

OpenRC システム上で、サービスを有効化して開始するには:

root #

rc-update add dhcpcd default

root #

rc-service dhcpcd start

systemd システム上で、サービスを有効化するには:

root #systemctl enable dhcpcd

これらのステップが完了したら、次にシステムが起動したときに、dhcpcd が DHCP サーバから IP アドレスを取得するはずです。さらなる詳細については Dhcpcd の記事を確認してください。

netifrc (OpenRC)

ヒント
これは OpenRC 上で Netifrc を使ってネットワークをセットアップするときに固有の方法です。他にも Dhcpcd のような、より簡潔なセットアップの方法も存在します。

ネットワークを設定する

Gentoo Linux をインストールしている間、ネットワークが使えるように設定されています。しかし、それは live 環境のためのネットワーク設定であり、インストールされた環境のためのものではありません。では、インストールされた Gentoo Linux のネットワークを設定しましょう。

メモ
bonding、ブリッジ、802.1Q VLAN、無線ネットワークに間するより詳細な情報は、追加のネットワーク設定セクションを参照してください。

すべてのネットワーク設定は/etc/conf.d/netにあります。直接的ではありますが、おそらく直感で理解できる構文ではありません。しかし恐れることはありません。すべては以下で説明されます。/usr/share/doc/netifrc-*/net.example.bz2に、多くの異なる設定に対して完全にコメントが付与された例が記載されています。

最初に net-misc/netifrc をインストールします。

root #emerge --ask --noreplace net-misc/netifrc

DHCPはデフォルトで使用されます。DHCPを動かすために、DHCPクライアントをインストールしなければなりません。これは Installing Necessary System Toolsで説明されます。

もし、特別なDHCPのオプションを設定している、もしくはDHCPをまったく使いたくない等の理由で、ネットワーク接続をしなければならないときは、/etc/conf.d/netを編集します。

root #nano /etc/conf.d/net

IPアドレスとルーティングを設定するのはconfig_eth0とroutes_eth0です。

メモ
ここではネットワークインターフェイスがeth0であると仮定していますが、これはシステムによって違います。もし、最近のインストールメディアから起動しているのであれば、インストール時と同じインターフェイス名が使われると思ってよいでしょう。より詳しい情報はネットワークインターフェースの命名セクションを参照してください。

ファイル /etc/conf.d/net静的 IP アドレスの定義

config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"

DHCPを使う場合は、config_eth0を設定してください。

ファイル /etc/conf.d/netDHCPの定義

config_eth0="dhcp"

さらなる設定オプションのリストについては、/usr/share/doc/netifrc-*/net.example.bz2を参照してください。もし特定のDHCPを設定しなければならないときは、DHCPクライアントのmanページも必ず読みましょう。

もし、システムが複数のネットワークインターフェースを持っている場合は、config_eth1、config_eth2、…に対して上記の手順を繰り返してください。

設定を保存し、エディタを終了しましょう。

起動時に自動でネットワーク接続する

ブート時にネットワークインターフェースを有効にする場合は、デフォルトランレベルにそれらを追加する必要があります。

root #

cd /etc/init.d

root #

ln -s net.lo net.eth0

root #rc-update add net.eth0 default

もし、複数のネットワークインターフェースがある場合は、net.eth0と同じ方法で、適切なnet.*ファイルを作成しなければなりません。

もし、ブート後、ネットワークインターフェース名（現在、このドキュメントではeth0と記述）が間違っていた場合、次の手順で修正してください。

正しいインターフェース名で/etc/conf.d/netファイルを更新します。（例えばeth0をenp3s0またはenp5s0と修正）
新しいシンボリックリンクを作成。（例えば/etc/init.d/net.enp3s0）
古いシンボリックリンクを消去。（rm /etc/init.d/net.eth0）
新しいスクリプトをデフォルトランレベルに追加。
rc-update del net.eth0 defaultで古いスクリプトを消去。

hosts ファイル

次の重要なステップは、この新しいシステムのネットワーク環境内の他のホストについて、システムに教えることかもしれません。ネットワークホスト名は /etc/hosts で定義することができます。ホスト名をここに追加することで、ネームサーバでは解決できないホストについて、ホスト名から IP アドレスを解決できるようになります。

root #nano /etc/hosts

ファイル /etc/hostsネットワーク情報の記述

# 以下は本システムの定義です。必ず設定されなければなりません。
127.0.0.1     tux.homenetwork tux localhost
  
# ネットワーク上にあるその他のホストの定義です。任意設定です。
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny

設定をセーブし、エディタを終了しましょう。

任意自由選択: PCMCIA を機能させる

PCMCIA のサポートが必要な x86 システムでは、sys-apps/pcmciautils パッケージをインストールする必要があります。この老朽化した 16 ビット技術へのサポートは、v6.4.0 でまずは 'char' デバイスから、本流の Linux カーネルから取り除かれつつあることに注意してください。

root #emerge --ask sys-apps/pcmciautils

システム情報

root パスワード

passwdコマンドでルートのパスワードを設定します。

root #passwd

後で、日常の作業のための一般ユーザーアカウントを作成します。

init と boot 設定

OpenRC

Gentoo で OpenRC を使用しているときは、OpenRC はシステムのサービス、スタートアップ、シャットダウンの設定に /etc/rc.conf を使います。/etc/rc.conf を開いて、ファイル中のすべてのコメントを楽しみましょう。設定をレビューして、必要な箇所を変更してください。

root #nano /etc/rc.conf

次に、キーボードを設定するために/etc/conf.d/keymapsを開いて、正しいキーボードを選択、設定します。

root #nano /etc/conf.d/keymaps

keymap変数に特に注意してください。もしキーマップを間違えた場合、キーボードを叩くたびに、奇妙な現象が起こるでしょう。

最後に、クロック設定をするために/etc/conf.d/hwclockを編集します。個々の好みに合わせて設定できます。

root #nano /etc/conf.d/hwclock

もし、ハードウェアクロックがUTCになっていない場合、このファイルにclock="local"を記述しなければなりません。そうでない場合、クロックスキューが発生するでしょう。

systemd

まず、システムが正しく起動できるようにするために、systemd-machine-id-setup と systemd-firstboot を順に実行することをおすすめします。これは、新しい systemd 環境への最初のブートのために、システムのさまざまなコンポーネントが正しく設定されるように準備します。次のオプションを渡すことで、ロケール、タイムゾーン、ホスト名、root パスワード、そして root シェル値を設定するための、ユーザへのプロンプトを含めます。加えて、システムにランダムなマシン ID を割り当てます:

root #systemd-machine-id-setup

root #systemd-firstboot --prompt

次に、インストールされているすべてのユニットファイルをプリセットのポリシー値にリセットするため、ユーザは systemctl を実行すべきです:

root #systemctl preset-all --preset-mode=enable-only

完全にプリセットにするには次で行えますが、これまでのプロセスで既に設定したすべてのサービスもリセットするかもしれません:

root #systemctl preset-all

live 環境からインストール先の最初のブートへのシームレスな移行を確実に行うために、これらの 2 ステップは有用でしょう。

← カーネルの設定 Home ツールのインストール →

システムロガー

OpenRC

同じ機能が複数のパッケージによって提供されるツールがいくつかあります。そういったツールはstage3アーカイブには含まれていません。どのパッケージをインストールしたいのかをあなた次第で選んでください。

まずシステムにロギング機構を提供するツールを決定しましょう。UnixとLinuxでは歴史をかけて素晴らしいログ機能を発展させてきました -- お望みならログファイルにシステムで起こった全てを記録できます。

Gentooでは複数のシステムロガーから使いたいものを選択することができます。このうちのいくつかを紹介します。

app-admin/sysklogdは、システムのログを取得するための伝統的なデーモンを集めたものです。デフォルトのログ設定をそのまま使ってもうまく働くので、このパッケージは初心者にはいい選択肢です。
app-admin/syslog-ngは、進化したシステムロガーです。1つの大きなファイルにログを取る以上のことをするには、何らかの設定が必要です。更に上級のユーザは、ロギングの発展性に基いてこのパッケージを選択できます。スマートなロギングのためには追加の設定が必要になることに注意してください。
app-admin/metalogは、高度な設定ができるシステムロガーです。

Gentoo ebuild リポジトリにはまだまだ他のシステムロガーがあることでしょう。日毎に利用可能なパッケージは増えていますから。

ヒント
もし syslog-ng を使おうと思っているなら、後で logrotate をインストールして設定しましょう。syslog-ng にはログファイルをローテーションする機構がありません。一方で、より新しいバージョン (>= 2.0) の sysklogd は自身でログローテーションを行います。

選択したシステムログツールをインストールするには、それを emerge してください。OpenRC では、rc-update を使ってデフォルトのランレベルにスクリプトを追加してください。次の例では app-admin/sysklogd をインストールして、それをシステムの syslog ユーティリティとして有効化します:

root #emerge --ask app-admin/sysklogd

root #rc-update add sysklogd default

systemd

ここまで OpenRC ベースのシステムのためにロギング機構の選択肢を提示しましたが、一方 systemd には systemd-journald という組み込みのロガーが含まれています。systemd-journald サービスは、上のシステムロガーの節で概説したロギング機能のほとんどを取り扱うことができます。つまり、システムマネージャおよびサービスマネージャとして systemd を実行するシステムのほとんどでは、追加の syslog ユーティリティを追加する部分を問題無く省略することができます。

journalctl を利用したシステムログの検索、閲覧についての詳細は、man journalctl を参照してください。

中央ホストへログを転送する場合などさまざまな理由により、systemd ベースのシステム上で冗長なシステムロギング機構を含めたいことがあるかもしれません。これはハンドブックの典型的想定読者にとっては一般的な事態ではなく、高度なユースケースであるとみなします。そのため、ハンドブックでは取り扱いません。

任意自由選択: cronデーモン

OpenRC

cronデーモンは入れても入れなくてもよく、システムに必須ではありませんが、インストールしておくのが賢明でしょう。

cron デーモンは、予定された間隔を空けてコマンドを実行します。間隔は毎日、毎週、毎月、毎火曜日、隔週、などで設定できます。賢明なシステム管理者は、定型的なシステム管理タスクを、cron デーモンを活用して自動化するでしょう。

すべての cron デーモンは予定されたタスクのための高いレベルの粒度をサポートしており、また通常は、予定されたタスクが期待通り完了しなかった場合に、e メール等の形式で通知を送信する機能を含んています。

Gentoo ではいくつもの cron デーモンを提供しています:

sys-process/cronie - cronie はオリジナルの cron をベースとしていて、PAM と SELinux を使用できるなど、セキュリティと設定の改良がなされています。
sys-process/dcron - この軽量な cron デーモンは、利便性を損わない範囲で、簡潔で安全であることを目標としています。
sys-process/fcron - cron および anacron の機能を含めて拡張されたコマンドスケジューラ。
sys-process/bcron - 安全な操作を念頭に入れて設計された、比較的新しい cron システム。これを実現するために、システムは複数の独立したプログラムに分けられていて、それぞれが独立したタスクに責任を持ち、プログラム間の通信は厳密に制御されています。

cronie

次の例では sys-process/cronie を使用します:

root #emerge --ask sys-process/cronie

電源投入時に自動で cronie を開始するために、cronie を default システムランレベルに追加してください:

root #rc-update add cronie default

代替案: dcron

root #emerge --ask sys-process/dcron

cron エージェントとして dcron を使う場合、初期設定のための追加コマンドが必要です。

root #crontab /etc/crontab

代替案: fcron

root #emerge --ask sys-process/fcron

スケジュールされたタスクハンドラとして fcron を選択した場合、追加で emerge ステップが必要です:

root #emerge --config sys-process/fcron

代替案: bcron

bcron は組み込みの特権分離を持つ、新しい cron エージェントです。

root #emerge --ask sys-process/bcron

systemd

システムロギングと同様に、sysmted ベースのシステムには予定されたタスクのためのサポートが、タイマーという形ですぐ使える状態で含まれています。systemd タイマーはシステムレベルでもユーザレベルでも実行することができ、伝統的な cron デーモンが提供するものと同じ機能を含んでいます。冗長な可能性が必要でない限り、cron デーモンのような追加のタスクスケジューラをインストールすることは通常は不要で、問題無く省略することができます。

任意自由選択: ファイルのインデックスを作成

より高速なファイル検索のためにファイルシステム中の各ファイルのインデックスを作成するときは、sys-apps/mlocateをインストールしてください。

root #emerge --ask sys-apps/mlocate

任意自由選択: リモートシェルアクセス

ヒント
opensshd のデフォルト設定は、リモートユーザとして root にログインすることを許可していません。必要であれば非 root ユーザを作成して、インストール完了後にアクセスできるように適切に設定するか、root を許可するように /etc/ssh/sshd_config を修正してください。

インストール後、システムにリモートからアクセスできるようにするためには、ブート時に sshd を開始するように設定する必要があります。

OpenRC

OpenRC で sshd init スクリプトを default ランレベルに追加するには:

root #rc-update add sshd default

(たとえばリモートサーバで)シリアルコンソールからアクセスしなければならない場合、agetty を設定する必要があります。

/etc/inittab のシリアルコンソールの部分のコメントを外してください:

root #nano -w /etc/inittab

# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100

systemd

SSH サーバを有効化するには、次を実行してください:

root #systemctl enable sshd

シリアルコンソールサポートを有効化するには、次を実行してください:

root #systemctl enable getty@tty1.service

省略可能: シェル補完

Bash

Bash は Gentoo システムのデフォルトのシェルですので、補完拡張をインストールすることでシステムの管理を効率的かつ便利にすることができます。app-shells/bash-completion パッケージは、Gentoo に固有のコマンドや多くの共通のコマンドとユーティリティで利用できる補完をインストールします:

root #emerge --ask app-shells/bash-completion

インストール後は、各コマンドのための bash 補完を eselect を通じて管理することができます。さらなる詳細については、bash の記事の Shell completion integrations のセクションを参照してください。

時刻同期

システム時刻を同期する方法を利用することは重要です。これは通常 NTP プロトコルおよびソフトウェアによってなされます。Chrony など、NTP プロトコルを使用する他の実装もあります。

例えば、Chrony をセットアップするには:

root #emerge --ask net-misc/chrony

OpenRC

OpenRC では、次を実行してください:

root #rc-update add chronyd default

systemd

systemd では、次を実行してください:

root #systemctl enable chronyd.service

代わりに systemd ユーザは、デフォルトでインストールされている、よりシンプルな systemd-timesyncd NTP クライアントを利用したいかもしれません。

root #systemctl enable systemd-timesyncd.service

ファイルシステムツール

使っているファイルシステムよって、(ファイルシステムの整合性をチェックしたり、ファイルシステムを (再) フォーマットするために) 必須のファイルシステムツールをインストールする必要があるかもしれません。ext4 ユーザ空間ツール(sys-fs/e2fsprogs) は @system 集合の一部としてインストール済みであることに注意してください。

次の表は、インストールされた環境に特定のファイルシステムのツールが必要な場合、どのツールをインストールすべきかを示します。

ファイルシステム	パッケージ
XFS	sys-fs/xfsprogs
ext4	sys-fs/e2fsprogs
VFAT (FAT32, ...)	sys-fs/dosfstools
Btrfs	sys-fs/btrfs-progs
ZFS	sys-fs/zfs
JFS	sys-fs/jfsutils

nvme 等のデバイスとともに適切にスケジューラを動作させるためには、sys-block/io-scheduler-udev-rules をインストールするのがおすすめです:

root #emerge --ask sys-block/io-scheduler-udev-rules

ヒント
Gentooのファイルシステムについてのさらなる情報は、ファイルシステムの記事を参照してください。

ネットワークツール

もし、以前のシステムの設定のステップでネットワークが構成されていて、それでネットワーク設定が完了している場合は、この 'ネットワークツール' のセクションは飛ばして問題ありません。その場合はブートローダーの設定に進みましょう。

DHCP クライアントをインストールする

重要
多くのユーザはネットワークに接続するために DHCP クライアントが必要になるでしょう。もし DHCP クライアントがひとつもインストールされていない場合、ネットワークに接続できないことになり、これにより DHCP クライアントを後でダウンロードすることができなくなってしまいます。

DHCP クライアントは、netifrc スクリプトを使用して、一つ以上のネットワークインターフェースのために自動的に IP アドレスを取得します。net-misc/dhcpcdがお薦めです (dhcpcd も参照してください):

root #emerge --ask net-misc/dhcpcd

任意自由選択: PPPoE クライアントのインストール

もしインターネットに接続するためにPPPを使うのであれば、net-dialup/pppパッケージをインストールします。

root #emerge --ask net-dialup/ppp

任意自由選択: 無線ネットワークツールのインストール

もしシステムをワイヤレス・ネットワークに接続させるつもりならば、オープンネットワークあるいはWEPネットワークを使用するためにnet-wireless/iwパッケージを、あるいはWPAまたはWPA2ネットワークを使用するためにnet-wireless/wpa_supplicantパッケージをインストールしてください。iwはまた、ワイヤレス・ネットワークの検出のための便利で基本的な診断ツールでもあります。

root #emerge --ask net-wireless/iw net-wireless/wpa_supplicant

次はブートローダーの設定です。

← システムの設定 Home ブートローダーの設定 →

32ビット CPU 用にインストールする場合でも、UEFI をサポートしているほぼすべての x86 マザーボード(2006-2007年頃から現在までのもの)は 64ビット UEFI ファームウェア を持っています。以下の節で "64" が設定やファイル名に出てくることに気付いたユーザーもいるかもしれません。これはほぼすべてのケースにおいて意図されたものです。

この64ビットファームウェアの法則にはいくつかのごくわずかな例外があります。というのは、ごく一部の初期の Apple Mac と、Intel Atom を搭載した Dell のタブレット PC のいくつかは32ビットファームウェアをサポートしています。読者のほとんどは、32ビット UEFI ファームウェアに実際に出会うことはないでしょう。そのため32ビット UEFI ファームウェアは x86 ハンドブックでは扱いません。

ブートローダを選ぶ

これまでLinuxカーネルを設定すると共に、システムツールをインストールし、設定ファイルを修正してきました。そして今、最も重要なLinuxインストールの最後の一片をインストールします。それがブートローダーです。

ブートローダーは、ブート中にLinuxカーネルを起動することに責任を負っています。ブートローダーがないと、システムは電源ボタンが押されたときに、どう事を進めればいいのかわからなくなってしまいます。

x86 に対して私たちは、DOS/レガシー BIOS ベースのシステムについては GRUB または LILO を設定する方法を、UEFI システムについては GRUB または efibootmgr を設定する方法を文書化しています。

このセクションでは、ブートローダーパッケージの "emerge" と、ブートローダーのシステムへの "インストール" という表現を使っています。ここでいう "emerge" とは Portage を使ってソフトウェアパッケージがシステムで利用できるようにすることです。そして "インストール" はブートローダーが必要なファイルをコピーしたりディスク上の特定の領域に変更を加えることで、ブートローダーを有効化し次回起動時に使用可能な状態にすることを指します。

デフォルト: GRUB

デフォルトでは、大半の Gentoo システムが GRUB Legacy の後継である GRUB (sys-boot/grub パッケージで利用できます) を使用しています。GRUB は追加の設定なしに従来の BIOS ("pc") システムで使うことができ、それ以外のプラットフォームでもビルド前のわずかな設定で済みます。詳しくは、GRUB ページの前提条件節をご覧ください。

Emerge

MBR パーティションテーブルのみをサポートする従来の BIOS システムを使う場合、GRUBをインストールするのに追加の設定は必要ありません:

root #emerge --ask --verbose sys-boot/grub

UEFI ユーザーの方へ: 上記のコマンドを実行すると、現在有効な GRUB_PLATFORMS 値が表示されます。UEFI 対応のシステムでは GRUB_PLATFORMS="efi-64" が有効になっていることを確認してください (これがデフォルトです) 。もし有効になっていなければ、GRUB パッケージを EFI の機能付きでビルドするために、 GRUB を emerge する前に /etc/portage/make.conf にGRUB_PLATFORMS="efi-64" を追加しなければなりません。

root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf

root #emerge --ask sys-boot/grub

なんらかの経緯で GRUB_PLATFORMS="efi-64" を有効にしていない状態で GRUB が emerge されてしまった場合は、この行を make.conf に追加して、 emerge に --update --newuse オプションを渡せば、 world パッケージセットの依存関係を再計算することができます:

root #emerge --ask --update --newuse --verbose sys-boot/grub

これで GRUB ソフトウェアがシステムにマージされましたが、二次ブートローダとしてのインストールはまだ完了していません。

インストール

つぎに、 grub-install コマンドを使って、必要な GRUB ファイルを /boot/grub/ ディレクトリにインストールします。もし（システムがブートする）一番目のディスクにインストールするなら、 /dev/sda ですので、以下のどちらかのコマンドでインストールすることができます:

DOS/レガシー BIOS システム

DOS/レガシー BIOS システムでは:

root #grub-install /dev/sda

UEFI システム

重要
grub-install を実行する前に EFI システムパーティションがマウントされているか必ず確認してください。 grub-install が GRUB EFI ファイル (grubx64.efi) を間違ったディレクトリにインストールしてしまい、しかも間違ったディレクトリが使われた形跡をまったく残さないということが起こりえます。

UEFI システムでは:

root #grub-install --efi-directory=/efi

Installing for x86_64-efi platform.
Installation finished. No error reported.

インストールに成功したら、出力は上のコマンドの出力と一致するはずです。出力が完全に一致していない場合は、GRUB をデバッグするへと進み、そうでない場合は設定の手順へと進んでください。

追加可能: セキュアブート

sys-boot/grub パッケージは secureboot USE フラグを認識しません。これは、GRUB EFI 実行可能形式はパッケージによってインストールされるのではなく、grub-install コマンドによってインストールされるからです。そのため GRUB は、ブートパーティションにインストールした後に手動で署名しなくてはなりません。また、GRUB はモジュール化されたブートローダですが、セキュアブートが有効化されているときにはモジュールのロードは禁止されています。そのため、必要なモジュールはすべて GRUB EFI 実行可能形式の中にコンパイルしなてくはなりません。いくつかの基本的なモジュールを含める例を以下に示します。より高度な構成のためには微調整する必要があるかもしれません:

root #emerge --noreplace sbsigntools

root #

export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"

root #grub-install --target=x86_64-efi --efi-directory=/efi --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv

root #

sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efi

セキュアブートを有効化して正常にブートするためには、UEFI ファームウェアによって使用された証明書が受け入れられるか、shim をプリローダとして使用しなくてはなりません。shim はサードパーティの Microsoft の証明書によって署名済みで、ほとんどの UEFI マザーボードによってデフォルトで受け入れられます。

カスタム鍵を受け入れるように UEFI ファームウェアを設定する方法はファームウェアの製造元によって異なり、このハンドブックの対象外です。代わりに以下に shim をセットアップするための方法を示します:

root #emerge sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/GRUB/shimx64.efi

root #cp /usr/share/shim/mmx64.efi /efi/EFI/GRUB/mmx64.efi

Shims MOKlist は DER 形式の鍵を要求します。ここの例で生成された OpenSSL 鍵は PEM 形式なので、まず変換する必要があります:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

メモ
ここで使用されるパスは、生成された鍵に属する証明書を含む pem ファイルへのパスでなくてはなりません。この例では鍵と証明書は同じ pem ファイル内にあります。

そして、変換された証明書を Shims MOKlist にインポートしてください:

root #mokutil --import /path/to/kernel_key.der

最後に、UEFI ファームウェアに Shim を登録します。次のコマンドでは、boot-disk と boot-partition-id はそれぞれ、EFI システムパーティションのディスクとパーティションの識別子で置き換えてください:

root #

efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\GRUB\shimx64.efi' --label 'shim' --unicode

GRUB をデバッグする

GRUB をデバッグするとき、新しい live イメージ環境へと再起動することなくインストール済みのシステムをブート可能にできるかもしれない簡単な解決策がいくつか存在します。

出力の中のどこかに "EFI variables are not supported on this system" が表示されている場合は、おそらく live イメージが EFI モードでブートされておらず、現在レガシー BIOS ブートモードにある可能性が高いです。解決方法としては、以下で言及されている removable オプションを使う GRUB の手順を試してください。これは /EFI/BOOT/BOOTX64.EFI にある実行可能 EFI ファイルを上書きします。EFI モードで再起動できれば、マザーボードファームウェアはこのデフォルトブートエントリを実行し、GRUB を実行できるかもしれません。

grub-install が "Could not prepare Boot variable: Read-only file system" というエラーを返し、live 環境が正しく UEFI モードでブートされている場合は、efivars という特別なマウントを読み書き可能な状態で再マウントしたうえで先述の grub-install コマンドを再実行できるはずです:

root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars

これは特殊な EFI ファイルシステムをデフォルトではマウントしない、特定の非公式 Gentoo 環境によって引き起こされます。上のコマンドが実行できない場合は、公式 live イメージ環境を EFI モードで使用して再起動してください。

一部のマザーボードメーカの貧弱な UEFI 実装では、EFI システムパーティション (ESP) 内の .EFI ファイルの置き場所として /EFI/BOOT ディレクトリしかサポートしていないようです。GRUB のインストーラは、インストールコマンドに --removable オプションを付けることで、自動でこの場所に .EFI ファイルを作成することができます。ESP がマウントされていることを確認してから、以下のコマンドを実行してください; (以前に定義した通り) /efi にマウントされているとして、以下を実行してください:

root #grub-install --target=x86_64-efi --efi-directory=/efi --removable

このコマンドは UEFI 仕様で定義されている'デフォルトの'ディレクトリを作成し、デフォルトの名前 bootx64.efi を持つファイルを作成します。

設定

次に、/etc/default/grub ファイルと /etc/grub.d スクリプトで指定されたユーザ固有の設定をもとに、GRUB 設定ファイルを生成します。GRUB はどのカーネルを起動するか（/boot/ 内で利用可能な最上位のもの）、どれがルートファイルシステムかを自動で検出してくれるので、ほとんどの場合、ユーザによる設定の必要はありません。カーネルパラメータは /etc/default/grub の GRUB_CMDLINE_LINUX 変数で指定することができます。

最終的な GRUB の設定ファイルを生成するには、 grub-mkconfig コマンドを実行します:

root #grub-mkconfig -o /boot/grub/grub.cfg

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-6.6.21-gentoo
Found initrd image: /boot/initramfs-genkernel-x86-6.6.21-gentoo
done

このコマンドの出力を見て、ブートに必要な Linux イメージが見つかったという報告が少なくともひとつあることを確認してください。もし initramfs を使っているか genkernel でカーネルをビルドしている場合は、正しい initrd イメージが認識されていることも確認してください。もし確認できなかった場合、/boot/ にそれらのファイルが存在するかどうか ls コマンドで確かめてください。必要なファイルが存在していなければ、カーネルの設定とインストールをやり直さなければなりません。

ヒント
接続されたドライブからほかのOSを検出するために、os-prober ユーティリティを使うこともできます。Windows 7、8.1、10、あるいはほかの Linux ディストリビューションが検出できるようになります。このようなデュアルブート環境を作るには、sys-boot/os-prober パッケージをインストールしてから grub-mkconfig コマンドを再実行するとよいでしょう。検出がうまくいかない時は、Gentoo コミュニティに助けを求める前に GRUB 記事をよく読み直してみてください。

代替案 1: LILO

Emerge

LILO (the LInuxLOader) は検証済みで、かつとても有用なLinuxのブートローダーです。しかしながら、GRUB と比べるといくつかの機能を欠いています。いくつかのシステムでは LILO は動作するものの GRUB は動作しないため、 LILO が今でも使われています。もちろん、 LILO をよく知っており使い続けたいと思っている人々もこれを使っています。どちらにしても、Gentoo は両方のブートローダーをサポートしています。

LILO のインストールは簡単です; emerge を使います。

root #emerge --ask sys-boot/lilo

設定

LILO の設定をするにはまず、/etc/lilo.conf を作成します:

root #nano -w /etc/lilo.conf

設定ファイルではブートできるカーネルを参照するためにセクションを使用しています。この設定ファイルで入力する必要があるので、カーネルファイル (カーネルバージョンも含む) や initramfs ファイルを確認しておいてください。

メモ
ルートファイルシステムが JFS の場合には読み書き可能なマウントの前にログをリプレイする必要があるため、append="ro" という行を各ブート項目の後に書き加えてください。

ファイル /etc/lilo.confLILO の設定例

boot=/dev/sda             # MBRにLILOをインストールする
prompt                    # ユーザに他のセクションを選択させる機会を与える
timeout=50                # デフォルトのセクションを起動する前に5秒間待つ
default=gentoo            # タイムアウトに達した場合、"gentoo"セクションを起動する
compact                   # これは劇的にロード時間を減らし、マップファイルをより小さくし続ける。いくつかのシステムでは失敗する場合がある。
  
image=/boot/vmlinuz-6.6.21-gentoo
  label=gentoo            # このセクションの名前
  read-only               # ルートを読み込み専用で始める。変えないこと！
  root=/dev/sda3          # ルートファイルシステムの場所
  
image=/boot/vmlinuz-6.6.21-gentoo
  label=gentoo.rescue     # このセクションの名前
  read-only               # ルートを読み込み専用で始める。変えないこと！
  root=/dev/sda3         # ルートファイルシステムの場所
  append="init=/bin/bb"   # Gentooの静的レスキューシェルを起動する
  
# 次の2行はWindowsとのデュアルブートのための行です。
# この例では、Windowsは/dev/sda6に格納されているとします。
other=/dev/sda6
  label=windows

メモ
異なるパーティション構成やカーネルイメージを使用している場合はそれに応じて調整してください。

initramfs が必要な場合、設定を変更してその initramfs ファイルを参照し、また initramfs に root デバイスの場所を渡すようにします:

ファイル /etc/lilo.confブートエントリーに initramfs の情報を加える

image=/boot/vmlinuz-6.6.21-gentoo
  label=gentoo
  read-only
  append="root=/dev/sda3"
  initrd=/boot/initramfs-genkernel-x86-6.6.21-gentoo

追加のオプションをカーネルに渡す必要がある場合には append 文を使います。たとえばフレームバッファーを有効化するために video 文を追加するには:

ファイル /etc/lilo.confブートオプションに video パラメータを追加する

image=/boot/vmlinuz-6.6.21-gentoo
  label=gentoo
  read-only
  root=/dev/sda3
  append="video=uvesafb:mtrr,ywrap,1024x768-32@85"

genkernel を使用したユーザーは、そのカーネルがインストール CD に使われたのと同じブートオプションを使用することを知っておいてください。たとえば SCSI デバイスのサポートを有効化する必要がある時は doscsi をカーネルオプションとして追加します。

それではファイルを保存して終了します。

インストール

仕上げに実行ファイル /sbin/lilo を起動して、LILO に /etc/lilo.conf の設定をシステムへ適用させます (つまり、自身をディスクにインストールさせます)。新しいカーネルをインストールしたりカーネルのファイル名が変更された際には、システムをブートさせるために lilo.conf ファイルに変更を加えるたびに /sbin/lilo を実行しなければならないことを覚えておいてください。

root #/sbin/lilo

代替案 2: efibootmgr

UEFI ベースのファームウェアを搭載したコンピュータシステムは、カーネルをブートするために二次ブートローダ (GRUB 等) を厳密には必要としません。二次ブートローダはブートプロセス中の UEFI ファームウェアの機能を拡張するために存在しています。GRUB を使用する (以前の節を参照してください) ほうが、ブート時のカーネルパラメータを簡単に変更するためのより柔軟なアプローチを提供しているので、典型的にはより簡単で、より堅牢です。

システムのブートについて最小限かつ厳格なアプローチをとるシステム管理者は、二次ブートローダを使用せずに、EFI スタブとして Linux カーネルをブートすることができます。

sys-boot/efibootmgr アプリケーションは、システムの一次ブートローダである UEFI ファームウェアと通信するためのツールです。通常このツールは、ファームウェアのブート可能エントリの一覧にブートエントリを追加または削除するために使われます。また、既にブート可能エントリとして追加されている Linux カーネルを追加のオプションとともに実行できるように、ファームウェア設定を更新することもできます。これらの通信は EFI 変数と呼ばれる特別なデータ構造を通して行われます (したがって、EFI 変数のカーネルサポートが必要です)。

続ける前に EFI スタブカーネルの記事を必ず確認してださい。カーネルを UEFI ファームウェアから直接ブートできるようにするには、特有のオプションを有効化しなければなりません。このサポートを組み込むために、カーネルの再コンパイルが必要になる場合があります。

追加の情報を得るために efibootmgr の記事を見てみるのも良い考えです。

メモ
繰り返しますが、efibootmgr は UEFI システムのブートにおいて必須ではありません; 単に UEFI ファームウェアに EFI スタブカーネルのためのエントリを追加するためだけに必要なものです。EFI スタブのサポート付きで適切にビルドされた Linux カーネルは、それ自体直接ブートさせることができます。追加のカーネルコマンドラインオプションも Linux カーネルの中に組み込むことができます (CONFIG_CMDLINE というカーネルの設定オプションがあります)。同様に、initramfs のサポートもカーネルの中に'組み込む'ことができます。これらの決定はカーネルのコンパイルに先立って行わなくてはならず、結果としてブートの構成はより静的なものとなります。

efibootmgr ソフトウェアをインストールしてください:

root #emerge --ask sys-boot/efibootmgr

/efi を作成して、カーネルをその中に bootx64.efi という名前でコピーしてください:

root #

mkdir -p /efi

root #

cp /boot/vmlinuz-* /efi/bootx64.efi

メモ
UEFI の定義には、ディレクトリパスの区切りにはバックスラッシュ (\) を用いなければなりません。

新しくコンパイルされた EFI スタブカーネルに対応する "gentoo" という名称のブートエントリを、UEFI ファームウェア内に作成してください:

root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\bootx64.efi"

初期 RAM ファイルシステム (initramfs) を用いるときには、適切なブートオプションを加えてください:

root #

efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\bootx64.efi" --unicode "initrd=\efi\initramfs-genkernel-x86-6.6.21-gentoo"

上のコマンドは、bootx64.efi ファイルと同じ ESP 内のディレクトリに initramfs ファイルがコピーされていることを前提としていることに注意してください。

これらの変更が完了したら、システムを再起動後から、"gentoo" という名称のブートエントリーが利用可能になります。

Unified カーネルイメージ

installkernel が unified カーネルイメージをビルドしてインストールするように構成されているなら、unified カーネルイメージはすでに EFI システムパーティション上の EFI/Linux ディレクトリにインストールされているはずです。もしそうなっていない場合は、ディレクトリが存在することを確認してから、ハンドブックで既に説明した通りにカーネルインストールを再度実行してください。

インストールされた unified カーネルイメージのためのブートエントリを直接追加するには:

root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader /efi/EFI/Linux/gentoo-x.y.z.efi

代替案 3: Syslinux

Syslinux は x86 アーキテクチャ用のもう一つの代替ブートローダーです。MBR をサポートしており、バージョン 6.00 からは EFI ブートもサポートしています。また、PXE (ネットワーク) ブートやあまり知られていないオプションもサポートします。Syslinux は多くの人々に人気のあるブートローダーですが、このハンドブックではサポートしていません。このブートローダーの emerge やインストールに関する情報は Syslinux の記事で得ることができます。

代替案 4: systemd-boot

別の選択肢として systemd-boot もあり、これは OpenRC と systemd のマシンの両方で動作します。これは薄いチェーンローダであり、セキュアブートと合わせてうまく動作します。

systemd-boot をインストールするには:

root #bootctl install

重要
bootctl install を実行する前に、EFI システムパーティションがマウントされていることを確認してください。

このブートローダを使用するときは、リブートする前に、以下を使用してブート可能なエントリが存在することを確認してください:

root #bootctl list

新しいエントリが存在しない場合は、sys-kernel/installkernel パッケージが systemd-boot USE フラグを有効化した状態でインストールされていることを確認して、カーネルインストールを再実行してください。

ディストリビューションカーネルについては:

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

手動で設定およびコンパイルされたカーネルについては:

root #make install

重要
systemd-boot 向けにカーネルをインストールする場合、root= カーネルコマンドライン引数はデフォルトでは追加されません。initramfs を使用する systemd システム上で、ブート時にルートパーティションを自動的に見つけるためには、ユーザは代わりに systemd-gpt-auto-generator に頼ることができます。そうしない場合ユーザは、/etc/kernel/cmdline 内で、使用すべき他のカーネルコマンドライン引数と並んで root= を設定することで、手動でルートパーティションの場所を指定するべきです。その後、上記の通りにカーネルを再インストールしてください。

追加可能: セキュアブート

secureboot USE フラグが有効化されている場合、systemd-boot EFI 実行可能形式は自動的に署名されるでしょう。bootctl install は自動的に署名されたバージョンをインストールするでしょう。

セキュアブートを有効化して正常にブートするためには、UEFI ファームウェアによって使用された証明書が受け入れられるか、shim をプリローダとして使用しなくてはなりません。shim はサードパーティの Microsoft の証明書によって署名済みで、ほとんどの UEFI マザーボードによってデフォルトで受け入れられます。

カスタム鍵を受け入れるように UEFI ファームウェアを設定する方法はファームウェアの製造元によって異なり、このハンドブックの対象外です。代わりに、systemd-boot を自動的に更新して shim とともに構成するための postinst フックが systemd-boot wiki ページで提供されています。しかし、初回は以下の手順に従って、これを手動で行うべきです:

root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFI

root #cp /usr/share/shim/mmx64.efi /efi/EFI/BOOT/mmx64.efi

root #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efi

メモ
shim は grubx64.efi をロードするようにハードコードされています。そのため systemd-boot ブートローダには、あたかもそれが GRUB であるかのように名前を付けなくてはなりません。

Shims MOKlist は DER 形式の鍵を要求します。ここの例で生成された OpenSSL 鍵は PEM 形式なので、まず変換する必要があります:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

メモ
ここで使用されるパスは、生成された鍵に属する証明書を含む pem ファイルへのパスでなくてはなりません。この例では鍵と証明書は同じ pem ファイル内にあります。

そして、変換された証明書を Shims MOKlist にインポートしてください:

root #mokutil --import /path/to/kernel_key.der

最後に、UEFI ファームウェアに Shim を登録します。次のコマンドでは、boot-disk と boot-partition-id はそれぞれ、EFI システムパーティションのディスクとパーティションの識別子で置き換えてください:

root #

efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\BOOT\BOOTX64.EFI' --label 'shim' --unicode

システムのリブート

chroot環境を出て、全てのパーティションをアンマウントします。次に、最終かつ真のテストを実行するためのマジカルコマンドrebootを入力しましょう。

(chroot) livecd #exit

livecd~#

cd

livecd~#

umount -l /mnt/gentoo/dev{/shm,/pts,}

livecd~#

umount -R /mnt/gentoo

livecd~#reboot

live イメージを取り出すのを忘れないでください。そうしないと新しくインストールされた Gentoo ではなく、live イメージが再度ブート対象になってしまうかもしれません！

リブートして新しい Gentoo 環境に入ることができたら、最終章のインストールの締めくくりに進むのがよいでしょう。

← ツールのインストール Home インストールの締めくくり →

ユーザー管理

日常的な使用のためのユーザを追加する

Unix/Linux システム上で root として作業するのは危険であり、できるだけ避けるべきです。そのため、日常的に使用するための標準のユーザアカウントを、一つまたは複数追加することを、強くお勧めします。

グループは、そのグループに所属するメンバーができることを定義します。次の表はいくつかの重要なグループを示します。

グループ	説明
audio	ユーザアカウントがオーディオデバイスにアクセスできるようにします。
cdrom	ユーザアカウントが光学デバイスに直接アクセスできるようにします。
cron	ユーザアカウントが cron による時間ベースのジョブスケジューリングにアクセスできるようにします。メモ: systemd サービスシステムを実行するシステム上のユーザアカウントは、cron ジョブの代わりに systemd タイマとユーザサービスファイルを使用することができます。
floppy	ユーザアカウントが、フロッピードライブとして知られる、古代の機械的デバイスに直接アクセスできるようにします。このグループは現代的なシステムでは通常は使用されません。
portage	ユーザアカウントが、Portage グループでのみ利用可能な特定の資源にアクセスできるようにします。これは Gentoo の開発とトラブルシューティング目的のために有用です。
usb	ユーザアカウントが USB デバイスにアクセスできるようにします。
video	ユーザアカウントが、ビデオキャプチャのためのハードウェアと、ハードウェアアクセラレーションにアクセスできるようにします。
wheel	ユーザアカウントが su (substitute user) コマンドを使うことができるようにし、root アカウントや他のアカウントに切り換えることを許可します。root アカウントを持つシングルユーザシステムでは、メインの標準ユーザをこのグループに追加するのが良い考えでしょう。

例えば wheel、users、audio の 3 グループに所属する larry というユーザを作成するには、最初に root としてログインし (root だけがユーザを作ることができます)、useradd を実行します:

Login:root

Password: (rootのパスワードを入力してください)

標準ユーザアカウントにパスワードを設定するときに、root ユーザに設定したものと同一または似ているパスワードを使用することを避けるのは、セキュリティ上の良いプラクティスです。

ハンドブックの著者としては、少なくとも 16 文字の長さを持ち、システム上の他のどのユーザとも異なる値を持つパスワードを使用することを推奨します。

root #

useradd -m -G users,wheel,audio -s /bin/bash larry

root #passwd larry

Password: (larryのパスワードを入力してください)
Re-enter password: (確認のためにもう一度パスワードを入力してください)

一時的に権限を昇格する

もし、root で何か作業をする場合は、一時的に root 権限を得るために su - を使います。別の方法は sudo (app-admin/sudo) または doas (app-admin/doas) ユーティリティを使用することです。これらは (正しく設定されれば) とても安全です。

root ログインを無効化する

潜在的な脅威アクターが root としてログインできないようにするために、root パスワードの削除および/または root ログインの無効化によって、セキュリティを向上させることができます。

root ログインを無効化するには:

root #passwd -l root

root パスワードを削除して、ログインを無効化するには:

root #passwd -dl root

ディスクのクリーンアップ

インストール用配布物の削除

Gentoo のインストールとリブートが完了し、インストールがすべてうまくいっていれば、stage ファイルやその他のインストール用配布物 - DIGEST、CONTENT、*.asc (PGP 署名) ファイルなど - は安全に削除することができます。

ファイルは / ディレクトリに置かれているので、以下のコマンドで削除することができます:

root #rm /stage3-*.tar.*

次にすることは？

次に何をすればいいかわかりませんか？探索する道が多くあります。Gentooには多くの可能性と共にユーザーが存在します。それゆえ、このwikiや他のGentooに関連するサブドメイン群（下の Gentoo オンラインを見てください）を探索するため、多くのドキュメント化された機能を使うことができます（記述量は多くないのですが…）。

さらなるドキュメント

重要な注意事項として、Gentoo で採用できる選択肢の多さから、このハンドブックが提供するドキュメントの範囲は一部に限られています。ハンドブックの主眼は、Gentoo システムを構築して基本的な管理活動を行えるようにすることに置いています。ハンドブックはあえて、グラフィカル環境、セキュリティ強化 (hardening) についての詳細、その他重要な管理タスクについての指示を除外しています。とはいえ、基本的な機能に関して読者を助けるため、ハンドブックのセクションをまだいくつか用意しています。

読者は絶対に、ハンドブックの Gentoo の操作を読むべきです。これにはソフトウェアをどのように最新の状態にしておくのか、追加のソフトウェアパッケージをどのようにインストールするのか、USE フラグや Gentoo の OpenRC 初期システムの詳細や、インストール後の Gentoo システムを扱うことに関する他の様々な有益なトピックについてが説明されています。

ハンドブック以外では、コミュニティから追加提供されるドキュメントを見つけるために、Gentoo wiki の他のコーナーを探索したいと思うでしょう。Gentoo wiki チームは、documentation topic overview を提供しています。これは、この Wiki にある記事のセレクションをカテゴリー別に一覧にしています。例えば、システムをよりあなたの国に適したものとするためには、ローカライゼーションガイドを参照します（特に英語を第二外国語として話すユーザにとって便利なものです）。

デスクトップ用途で利用したい多数派のユーザは、日常的に使用するためのグラフィカル環境をセットアップすることになるでしょう。対応しているデスクトップ環境 (DE) とウィンドウマネージャ (WM) については、コミュニティによって維持されている 'メタ' 記事が多数存在します。それぞれの DE が必要なセットアップ作業は微妙に異なっているため、ブートストラップ作業の複雑性が増えることに注意してください。

その他にも、Gentoo 上で利用可能なソフトウェアについての俯瞰的な概要を提供するメタ記事が多数存在します。

Gentoo オンライン

重要
読者は、すべての公式の Gentoo オンラインサイトが Gentoo の行動規範によって治められていることに注意するべきです。Gentoo のコミュニティで活動することは特権で、権利ではありません。そしてユーザは、行動規範が理由があるために存在することを知っていると見なされます。

Libera.Chatが運営するInternet Relay Chat（IRC）ネットワークと、メーリングリストを除いて、ほとんどのGentooのウェブサイトは質問をしたり、議論を開始したり、バグを報告するために、サイト単位でアカウントを必要とします。

フォーラムと IRC

私たちのGentoo forumsや多くのInternet Relay Chat Channelsの一つに参加することはウェルカムです。新規のGentooのインストールの最中に遭遇した問題が、過去に発見されたか、またその後いくつかのフィードバックの後に解決したかをフォーラムで調べるのは簡単です。初めてのGentoo故に他のユーザがインストールの問題を経験する可能性は驚くべきものです。ユーザはGentooサポートチャンネルで手助けを求める前に、フォーラムやwikiを調べるよう勧められています。

メーリングリスト

フォーラムやIRCでアカウントを作成するよりはむしろ、メール上でサポートやフィードバックを求めるほうがいいというコミュニティメンバーのために、いくつかのメーリングリストが利用可能です。ユーザは特定のメーリングリストを購読するために説明に従う必要があります。

バグ

時々、wikiを見たり、フォーラム内を探したり、IRCチャンネルやメーリングリストにサポートを求めても、問題に対する既知の解決策がない場合があります。一般的にこれは、GentooのBugzillaサイトにバグを公開する合図です。

開発ガイド

Gentooの開発についてより多くのことを学びたいと考えている読者は、開発ガイドを見ると良いでしょう。このガイドにはebuildの書き方、eclassの扱い方についての説明や、Gentooの開発の背後にある、多くの一般概念の定義が載っています．

締めくくり

Gentooは堅固で、柔軟でそして素晴らしく維持されたディストリビューションです。開発者コミュニティは、Gentooをどのようにさらによりよいディストリビューションにするかについてのフィードバックを聞けることを嬉しく思います。

確認として書いておきますが、このハンドブックに対するすべてのフィードバックは、ガイドライン（ハンドブックのはじめにあるどうやってハンドブックを改善しますか？のセクションに詳細があります）に従っているべきです。

We look forward to seeing how our users will choose to implement Gentoo to fit their unique use cases and needs.

← ブートローダーの設定 Home Portageについて →

Warning: Display title "Gentoo Linux x86 ハンドブック: Gentoo をインストールする" overrides earlier display title "ハンドブック:X86/フル/インストール".

[1] ttps://gitweb.gentoo.org/proj/portage.git/commit/?id=5d2af567772bb12b073f1671daea6263055cbdc2

[2] ttps://gitweb.gentoo.org/proj/portage.git/commit/?id=de7be7f45ee54e3f789def46542919550687d15e

[6] ttps://www.gnu.org/licenses/license-list.html

[7] ttps://www.opensource.org/licenses

[8] ttps://www.gnu.org/philosophy/free-sw.html

[9] ttps://freedomdefined.org/

[3] ttps://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

[4] ttps://www.gentoo.org/glep/glep-0023.html#id7

[5] ttps://www.gentoo.org/glep/glep-0023.html#id7

[1]

[2]

[1]

[2]

[3]

[a_license 1]

[a_license 2]

[a_license 3]

[a_license 4]