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

はじめに

ようこそ

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 インストールメディアを用いる方法と、場合によってはネットワークブートによる方法です。

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

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

トラブルがあったときは

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

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

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

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

ハードウェア要件

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

	Minimal CD	LiveDVD
CPU
Memory
Disk space
Swap space

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

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

Minimal インストール CD

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

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

Gentoo LiveGUI

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

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

stage ファイルとは?

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

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

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

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

ダウンロード

メディアの入手

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

Gentoo ミラーに移動する

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

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

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

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

CODE 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ファイルも同じようにダウンロードします。

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

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

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

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

Microsoft Windows 上での検証

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

Linux 上での検証

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

Tip
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--minimal-20240107T170309Z.iso.asc

gpg: assuming signed data in 'install--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の署名のページ上にある指紋かどうかを調べます。

Note
インポートされた鍵が信頼に足ると確証が持てたら、その鍵を信頼されたものとしてマークすることは、一般的に良いプラクティスです。信頼された鍵が検証されるときには、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 を得ることができます。

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

dd で書き込む

Warning
ターゲットは上書きされるので、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

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

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

ディスクに書き込む

See also
より詳しい手順は 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--minimal-20141204.iso

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

起動する

Note
This is a placeholder for architecture-specific booting information

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

インストールメディアが起動するとき、すべてのハードウェア機器を検出して適切なカーネルモジュールを読み込もうとします。これは非常に多くの場合、とても良い仕事をします。しかしある場合において、システムに必要なカーネルモジュールを自動で読み込まないかもしれません。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:Parts/ja

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

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

GNU Screen

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

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

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

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

root #rc-service sshd start

Note
ユーザーがシステムにログオンすると、(指紋・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 情報を取得するためにも使用されます。

Tip
公式 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

See also
Dhcpcd の使い方

ネットワークのテスト

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

root #ip route

default via 192.168.0.1 dev enp1s0

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

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

root #ping -c 3 1.1.1.1

Tip
ホスト名ではなく、既知の 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) が続きます。

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

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

Note
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 であるとしましょう。

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

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 を構成する

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

Important
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

Note
無線カードのデバイス名は、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

Note
無線ネットワークが 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 または静的アドレッシングを構成するでしょう。

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

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

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

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

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

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

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

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

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

ネットワークと CIDR

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

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

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

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

Tip
最もよく使用される 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) 上のホストと通信できるようになるはずです。

インターネット

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

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

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

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

まとめると:

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

ドメインネームシステム

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

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

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

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

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

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

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

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

root #ip address add 192.168.0.2/24 dev enp1s0

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

デフォルトルート構成

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

root #ip route

192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2

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

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

root #ip route add default via 192.168.0.1

DNS 構成

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

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

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

root #nano /etc/resolv.conf

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

FILE /etc/resolv.confQuad9 DNS を使用する。

nameserver 9.9.9.9
nameserver 149.112.112.112

FILE /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) ごとの連続領域としてアドレッシングできます。

Introduction to block devices

Block devices

Note
Placeholder for introduction to block devices specific to that architecture

Designing a partition scheme

Note
Placeholder for designing a partition scheme specific to that architecture

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

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

はじめに

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

ファイルシステム

Linux は多くのファイルシステムをサポートしていますが、それらの多くは特定の目的をもって配備するのが賢明なものです。特定のファイルシステムのみが アーキテクチャ上で安定して動作するとされています - 重要なパーティションに実験的なファイルシステムを選択するときは、事前にファイルシステムのサポート状況を十分に知っておくことを推奨します。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 とデータ交換の相互運用のためにのみ使うべきです (のみの強調に注意してください)。

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

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

Note
再起動する前に、選択したファイルシステムに関連するユーザ空間ユーティリティを 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

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

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

root #mkfs.

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

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

root #mkfs.vfat -F 32

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

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

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

root #mkfs.xfs

小さな ext4 パーティション

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

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

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

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

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

root #mkswap

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

root #swapon

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

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

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

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

root #mkdir --parents

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

root #mkdir --parents

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

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

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

root #mount

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

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

root #chmod 1777 /tmp

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

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

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

stage ファイルを選択する

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

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

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

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

Tip
大部分のユーザは、'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 ビット)

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

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

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

非 multilib (64 ビットのみ)

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

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

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

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

root #cd

日時を設定する

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

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

root #date

Mon Oct  3 13:16:22 PDT 2021

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

自動

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

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

root #chronyd -q

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

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

手動

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

Note
すべての 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//autobuilds/ ディレクトリに移動してください。入手可能なすべてのstageファイルが列挙されています。ファイルは、サブアーキテクチャにちなんだ名前のサブティレクトリの中にあることもあります。ファイルを選び、dを押してダウンロードしてください。

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

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

検証して確認する

Note
今では、ほとんどの 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--<release>-<init>.tar.xz

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

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

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

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

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

root #sha256sum --check stage3--<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--<release>-<init>.tar.xz.asc

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

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

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

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

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

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

root #tar xpvf --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 による設定は永続的なものではありません。

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

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

Note
/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 ファイルアーカイブに含まれるデフォルト値で十分でしょう。以下に例を示します:

CODE CFLAGSとCXXFLAGS変数の設定例

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

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

MAKEOPTS

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

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

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

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

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

FILE /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 /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/はファイルシステムの新しいエントリ（インスタンスとも言えるでしょう）となります。

Tip
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

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

Warning
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ステップで実行されます。

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

root #chroot /mnt/gentoo /bin/bash

root #source /etc/profile

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

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

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

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

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

UEFI システム

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

root #mkdir

root #mount

DOS/レガシー BIOS システム

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

root #mount

Portage を設定する

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

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

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

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

root #emerge-webrsync

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

この時点で、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

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

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

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

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

root #eselect profile list

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

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

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

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

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

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

root #eselect profile set 2

Note
This is a placeholder for architecture-specific profile information

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

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

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

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

リポジトリの構成

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

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

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

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

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

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

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

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

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

FILE /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 ..."

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

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

root #less /profiles/use.desc

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

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

root #nano /etc/portage/make.conf

FILE /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 を設定することでこれを行えます:

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

USE="-X acl alsa"

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

CPU_FLAGS_*

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

Important
混乱しないで! 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 変数の例です。使用するドライバの名前の部分は置き換えてください。

FILE /etc/portage/make.conf

VIDEO_CARDS="amdgpu radeonsi"

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

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

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

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

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

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

名前	説明
@GPL-COMPATIBLE	フリーソフトウェア財団によって承認された、GPLと両立するライセンス (GPL compatible license) 群
@FSF-APPROVED	FSF (訳注: フリーソフトウェア財団) によって承認された自由ソフトウェアライセンス群 (@GPL-COMPATIBLE を含みます)
@OSI-APPROVED	Open Source Initiative によって承認されたライセンス群
@MISC-FREE	おそらく自由ソフトウェアであるその他のライセンス群。言い換えると、自由ソフトウェアの定義に従っているものの、FSF や OSI によって承認されていないライセンス
@FREE-SOFTWARE	@FSF-APPROVED、@OSI-APPROVED、および @MISC-FREE を組み合わせたもの。
@FSF-APPROVED-OTHER	FSF が承認した「自由な文書」および「ソフトウェアや文書以外の実用の著作物のライセンス」 (フォントを含む)
@MISC-FREE-DOCS	自由の定義に従っているが、@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 で、プロファイルによってシステム全体のデフォルトとなっているライセンス設定を無視することができます:

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

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

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

root #mkdir /etc/portage/package.license

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

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

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

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

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

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

1. プロファイルのターゲットが、stage ファイルを選択したときのものと異なっている。
2. インストールされたパッケージに追加の 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

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

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

タイムゾーン

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

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

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

systemd

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

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

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

ロケールの設定

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

ロケールの生成

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

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

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

root #nano /etc/locale.gen

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

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

Warning
多くのアプリケーションは適切にビルドするのに少なくとも 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 ファイルも編集してください。

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

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

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

Architecture specific firmware

Note
Placeholder for architecture-specific firmware information

マイクロコード

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

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

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

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

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

root #emerge --ask sys-kernel/installkernel

ベースのシステムにカーネルを手動でインストールしてコンパイルする場合には、Gentoo はsys-kernel/ パッケージを推奨しています。

適切なカーネルソースを選択して、emerge でインストールします:

root #emerge --ask sys-kernel/

このコマンドはカーネルソースを /usr/src/ の下に、カーネルバージョン毎のパスを分けてインストールします。選択されたカーネルソースパッケージに対して symlink USE フラグが有効化されていなければ、シンボリックリンクは自動で作成されません。

現在実行しているカーネルに対応するソースを指すように、/usr/src/linux シンボリックリンクを維持することは慣例となっています。しかし、このシンボリックリンクはデフォルトでは作成されないでしょう。シンボリックリンクを作成する簡単な方法は、eselect の kernel モジュールを利用することです。

シンボリックリンクの目的と、それを管理する方法についてのさらなる情報は、Kernel/Upgrade を参照してください。

まず、インストールされているカーネルを一覧表示します:

root #eselect kernel list

Available kernel symlink targets:
  [1]   linux-

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-

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

はじめに

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

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

しかし、一つだけ真実があります。カーネルをマニュアルで設定する時、ハードウェア情報を知ることはとても役に立ちます。ほとんどの情報は、lspciコマンドを含むsys-apps/pciutilsをインストールすることで得られます。

root #emerge --ask sys-apps/pciutils

Note
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 固有のコンフィギュレーションオプションを有効化することを強く推奨します。これらは、正しく機能するために必要な最小限のカーネルの機能が有効化されることを確実にします:

KERNEL 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):

KERNEL 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):

KERNEL SCSI ディスクサポートを有効にする (CONFIG_SCSI, CONFIG_BLK_DEV_SD)

Device Drivers --->
  SCSI device support  ---> 
    <*> SCSI device support
    <*> SCSI disk support

KERNEL 基本的な 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 サポートが有効になっているか確認してください:

KERNEL Linux 4.4.x で基本的な NVMe サポートを有効化する (CONFIG_BLK_DEV_NVME)

Device Drivers  --->
  <*> NVM Express block device

KERNEL Linux 5.x.x で基本的な NVMe サポートを有効化する (CONFIG_DEVTMPFS)

Device Drivers --->
  NVME Support --->
    <*> NVM Express block device

以下の追加の NVMe サポートを有効化しても害はありません:

KERNEL 追加の 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個以上を選択してください:

KERNEL ファイルシステムサポートを有効化する (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):

KERNEL 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):

KERNEL SMP サポートを有効にする (CONFIG_SMP)

Processor type and features  --->
  [*] Symmetric multi-processing support

Note
マルチコアシステムでは、それぞれのコアが１プロセッサとカウントされます。

USB接続の入力装置（キーボードやマウス）などのUSBデバイスを使用する場合、以下を必ず有効にしてください:

KERNEL 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 を有効化してください:

KERNEL カーネルモジュールに署名する 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 も有効化してください:

KERNEL 署名済みカーネルモジュールを強制する 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

KERNEL 署名鍵を指定する 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 フラグを有効化してください:

FILE /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 です

Note
MODULES_SIGN_KEY と MODULES_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。

省略可能: カーネルイメージに署名する (セキュアブート)

(セキュアブートが有効化されたシステムで使用するために) カーネルイメージに署名する場合には、以下のカーネルコンフィグオプションを設定することが推奨されます:

KERNEL セキュアブートのためのロックダウン

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) とともにビルドしなくてはなりません:

KERNEL 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

Note
この例では、カーネルイメージに署名するために、モジュールに署名するために生成されたのと同じ鍵が使用されています。カーネルイメージに署名するために、2 個目の別の鍵を生成して使用することも可能です。前節と同じ OpenSSL コマンドをもう一度使用することができます。

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

他のパッケージによってインストールされる EFI 実行可能形式に自動的に署名するには、グローバルに secureboot USE フラグを有効化してください:

FILE /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"

Note
SECUREBOOT_SIGN_KEY と SECUREBOOT_SIGN_CERT は異なるファイルにすることもできます。この例では、OpenSSL によって生成される pem ファイルには鍵とそれに伴う証明書の両方を含んでいるため、両変数は同じ値に設定されています。

Note
systemd の ukify を使用して Unified カーネルイメージを生成する場合は、カーネルイメージは unified カーネルイメージに含められる前に自動的に署名されるので、手動で署名する必要はありません。

Architecture specific kernel configurations

Note
Placeholder for architecture-specific kernel build information

Compiling and installing

Note
Placeholder for instructions for building and installing the kernel sources

別の方法: Genkernel

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

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

FILE /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 は多種多様に異なるコンピュータアーキテクチャのために、幅広いハードウェアをサポートするカーネルを生成するため、コンパイルが完了するまでにかなりの時間がかかることがあるということに注意しましょう。

Warning
もしルートパーティションまたはボリュームが ext4 または XFS 以外のファイルシステムを使用している場合、おそらく genkernel --menuconfig all を使ってマニュアルでカーネルを設定し、その特定のファイルシステムのためのサポートを (モジュールとしてファイルシステムをビルドするのではなく) カーネルに組み込む必要があるでしょう。

Note
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 システムでは:

FILE /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 システムでは:

FILE /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 フラグを有効化してください。

FILE /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 上のスクリプトは、システムがブートを継続する前に、パーティションが正しくマウントされていることを確実にします。

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

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

FILE /etc/portage/package.use/installkernel

sys-kernel/installkernel dracut

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

root #emerge --ask sys-kernel/dracut

root #dracut --kver=

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

root #ls /boot/initramfs*

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

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

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

systemd システムでは:

FILE /etc/portage/package.use/systemd

sys-apps/systemd boot

OpenRC システムでは:

FILE /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 を使用する場合は:

FILE /etc/portage/package.use/installkernel

sys-kernel/installkernel dracut uki

FILE /etc/dracut.conf

uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

ukify を使用する場合は:

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

FILE /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 カーネルイメージを生成しないように設定することで、インストールすることができます:

FILE /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 を使用する場合は:

FILE /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 を使用する場合は:

FILE /etc/kernel/uki.conf

[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

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

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

FILE /etc/portage/package.use/module-rebuild

*/* dist-kernel

外部のカーネルモジュールは手動で再ビルドすることもできます:

root #emerge --ask @module-rebuild

カーネルモジュール

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

Note
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、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 ファイル拡張子はロード機構にとって重要ではなく、設定ファイルから除かれるということに注意してください:

FILE /etc/modules-load.d/network.conf強制的に3c59x モジュールをロードする

3c59x

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

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

ファイルシステムの情報

ファイルシステムラベルと UUID

MBR（BIOS）とGPTの両方が、ファイルシステムラベルとファイルシステムUUIDをサポートしています。これらの属性は、ブロックデバイスを探しマウントするために使用されるmountコマンドの代用として、/etc/fstab内で定義することができます。ファイルシステムラベルやファイルシステムUUIDはそれぞれLABELとUUID接頭辞で識別され、blkidコマンドで確認することができます：

root #blkid

Warning
もし、パーティション内のファイルシステムが消滅すると、ファイルシステムのラベルとUUIDの値は後に変更されるか除去されます。

一意性のため、MBRスタイルのパーティションテーブルを使用している読者は、/etc/fstab内で、マウント可能なボリュームを定義するのにラベルよりもUUIDを用いることを推奨します。

Important
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 ファイルを作成する

Note
init システムに systemd を使用しており、パーティション UUID が Preparing the disks で説明されている Discoverable Partition Specification に適合していて、かつ UEFI を使用しているシステムでは、systemd が仕様に従ってパーティションを自動的にマウントするので、fstab の作成を省略できます。

/etc/fstabファイルは表のように記述します。それぞれの行はホワイトスペース（一つまたは複数のスペース、タブ、もしくはその 2 種の組み合わせ）で区切られる 6 つのフィールドを持ちます。それぞれのフィールドの意味は以下の通りです。

1. 最初のフィールドはマウントされるブロックスペシャルデバイスやリモートファイルシステムを示します。デバイスファイルへのパスや、ファイルシステムラベルやファイルシステムUUID，そしてパーティションラベルやパーティションUUIDを含む、いくつかの種類のデバイスIDがブロックスペシャルデバイスノードとして使用可能です。
2. 2番目のフィールドはそのパーティションがマウントされるマウントポイントを示します。
3. 3番目のフィールドはそのパーティションのファイルシステムの種類を示します。
4. 4番目のフィールドは、そのパーティションをマウントするmountコマンドが使用するオプションを示します。すべてのファイルシステムは、固有のマウントオプションを持っています。システム管理者はマウントコマンドのmanページ(man mount)を参照することですべてのオプションを確認できます。複数のマウントオプションを記述する場合はカンマで区切ります。
5. 5番目のフィールドはそのパーティションをdumpでダンプするかどうかを示しています。このフィールドは通常0（ゼロ）のままにしておいてかまいません。
6. 6番目のフィールドは、直前のシャットダウンが正常に完了しなかったときに、fsckが各パーティションをどの順番でチェックするか示しています。ルートファイルシステムは1であるべきです。残りのファイルシステムは2（ファイルシステムチェックが不要であれば0）に設定しましょう。

Important
Gentoo stage ファイルに含まれるデフォルトの /etc/fstab ファイルは有効な fstab ではなく、関連する値を入力するために使用できるテンプレートです。

root #nano /etc/fstab

DOS/レガシー BIOS システム

実際のパーティション構成にあわせたルールや、CD-ROMドライブのためのルールを追加してください。他にパーティションやドライブがあれば、それも忘れずに追加しておきましょう。

以下は、より詳細な/etc/fstabの例です。

FILE /etc/fstabDOS/レガシー BIOS システム向けの完全な /etc/fstab の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
               defaults    0 2
   none         swap    sw                   0 0
   /                defaults,noatime              0 1

/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

UEFI システム

以下は UEFI ファームウェアを介してブートするシステムでの /etc/fstab ファイルの例です:

FILE /etc/fstabUEFI システム向けの完全な /etc/fstab の例

# 整形上の差異や、「ディスクの準備」ステップで作成する追加のパーティションについては、適宜修正してください
                    0 2
   none             sw                   0 0
   /                defaults,noatime              0 1

/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

3番目のフィールドでautoを使う場合、mountコマンドはそのパーティションのファイルシステムが何かを推測します。これは様々なファイルシステムを使う可能性があるリムーバルメディアで推奨されます。4番目のuserオプションで、ルート権限を持たないユーザーがCDをマウントできるようになります。

パフォーマンスを改善するために、多くのユーザーはマウントオプションとして noatime オプションを付け加えたいと考えるでしょう。アクセス時間が記録されないので、結果としてより高速なシステムになります (一般的にこの記録はほとんど必要ありません)。ソリッドステートドライブ (SSD) を持つシステムでもこれはおすすめです。代わりに lazytime もまた考慮に値するかもしれません。

Tip
パフォーマンスを低下させるため、/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)

Tip
これは OpenRC 上で Netifrc を使ってネットワークをセットアップするときに固有の方法です。他にも Dhcpcd のような、より簡潔なセットアップの方法も存在します。

ネットワークを設定する

Gentoo Linux をインストールしている間、ネットワークが使えるように設定されています。しかし、それは live 環境のためのネットワーク設定であり、インストールされた環境のためのものではありません。では、インストールされた Gentoo Linux のネットワークを設定しましょう。

Note
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です。

Note
ここではネットワークインターフェイスがeth0であると仮定していますが、これはシステムによって違います。もし、最近のインストールメディアから起動しているのであれば、インストール時と同じインターフェイス名が使われると思ってよいでしょう。より詳しい情報はネットワークインターフェースの命名セクションを参照してください。

FILE /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を設定してください。

FILE /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と記述）が間違っていた場合、次の手順で修正してください。

1. 正しいインターフェース名で/etc/conf.d/netファイルを更新します。（例えばeth0をenp3s0またはenp5s0と修正）
2. 新しいシンボリックリンクを作成。（例えば/etc/init.d/net.enp3s0）
3. 古いシンボリックリンクを消去。（rm /etc/init.d/net.eth0）
4. 新しいスクリプトをデフォルトランレベルに追加。
5. rc-update del net.eth0 defaultで古いスクリプトを消去。

hosts ファイル

次の重要なステップは、この新しいシステムのネットワーク環境内の他のホストについて、システムに教えることかもしれません。ネットワークホスト名は /etc/hosts で定義することができます。ホスト名をここに追加することで、ネームサーバでは解決できないホストについて、ホスト名から IP アドレスを解決できるようになります。

root #nano /etc/hosts

FILE /etc/hostsネットワーク情報の記述

# 以下は本システムの定義です。必ず設定されなければなりません。
127.0.0.1     tux.homenetwork tux localhost
  
# ネットワーク上にあるその他のホストの定義です。任意設定です。
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny

設定をセーブし、エディタを終了しましょう。

システム情報

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 リポジトリにはまだまだ他のシステムロガーがあることでしょう。日毎に利用可能なパッケージは増えていますから。

Tip
もし 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

任意自由選択: リモートシェルアクセス

Tip
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

Tip
Gentooのファイルシステムについてのさらなる情報は、ファイルシステムの記事を参照してください。

ネットワークツール

もし、以前のシステムの設定のステップでネットワークが構成されていて、それでネットワーク設定が完了している場合は、この 'ネットワークツール' のセクションは飛ばして問題ありません。その場合はブートローダーの設定に進みましょう。

DHCP クライアントをインストールする

Important
多くのユーザはネットワークに接続するために 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 ブートローダーの設定 →

Note
Placeholder for architecture-specific bootloader installation

システムのリブート

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 オンライン

Important
読者は、すべての公式の 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について →