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

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:PPC64/Full/Installation and the translation is 100% complete.



はじめに

ようこそ

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

オープンさ

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

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

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

選択

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

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

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

性能

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

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

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

インストール作業の順序

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

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

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

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

Gentoo のインストール方法

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

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

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

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

トラブルがあったときは

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

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

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

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





ハードウェア要件

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


CPU PowerPC64 CPU
システム IBM RS/6000s、Power Macintosh G5、IBM pSeries および IBM iSeries。
メモリー 64 MB
ディスク領域 1.5 GB (スワップ領域を除く)
スワップ領域 少なくとも 256 MB

サポートされているシステムの全リストは、penguinppc.org/about-2 にあります。


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

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

Minimal インストール CD

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

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

必要なときに使う Gentoo LiveDVD

必要な場合に使う、Gentooをインストール用の特別なDVDイメージが作成されています。この章で説明する方法は、MinimalインストールCDをターゲットにしているので、LiveDVDから起動する場合と少々の差異があるかもしれません。しかしLiveDVD (または他の公式 Gentoo Linux 環境) は、ターミナル上で単純にsudo su -またはsudo -iを実行するだけで、rootプロンプトの取得を行えます。

stage ファイルとは?

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

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

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

ダウンロード

メディアの入手

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

Gentoo ミラーに移動する

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

  1. 典型的には Gentoo source mirrors で見つかる利用地域のミラーを使用して、ミラーに接続する。
  2. releases/ディレクトリに行く。
  3. 関連するターゲットアーキテクチャのディレクトリ(例えばppc64/)を選択する。
  4. autobuilds/ディレクトリを選択する。
  5. amd64x86アーキテクチャでは、それぞれcurrent-install-amd64-minimal/ or current-install-x86-minimal/のどちらかを選択する。他のすべてのアーキテクチャでは、current-iso/ディレクトリへ進む。
メモ
armmipss390 のような一部のターゲットアーキテクチャには、Minimal インストール CD がありません。現時点では、Gentoo Release Engineering project はこれらのターゲット向けの .iso ファイルの作成をサポートしていません。

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

コード releases/amd64/autobuilds/current-install-amd64-minimal/ でダウンロード可能なファイルの一覧の例
[TXT]	install-amd64-minimal-20231112T170154Z.iso.asc	        2023-11-12 20:41        488
[TXT]	install-amd64-minimal-20231119T164701Z.iso.asc	        2023-11-19 18:41        488
[TXT]	install-amd64-minimal-20231126T163200Z.iso.asc	        2023-11-26 18:41        488
[TXT]	install-amd64-minimal-20231203T170204Z.iso.asc	        2023-12-03 18:41        488
[TXT]	install-amd64-minimal-20231210T170356Z.iso.asc	        2023-12-10 19:01        488
[TXT]	install-amd64-minimal-20231217T170203Z.iso.asc	        2023-12-17 20:01        488
[TXT]	install-amd64-minimal-20231224T164659Z.iso.asc	        2023-12-24 20:41        488
[TXT]	install-amd64-minimal-20231231T163203Z.iso.asc	        2023-12-31 19:01        488
[ ]     install-amd64-minimal-20240107T170309Z.iso              2024-01-07 20:42        466M
[ ]     install-amd64-minimal-20240107T170309Z.iso.CONTENTS.gz	2024-01-07 20:42        9.8K
[ ]     install-amd64-minimal-20240107T170309Z.iso.DIGESTS      2024-01-07 21:01        1.3K
[TXT]   install-amd64-minimal-20240107T170309Z.iso.asc	        2024-01-07 21:01        488
[ ]     install-amd64-minimal-20240107T170309Z.iso.sha256       2024-01-07 21:01        660
[TXT]	latest-install-amd64-minimal.txt                        2024-01-08 02:01        653

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

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

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

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

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

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

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

Microsoft Windows 上での検証

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

Linux 上での検証

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

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

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

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

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

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

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

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

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

user $gpg --verify install-amd64-minimal-20240107T170309Z.iso.asc
gpg: assuming signed data in 'install-amd64-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の署名のページ上にある指紋かどうかを調べます。

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

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

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

ブータブル USB を書き込む

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

Linux で書き込む

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

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

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

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

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

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

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

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

ヒント
Gentoo ブートメディアGPT パーティションスキームを完全に含むため、ベースデバイスパス (sdd1 ではなく sdd) を使用することが推奨されます。
dd で書き込む
警告
ターゲットは上書きされるので、dd を実行する前に、ターゲット (of=target) のパスを確認するようにしてください。

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

root #dd if=install-amd64-minimal-<release timestamp>.iso of=/dev/sdd bs=4096 status=progress && sync
メモ
if=入力ファイルを指定し、of=出力ファイルを指定します。この場合では出力ファイルはデバイスです。
ヒント
転送を高速化するため、多くの場合 bs=4096 が使用されます。 status=progress は転送の統計情報を表示します。

ディスクに書き込む

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

Microsoft Windows 7 以降での書き込み

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

Linux での書き込み

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

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

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

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

起動する

Default: Booting the installation CD on an Apple/IBM

Place the installation CD in the CD-ROM and reboot the system. Hold down the c key at bootup. A friendly message will show up together with a boot: prompt at the bottom of the screen.

ヒント
Hold the left mouse button during the boot process to open the CD/DVD drive tray.

On this prompt, the default Linux kernel (called gentoo) can be booted, which will boot up from the installation CD further.

Some kernel options can be tweaked at this prompt. The following table lists the available boot options that can be added:

Boot option Description
video= This option takes one of the following vendor-specific values: radeonfb, rivafb, atyfb, aty128, nvidiafb, or ofonly. Follow this tag with the resolution and refresh rate that is needed. For instance video=radeonfb:1280x1024@75. When uncertain what to choose, ofonly will almost certainly work.
nol3 Disables level 3 cache on some Powerbooks (needed for at least the 17").
debug Enables verbose booting, spawns an initrd shell that can be used to debug the installation CD.
sleep=N Wait N seconds (where N is an integer number) before continuing. This can be needed by some very old SCSI CD-ROMs which do not speed up the CD quick enough.
bootfrom=X Where X is substituted for a another device name to from a different device.
dosshd Starts sshd. Useful for unattended installs.
passwd=foo Sets the value after the = as the root password. Use with dosshd for remote installs.

At this prompt, hit enter, and a complete Gentoo Linux environment will be loaded from the CD.

IBM pSeries

On the IBM pSeries, the CD should autoboot, but sometimes it does not. In that case, set up the CD-ROM as a bootable device in the multi-boot menu. If a monitor and a keyboard is attached, then the multi-boot menu can be reached by pressing the F1 key on startup. However, if the system is reached through the serial console, then press 1. Press the key when the beginning of the following line on the serial console is visible:

コード Line at which point '1' should be pressed
memory      keyboard     network      scsi      speaker

The other option is to jump into Open Firmware and do it from there:

  1. Boot into Open Firmware: same procedure as getting into multi-boot (described a few lines above), but use F8 and 8 instead of F1 and 1.
  2. Run the command 0> boot cdrom:1,yaboot
  3. Stand back and enjoy!
メモ
If the following output is displayed, then Open Firmware isn't set up correctly. Please use the multi-boot option described above:
コード Output if Open Firmware is not set up correctly
0 > boot cdrom:1,yaboot
 ok
0 >

キーボードレイアウトを設定する

On the console, a root (#) prompt will become visible. It is also possible to switch to other consoles by pressing and holding Alt+fn then F2, F3, or F4. Get back to the initial prompt by pressing Alt+fn+F1.

When installing Gentoo on a system with a non-US keyboard, use loadkeys to load the keymap for the keyboard. To list the available keymaps, execute ls on the /usr/share/keymaps/i386/ directory:

root #ls /usr/share/keymaps/i386/

loadkeys コマンドで選択したキーマップをロードします:

root #loadkeys be-latin1

Another common option would be the QWERTY PC110 key configuration:

root #loadkeys pc110


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

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

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

root #modprobe 8139too

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

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

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

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

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

次の例では、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:PPC64/ja

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

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

GNU Screen

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

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

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

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

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

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





ネットワークの自動構成

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

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

DHCP を使う

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

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

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

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

root #dhcpcd enp1s0

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

root #dhcpcd -HD enp1s0

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

root #dhcpcd -x
sending signal Term to pid 10831
waiting for pid 10831 to exit

ネットワークのテスト

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

root #ip route
default via 192.168.0.1 dev enp1s0

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

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

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

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

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

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

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

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

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

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

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
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.77/22 brd 10.0.23.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::ea40:f2ff:feac:257a/64 scope link 
       valid_lft forever preferred_lft forever

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

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

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

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

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

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

web プロキシを設定する

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

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

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

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

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

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

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

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

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

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

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

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

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

user $links -ftp-proxy ${ftp_proxy}

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

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

ADSL のために pppoe-setup を使う

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

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

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

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

PPTP を使う

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

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

root #nano /etc/ppp/chap-secrets

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

root #nano /etc/ppp/options.pptp

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

root #pptp <server ipv4 address>

WEP を構成する

警告
WEP が唯一の選択肢でない限り、WEP を使用しないでください。WEP は基本的に、オープンネットワーク上に何のセキュリティも提供しません。
重要
iw コマンドは以下のアーキテクチャ上でのみ利用可能です: amd64x86armarm64ppcppc64、および riscv

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

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

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

root #iw dev wlp9s0 link
Not connected.

または

root #iw dev wlp9s0 link
Connected to 00:00:00:00:00:00 (on wlp9s0)
	SSID: GentooNode
	freq: 2462
	RX: 3279 bytes (25 packets)
	TX: 1049 bytes (7 packets)
	signal: -23 dBm
	tx bitrate: 1.0 MBit/s
メモ
無線カードのデバイス名は、wlp9s0 の代わりに wlan0 または ra0 のような名前かもしれません。正しいデバイス名を調べるには、ip link を実行してください。

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

  • まず、インターフェースがアクティブになっていることを確認してください:
root #ip link set dev wlp9s0 up
  • GentooNodeという名前のオープンネットワークに接続するには:
root #iw dev wlp9s0 connect -w GentooNode
  • 16進WEPキーを使って接続するには、キーの前にd:を付けてください:
root #iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd
  • ASCII WEPキーで接続するには:
root #iw dev wlp9s0 connect -w GentooNode key 0:some-password
メモ
無線ネットワークが WPA または WPA2 で設定されている場合には、wpa_supplicant を使う必要があります。Gentoo Linux でのネットワーク設定のさらなる情報については、Gentoo ハンドブックの無線ネットワークの章を読んでください。

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

net-setup を使用する

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

root #net-setup enp1s0

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

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

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

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

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

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

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

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

重要
IP アドレスは任意に設定することができます。その結果、複数のデバイスが同一の IP アドレスを使用する設定にすることができてしまいますが、これはアドレスの競合につながります。アドレスの競合は DHCP または SLAAC を使用して回避すべきです。
ヒント
IPv6 は、アドレス構成のために典型的には StateLess Address AutoConfiguration (SLAAC) を使用します。ほとんどの場合、手動で IPv6 アドレスを設定することはバッドプラクティスです。特定のアドレスサフィックスが好ましい場合は、インターフェース識別トークンを使用することができます。

ネットワークと CIDR

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

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

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

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

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

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

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

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

インターネット

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

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

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

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

まとめると:

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

ドメインネームシステム

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

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

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

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

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

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

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

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

root #ip address add 192.168.0.2/24 dev enp1s0
ヒント
このコマンドの先頭の部分は ip a と省略できます。

デフォルトルート構成

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

root #ip route
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2
ヒント
このコマンドは ip r と省略できます。

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

root #ip route add default via 192.168.0.1

DNS 構成

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

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

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

root #nano /etc/resolv.conf

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

ファイル /etc/resolv.confQuad9 DNS を使用する。
nameserver 9.9.9.9
nameserver 149.112.112.112
ファイル /etc/resolv.confCloudflare DNS を使用する。
nameserver 1.1.1.1
nameserver 1.0.0.1

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

root #ping -c 3 gentoo.org

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





ブロックデバイスの概要

ブロックデバイス

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 バスSCSIUSB バスを介してブロックストレージとして接続されます。例えば、最初の 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) ごとの連続領域としてアドレッシングできます。


Partitions and slices

Although it is theoretically possible to use a full disk to house a Linux system, this is almost never done in practice. Instead, full disk block devices are split up in smaller, more manageable block devices. On most systems, these are called partitions. Other architectures use a similar technique, called slices.


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

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

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

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

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

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


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

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

スワップ領域について

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

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

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


Default: Using mac-fdisk

重要
These instructions are for the Apple G5 system.
Partition Description
/dev/sda1 Apple partition map, automatically created when the disk is formatted with a "mac" partition table.
/dev/sda2 New World boot block
/dev/sda3 Swap partition
/dev/sda4 Root partition

Start mac-fdisk:

root #mac-fdisk /dev/sda

First delete the partitions that have been cleared previously to make room for Linux partitions. Use the d key in mac-fdisk to delete those partition(s). It will ask for the partition number to delete.

Second, create an Apple_Bootstrap partition by pressing the b key. It will ask for a block from which to start. Enter the number of the first free partition, followed by entering a p. For instance this is 2p.

メモ
This partition is not a "boot" partition. It is not used by Linux at all; there is no need to place any filesystem on it and it should never be mounted. PPC users do not need an extra partition for /boot.

Now create a swap partition by pressing the c key. Again mac-fdisk will ask what block to start from. As we used 2 before to create the Apple_Bootstrap partition, enter 3p. When asked for the size, enter 512M (or whatever size needed). When asked for a name, enter swap (mandatory).

To create the root partition, enter c, followed by 4p to select from what block the root partition should start. When asked for the size, enter 4p again. mac-fdisk will interpret this as "Use all available space". When asked for the name, enter root (mandatory).

To finish up, write the partition to the disk using w and q to quit mac-fdisk.

メモ
To make sure everything is okay, run mac-fdisk once more to verify all the partitions are present. If a partition is absent, or it is missing some of the changes that were made, then reinitialize the partitions by pressing i in mac-fdisk. Note that this will recreate the partition map and thus remove all the partitions.

代替案: fdisk を用いる

重要
The following instructions are for IBM pSeries, iSeries, and OpenPower systems.
メモ
When planning to use a RAID disk array for the Gentoo installation on POWER5-based hardware, first run iprconfig to format the disks to Advanced Function format and create the disk array. Emerge sys-fs/iprutils after the installation is complete.

If the system has an ipr-based SCSI adapter, start the ipr utilities now.

root #/etc/init.d/iprinit start

The following parts explain how to create the example partition layout described previously, namely:

Partition Description
/dev/sda1 PPC PReP Boot partition
/dev/sda2 Swap partition
/dev/sda3 Root partition

Change or modify the partition layout according to personal preference.

Viewing current partition layout

fdisk is a popular and powerful tool to split a disk into partitions. Fire up fdisk on the current disk (in our example, we use /dev/sda):

root #fdisk /dev/sda
Command (m for help)

If there is still an AIX partition layout on the system, then the following error message will be displayed:

root #fdisk /dev/sda
  There is a valid AIX label on this disk.
  Unfortunately Linux cannot handle these
  disks at the moment.  Nevertheless some
  advice:
  1. fdisk will destroy its contents on write.
  2. Be sure that this disk is NOT a still vital
     part of a volume group. (Otherwise you may
     erase the other disks as well, if unmirrored.)
  3. Before deleting this physical volume be sure
     to remove the disk logically from your AIX
     machine.  (Otherwise you become an AIXpert).

Don't worry, new empty DOS partition table can be created by pressing o.

警告
This will destroy any installed AIX version!

Type p to display the disk current partition configuration:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          12       53266+  83  Linux
/dev/sda2              13         233      981571+  82  Linux swap
/dev/sda3             234         674     1958701+  83  Linux
/dev/sda4             675        6761    27035410+   5  Extended
/dev/sda5             675        2874     9771268+  83  Linux
/dev/sda6            2875        2919      199836   83  Linux
/dev/sda7            2920        3008      395262   83  Linux
/dev/sda8            3009        6761    16668918   83  Linux

This particular disk is configured to house six Linux filesystems (each with a corresponding partition listed as "Linux") as well as a swap partition (listed as "Linux swap").

Removing all partitions

First remove all existing partitions from the disk. Type d to delete a partition. For instance, to delete an existing /dev/sda1:

Command (m for help):d
Partition number (1-4): 1

The partition has been scheduled for deletion. It will no longer show up when typing p, but it will not be erased until the changes have been saved. If a mistake was made and the session needs to be aborted, then type q immediately and hit Enter and none of the partitions will be deleted or modified.

Now, assuming that indeed all partitions need to be wiped out, repeatedly type p to print out a partition listing and then type d and the number of the partition to delete it. Eventually, the partition table will show no more partitions:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
Device Boot    Start       End    Blocks   Id  System

Now that the in-memory partition table is empty, let's create the partitions. We will use a default partitioning scheme as discussed previously. Of course, don't follow these instructions to the letter but adjust to personal preference.

Creating the PPC PReP boot partition

First create a small PReP boot partition. Type n to create a new partition, then p to select a primary partition, followed by 1 to select the first primary partition. When prompted for the first cylinder, hit Enter. When prompted for the last cylinder, type +7M to create a partition 7 MB in size. After this, type t to set the partition type, 1 to select the partition just created and then type in 41 to set the partition type to "PPC PReP Boot". Finally, mark the PReP partition as bootable.

メモ
The PReP partition has to be smaller than 8 MB!
Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
Command (m for help):n
Command action
      e   extended
      p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-6761, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-6761, default
6761): +8M
Command (m for help):t
Selected partition 1
Hex code (type L to list codes): 41
Changed system type of partition 1 to 41 (PPC PReP Boot)
Command (m for help):a
Partition number (1-4): 1
Command (m for help):

Now, when looking at the partition table again (through p), the following partition information should be shown:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1  *            1           3       13293   41  PPC PReP Boot

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

Now create the swap partition. To do this, type n to create a new partition, then p to tell fdisk to create a primary partition. Then type 2 to create the second primary partition, /dev/sda2 in our case. When prompted for the first cylinder, hit Enter. When prompted for the last cylinder, type +512M to create a partition 512MB in size. After this, type t to set the partition type, 2 to select the partition just created and then type in 82 to set the partition type to "Linux Swap". After completing these steps, typing p should display a partition table that looks similar to this:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           3       13293   41  PPC PReP Boot
/dev/sda2               4         117      506331   82  Linux swap

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

Finally, create the root partition. To do this, type n to create a new partition, then p to tell fdisk to create a primary partition. Then type 3 to create the third primary partition, /dev/sda3 in our case. When prompted for the first cylinder, hit Enter. When prompted for the last cylinder, hit enter to create a partition that takes up the rest of the remaining space on the disk. After completing these steps, typing p should display a partition table that looks similar to this:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           3       13293   41  PPC PReP Boot
/dev/sda2               4         117      506331   82  Linux swap
/dev/sda3             118        6761    29509326   83  Linux

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

To save the partition layout and exit fdisk, type w.

Command (m for help):w


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

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

はじめに

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

ファイルシステム

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

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

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

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

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

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

ファイルシステム 作成コマンド live 環境内にある? パッケージ
btrfs mkfs.btrfs はい sys-fs/btrfs-progs
ext4 mkfs.ext4 はい sys-fs/e2fsprogs
f2fs mkfs.f2fs はい sys-fs/f2fs-tools
xfs mkfs.xfs はい sys-fs/xfsprogs
vfat mkfs.vfat はい sys-fs/dosfstools
NTFS mkfs.ntfs はい sys-fs/ntfs3g
重要
ハンドブックではインストールプロセスの一部として新しいパーティションを使用することを推奨しますが、重要なこととして、mkfs コマンドを実行すると、パーティションに含まれるすべてのデータは消去されることに注意してください。必要な場合は、新しいファイルシステムを作成する前に、中に存在する任意のデータが適切にバックアップされていることを確認してください。

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

root #mkfs.xfs /dev/sda3

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

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

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

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

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

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

root #mkfs.xfs /dev/sda1

小さな ext4 パーティション

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

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

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

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

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

root #mkswap /dev/sda2

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

root #swapon /dev/sda2

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

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

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

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

root #mkdir --parents

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

root #mkdir --parents

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

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

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

root #mount /dev/sda3

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

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

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





stage ファイルを選択する

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

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

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

重要
インストールが確立された後にメジャープロファイルを変更することは、技術的には可能ですが、変更にはかなりの労力と熟慮が必要で、このインストールマニュアルの範囲外です。init システムの切り換えは難しいですが、no-multilib から multilib への切り換えは Gentoo と低レベルツールチェーンについての深い知識を必要とします。
ヒント
大部分のユーザは、'advanced' な tarball を選択する必要は無いはずです。これらは、典型的でないあるいは高度な、ソフトウェアもしくはハードウェアのためのものです。

OpenRC

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

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

systemd

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

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

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

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

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

非 multilib (64 ビットのみ)

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

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

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

日時を設定する

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

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

root #date
Mon Oct  3 13:16:22 PDT 2021

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

自動

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

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

root #chronyd -q
重要
動作するリアルタイムクロック (RTC) を持たないシステムは、システム開始のたびに、そしてその後は定期的に、システム時計を同期しなくてはなりません。RTC を持つシステムでも、バッテリが故障して時計のずれが蓄積することがあるため、これは有用です。
警告
標準的な NTP のトラフィックは認証されていません。ネットワークから取得した時刻データを検証することは重要です。

手動

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

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

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

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

root #date 100313162021

stage ファイルをダウンロードする前に、カレントディレクトリを、インストール対象として使用されるマウントポイントの場所 (おそらく /mnt/gentoo でしょう) に設定しておくべきです。

root #cd /mnt/gentoo

グラフィカルブラウザ

完全なグラフィカルウェブブラウザがある環境を使っているひとには、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_proxyftp_proxy変数をexportしてください。

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

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

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

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

検証して確認する

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

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

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

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

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

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

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

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

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

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

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

root #sha256sum --check stage3-ppc64-<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 環境内で gpgwget を提供していれば、Gentoo 鍵を含むバンドルを取得してインポートすることができます:

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

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

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

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

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

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

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

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

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

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

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

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

はじめに

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

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

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

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

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

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

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

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

CFLAGS と CXXFLAGS

CFLAGSCXXFLAGS変数はそれぞれ、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を使うと、必要の無い場合にはフレームポインタをレジスタに保持しなくなります。これはアプリケーションのデバッグ時に深刻な影響を与えるかもしれません。

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

コード CFLAGSCXXFLAGS変数の設定例
# すべての言語において設定するコンパイラフラグ
COMMON_FLAGS="-O2 -pipe"
# 同じ設定を両方の変数に使用
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
ヒント
各種コンパイルオプションがどのようにシステムに影響するかについては GCC の最適化 の記事に詳しい情報がありますが、初心者がシステムの最適化を始めるには Safe CFLAGS の記事のほうがもっと実践的な場所かもしれません。

MAKEOPTS

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

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

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

警告
ジョブ数を大きくすると、メモリ使用量にきわめて大きな影響を及ぼします。目安は、指定したジョブ数の各ジョブに対し、最低 2 GiB の RAM が割り当てられるようにすることです (つまり、例えば -j6最低でも 12 GiB を要求します)。メモリが枯渇しないようにするには、利用可能なメモリ容量に合うようにジョブ数を減らしてください。
ヒント
並列 emerge を使用する (--jobs) と、実効的なジョブ数が指数関数的に (make ジョブ数 × emerge ジョブ数まで) 増大することがあります。これに対しては、localhost-only distcc 構成によって、ホスト当たりのコンパイラインスタンス数を制限することで対処することができます。
ファイル /etc/portage/make.confMAKEOPTS 設定例
# 未定義のままの場合、Portage のデフォルトの挙動は以下の通りです:
# - MAKEOPTS の jobs 値を `nproc` が返すスレッド数と同じ数に設定する
# - MAKEOPTS の load-average 値を `nproc` が返すスレッド数と同じ数に設定する
# '4' をシステムに応じて適切に (min(RAM/2GB, スレッド数) 置き換えるか、未設定のままにしておいてください。
MAKEOPTS="-j4 -l4"

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

よーい、ドン!

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

参照





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

ヒント
Gentoo のインストールメディアを使用している場合は、このステップは単に arch-chroot /mnt/gentoo として置き換えることができます。
root #mount --types proc /proc /mnt/gentoo/proc
root #mount --rbind /sys /mnt/gentoo/sys
root #mount --make-rslave /mnt/gentoo/sys
root #mount --rbind /dev /mnt/gentoo/dev
root #mount --make-rslave /mnt/gentoo/dev
root #mount --bind /run /mnt/gentoo/run
root #mount --make-slave /mnt/gentoo/run
メモ
インストールの後半で出てくるsystemdを使う場合、--make-rslaveが必要です。
警告
Gentoo以外のインストールメディアを使う場合、これだけでは十分ではない場合があります。いくつかのディストリビューションは/run/shm/へのシンボリックリンクとして/dev/shmを作りますが、これはchroot後に無効になってしまいます。これに対応するためには、/dev/shm/をtmpfsとして適切にマウントしておくことが必要です:
root #test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
root #mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm

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

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

新しい環境に入る

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

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

  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 環境で実行されます。

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

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

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

UEFI システム

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

root #mkdir # 以前の手順で作成済みかもしれません
root #mount

DOS/レガシー BIOS システム

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

root #mount /dev/sda1

Portage を設定する

Gentoo ebuild リポジトリ

ミラーを選択するために次に重要なステップは、/etc/portage/repos.conf/gentoo.confファイルでGentoo ebuildリポジトリを設定することです。このファイルはパッケージリポジトリを更新するときに必要になる同期情報を含んでいます(パッケージリポジトリは、Portageがソフトウェアパッケージをダウンロード、インストールする時に必要なすべての情報を含むebuildと関連ファイルを集めたものです)。

リポジトリの設定は単純な数ステップでできます。最初に (それが存在しなければ) repos.conf ディレクトリを作成してください:

root #mkdir --parents /etc/portage/repos.conf

次に、Portageが提供するGentooリポジトリ設定ファイルを(新規作成した)repos.confディレクトリにコピーします。

root #cp /usr/share/portage/config/repos.conf /etc/portage/repos.conf/gentoo.conf

エディタで覗き見するか、catコマンドを使いましょう。そのファイルは.iniフォーマットで、以下のような記述になっているはずです。

ファイル /mnt/gentoo/etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo
 
[gentoo]
location = /var/db/repos/gentoo
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes
sync-rsync-verify-jobs = 1
sync-rsync-verify-metamanifest = yes
sync-rsync-verify-max-age = 24
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4
sync-webrsync-verify-signature = yes
sync-git-verify-commit-signature = yes

上に記載されているデフォルトの sync-uri 変数は、ローテーション可能なミラーの場所を決めています。これは Gentoo インフラストラクチャーの帯域にかかるストレスを軽減することに役立ち、また特定のミラーがオフラインになっている場合のバックアップとなります。よって、デフォルトのURIは、ローカルまたはプライベートの Portage ミラーを代わりに使うのでない限り、そのままにしておくことが推奨されます。

ヒント
Portage の plug-in sync API の仕様は Portage プロジェクトの Sync のページにあります。

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

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

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

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

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

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


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

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

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

root #emerge --ask --verbose --oneshot app-portage/mirrorselect
root #mirrorselect -i -o >> /etc/portage/make.conf

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

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

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

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

root #emerge --sync

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

root #emerge --sync --quiet

ニュースを読む

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

* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.

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

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

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

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

root #man news.eselect

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

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

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

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

root #eselect profile list
Available profile symlink targets:
  [1]   default/linux/ppc64/ *
  [2]   default/linux/ppc64//desktop
  [3]   default/linux/ppc64//desktop/gnome
  [4]   default/linux/ppc64//desktop/kde
メモ
コマンドの出力は一例で、常に更新されています。
メモ
systemd を使用するには、名前に "systemd" を含んだプロファイルを選択してください。逆もまた然りです。

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

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

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

root #eselect profile set 2



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

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

Since December 2023, Gentoo's Release Engineering team has offered an official binary package host (colloquially shorted to just "binhost") for use by the general community to retrieve and install binary packages (binpkgs).[1]

Adding a binary package host allows Portage to install cryptographically signed, compiled packages. In many cases, adding a binary package host will greatly decrease the mean time to package installation and adds much benefit when running Gentoo on older, slower, or low power systems.

リポジトリの構成

The repository configuration for a binhost is found in Portage's /etc/portage/binrepos.conf/ directory, which functions similarly to the configuration mentioned in the Gentoo ebuild repository section.

When defining a binary host, there are two important aspects to consider:

  1. The architecture and profile targets within the sync-uri value do matter and should align to the respective computer architecture (ppc64 in this case) and system profile selected in the Choosing the right profile section.
  2. Selecting a fast, geographically close mirror will generally shorten retrieval time. Review the mirrorselect tool mentioned in the Optional: Selecting mirrors section or review the online list of mirrors where URL values can be discovered.

ファイル /etc/portage/binrepos.conf/gentoo.confCDN-based binary package host example
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

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

Portage will compile packages from code source by default. It can be instructed to use binary packages in the following ways:

  1. The --getbinpkg option can be passed when invoking the emerge command. This method of for binary package installation is useful to install only a particular binary package.
  2. Changing the system's default via Portage's FEATURES variable, which is exposed through the /etc/portage/make.conf file. Applying this configuration change will cause Portage to query the binary package host for the package(s) to be requested and fall back to compiling locally when no results are found.

For example, to have Portage always install available binary packages:

ファイル /etc/portage/make.confConfigure Portage to use binary packages by default
# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

Additional Portage features will be discussed in the the next chapter of the handbook.

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

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

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

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

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

root #emerge --info | grep ^USE
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
メモ
上記の例は出力のほとんどを省略しています。実際には、USE 変数のリストはずっとずっと長いものです。

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

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

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

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

root #nano /etc/portage/make.conf
ファイル /etc/portage/make.confDVD、ALSA、CD書き込みをサポートしたKDE/Plasmaベースのフラグ設定
USE="-gtk -gnome qt5 kde dvd alsa cdr"

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

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

CPU_FLAGS_*

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

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

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

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

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

root #emerge --ask app-portage/cpuid2cpuflags

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

root #cpuid2cpuflags

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

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

VIDEO_CARDS

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

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

ファイル /etc/portage/make.conf
VIDEO_CARDS="amdgpu radeonsi"

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

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

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

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

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

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

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

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

user $portageq envvar ACCEPT_LICENSE
@FREE

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

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

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

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

ファイル /etc/portage/make.confシステム全体で ACCEPT_LICENSE でライセンスを受諾する
# プロファイルの ACCEPT_LICENSE のデフォルト値を無視する
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"

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

root #mkdir /etc/portage/package.license

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

ファイル /etc/portage/package.license/kernelパッケージ単位でライセンスを受諾する
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
重要
ebuild の LICENSE 変数は Gentoo の開発者やユーザにとってのガイドラインでしかありません。これは法的声明ではなく、これが現実を反映する保証はありません。ソフトウェアパッケージのライセンスに関する、ebuild 開発者の解釈だけを信用しないようにすることをおすすめします; パッケージそのものを、システムにインストールされるすべてのファイルを含めて徹底的にチェックしてください。

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

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

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

Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.

Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:

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

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

It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.

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

If happy, then proceed with a real depclean:

root #emerge --ask --depclean
ヒント
非 desktop の stage ファイルから、デスクトップ環境プロファイルターゲットを選択した場合、@world 更新プロセスはインストール時間を格段に長くしてしまうかもしれません。時間に追われている人は次の経験則が成り立つでしょう。「名前が短く、特定のシステムを示さないプロファイルの @world 集合を選択する」。「もっとも一般的な @world 集合は、より少ないパッケージのアップデートですむ」。例えば:
  • default/linux/amd64/ を選択すると、おそらくパッケージのアップデートは少なくて済むでしょう。
  • default/linux/amd64//desktop/gnome/systemd を選択すると、おそらくより多くのパッケージがインストールされるでしょう。なぜなら、プロファイルターゲットが、 GNOME デスクトップ環境をサポートするための依存パッケージを含む、より大きな @system および @profile 集合を持つからです。


タイムゾーン

メモ
このステップは musl libc を使う場合は適用されません。それがどういう意味か分からない場合は、このステップを実行すべきです。
警告
/usr/share/zoneinfo/Etc/GMT* のタイムゾーンは、その名前が期待されるゾーンを示していないため、避けましょう。たとえば、GMT-8 は実際には GMT+8 となります。

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

root #ls -l /usr/share/zoneinfo
total 352
drwxr-xr-x 2 root root   1120 Jan  7 17:41 Africa
drwxr-xr-x 6 root root   2960 Jan  7 17:41 America
drwxr-xr-x 2 root root    280 Jan  7 17:41 Antarctica
drwxr-xr-x 2 root root     60 Jan  7 17:41 Arctic
drwxr-xr-x 2 root root   2020 Jan  7 17:41 Asia
drwxr-xr-x 2 root root    280 Jan  7 17:41 Atlantic
drwxr-xr-x 2 root root    500 Jan  7 17:41 Australia
drwxr-xr-x 2 root root    120 Jan  7 17:41 Brazil
-rw-r--r-- 1 root root   2094 Dec  3 17:19 CET
-rw-r--r-- 1 root root   2310 Dec  3 17:19 CST6CDT
drwxr-xr-x 2 root root    200 Jan  7 17:41 Canada
drwxr-xr-x 2 root root     80 Jan  7 17:41 Chile
-rw-r--r-- 1 root root   2416 Dec  3 17:19 Cuba
-rw-r--r-- 1 root root   1908 Dec  3 17:19 EET
-rw-r--r-- 1 root root    114 Dec  3 17:19 EST
-rw-r--r-- 1 root root   2310 Dec  3 17:19 EST5EDT
-rw-r--r-- 1 root root   2399 Dec  3 17:19 Egypt
-rw-r--r-- 1 root root   3492 Dec  3 17:19 Eire
drwxr-xr-x 2 root root    740 Jan  7 17:41 Etc
drwxr-xr-x 2 root root   1320 Jan  7 17:41 Europe
...
root #ls -l /usr/share/zoneinfo/Europe/
total 256
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Amsterdam
-rw-r--r-- 1 root root 1742 Dec  3 17:19 Andorra
-rw-r--r-- 1 root root 1151 Dec  3 17:19 Astrakhan
-rw-r--r-- 1 root root 2262 Dec  3 17:19 Athens
-rw-r--r-- 1 root root 3664 Dec  3 17:19 Belfast
-rw-r--r-- 1 root root 1920 Dec  3 17:19 Belgrade
-rw-r--r-- 1 root root 2298 Dec  3 17:19 Berlin
-rw-r--r-- 1 root root 2301 Dec  3 17:19 Bratislava
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Brussels
...

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

OpenRC

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

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

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

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

systemd

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

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

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

ロケールの設定

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

ロケールの生成

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

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

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

root #nano /etc/locale.gen

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

ファイル /etc/locale.genUSとDEロケールを適切な文字コードと共に有効にする
en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8
警告
多くのアプリケーションは適切にビルドするのに少なくとも UTF-8 を必要とします。

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

root #locale-gen

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

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

ロケールの選択

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

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 9

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

ファイル /etc/env.d/02localeシステムのロケールをマニュアル設定する
LANG="de_DE.UTF-8"
LC_COLLATE="C.UTF-8"

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

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

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

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

参照





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

ファームウェア

Linux ファームウェア

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

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

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

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

SOF ファームウェア

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

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

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

マイクロコード

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

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

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

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

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

完全自動アプローチ: ディストリビューションカーネル
ディストリビューションカーネルは、Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されている) initramfs ファイルを、設定、自動でビルド、インストールするために利用されます。将来のカーネル更新はパッケージマネージャを介して扱われるため、他のシステムパッケージとまったく同様に完全に自動で行われます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。これが最も簡単なプロセスで、すぐ動作するものが手に入りシステム管理者による関与を最小にできるため、新規の Gentoo ユーザには完璧です。
ハイブリッドアプローチ: Genkernel
新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。システム管理者は Linux カーネル、関連するモジュール、および (必須ではありませんがデフォルトでは有効化されていない) initramfs ファイルを、設定、ビルド、インストールするために Gentoo の genkernel ツールを使用することができます。カスタマイズが必要な場合はカスタムのカーネルコンフィグファイルを提供することも可能です。将来のカーネル設定、コンパイル、インストールには、アップデートのたびに eselect kernelgenkernel、およびもし必要であれば他のコマンドを実行する形で、システム管理者による関与が必要です。
完全手動アプローチ
新しいカーネルのソースがシステムパッケージマネージャを通じてインストールされます。カーネルは eselect kernel と無数の make コマンドを利用して、手動で設定、ビルド、インストールされます。将来のカーネル更新はカーネルファイルの設定、ビルド、インストールの手動プロセスを繰り返して行います。これが最も込み入ったプロセスですが、カーネル更新プロセスに関して最大限の制御を行えます。

すべてのディストリビューションが構築されるその中心にあるのが Linux カーネルです。カーネルレイヤーはユーザのプログラムとハードウェアの間に存在します。ハンドブックではカーネルソースについていくつかの可能な選択肢を提供しますが、より詳しい説明付きで、より完全なカーネルソースのリストは、カーネルの概要のページで見ることができます。

ディストリビューションカーネル

ディストリビューションカーネルは、カーネルを展開、構成設定、コンパイル、インストールする完全なプロセスをカバーする ebuild です。この手法を利用する最大の利点は、@world アップグレードの一部として、パッケージマネージャによってカーネルが新しいバージョンに更新されることです。これは emerge コマンドを実行する以外にユーザの関与を必要としません。ディストリビューションカーネルはデフォルトでは、大部分のハードウェアをサポートするように構成されますが、カスタマイズするための 2 つの機構が提供されています: savedconfig とコンフィグスニペットです。設定についてのさらなる詳細はプロジェクトページを参照してください。

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

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

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

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

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

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

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

root #emerge --ask sys-kernel/gentoo-kernel-bin
省略可能: 署名付きカーネルモジュール

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルモジュールは既に署名されています。ソースからビルドしたカーネルのモジュールに署名するためには、/etc/portage/make.confmodules-sign USE フラグを有効化し、署名のためにどの鍵を使用するかを任意で指定してください:

ファイル /etc/portage/make.confモジュールの署名を有効化する
USE="modules-sign"

# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です。

MODULES_SIGN_KEY が指定されない場合は、カーネルビルドシステムが鍵を生成し、鍵は /usr/src/linux-x.y.z/certs に保存されるでしょう。各カーネルリリースに対して同じ鍵が使用されることを確実にするためには、手動で鍵を生成することを推奨します。鍵は以下で生成することができます:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
メモ
The MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.

OpenSSL が鍵の生成についてのいくつか質問をしてくるでしょうが、できる限り詳細にこれらの質問に答えることを推奨します。

安全な場所に鍵を保存してください。最低限の措置として、鍵は root ユーザによる読み取りのみ可能にすべきです。このことを以下のようにして確認してください:

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

これが上と違ったものを出力する場合は、以下で権限を修正してください:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
省略可能: カーネルイメージに署名する (セキュアブート)

ビルド済みディストリビューションカーネル (sys-kernel/gentoo-kernel-bin) 内のカーネルイメージは既にセキュアブート用に署名されています。ソースからビルドされたカーネルイメージに署名するには、/etc/portage/make.confsecureboot USE フラグを有効化し、署名のためにどの鍵を使用するかを任意で指定してください。セキュアブートとともに使用するためにカーネルイメージに署名するには、カーネルモジュールも署名する必要があることに注意してください。カーネルイメージとカーネルモジュールの両方に署名するために、同一の鍵を使用しても構いません:

ファイル /etc/portage/make.confカスタム署名鍵を有効化する
USE="modules-sign secureboot"

# 任意で、カスタム署名鍵を使用するために。
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # MODULES_SIGN_KEY が証明書を含まない場合のみ必須です。
MODULES_SIGN_HASH="sha512" # デフォルトは sha512 です。

# 任意で、セキュアブートを有効化してブートするために。署名鍵は同一でも別でも構いません。
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
メモ
The SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
メモ
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second separate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.

新しい鍵を生成する手順については上の節を参照してください。カーネルイメージを署名するために別の鍵を使用する場合は、同じ手順を繰り返すことができます。

セキュアブートを有効化して正しくブートさせるためには、使用するブートローダにも署名し、証明書が UEFI ファームウェアまたは Shim によって許可されなくてはなりません。これはハンドブック内で後で説明します。

アップグレードと後処理

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

root #emerge --depclean

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

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

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

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

sys-fs/zfssys-fs/zfs-kmod などのパッケージでこの USE フラグを有効化すると、パッケージが新しく更新されたカーネルに対して自動的に再ビルドされ、適用可能であれば、それに従って initramfs を再生成します。

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

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

root #emerge --ask @module-rebuild

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

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

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

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

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

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

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

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

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

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

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

root #eselect kernel list
Available kernel symlink targets:
  [1]   linux-3.16.5-gentoo

linux シンボリックリンクを作成するには、次を使用してください:

root #eselect kernel set 1
root #ls -l /usr/src/linux
lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-3.16.5-gentoo

別の方法: Genkernel

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

すべてをマニュアルで設定することが困難だと思われる場合は、システム管理者はカーネル管理のためのハイブリッドアプローチとして、genkernel を使うことを考えてみるべきです。

Genkernel はジェネリックカーネルコンフィギュレーションファイルを提供し、カーネルと initramfs をコンパイルし、生成されたバイナリを適切な場所にインストールします。これによりシステムの初回起動のための最小限かつジェネリックなハードウェアサポートが得られ、さらなる更新の制御と、将来のカーネル設定のカスタマイズが可能になります。

注意: システム管理者はカーネルの保守のために genkernel を使うことで、システムのカーネル、initramfs、その他のオプションに関する更新をより制御できるようになります。その一方で、将来的に新しいソースがリリースされてカーネル更新を実施するときには、時間と労力をかけた献身が確実に必要となるでしょう。システム任せのカーネル保守アプローチを求めているのなら、ディストリビューションカーネルを使用するべきです。

もう一点明確にしておくと、genkernel が自動的に実行中のハードウェアのためにカスタマイズされたカーネルコンフィギュレーションを生成すると信じているなら、それは誤解です。genkernel は、大部分の汎用的なハードウェアをサポートするように事前に決定されたカーネルコンフィギュレーションを使用して、カーネル、関連するモジュール、そして initramfs ファイルをアセンブルしてインストールするために必要な make コマンドを、自動で操作します。

バイナリ再配布可能なソフトウェアのライセンスグループ

linux-firmware パッケージが以前にインストールされているなら、インストールの節に進んでください。

前提条件として、sys-kernel/genkernel パッケージの firwmare USE フラグがデフォルトで有効化されているため、パッケージマネージャは sys-kernel/linux-firmware パッケージを取り込もうとするでしょう。linux-firmware をインストールする前に、バイナリ再配布可能なソフトウェアライセンスを受諾する必要があります。

このライセンスグループは、/etc/portage/make.conf ファイル内で ACCEPT_LICENSE の値として @BINARY-REDISTRIBUTABLE を追加することで、すべてのパッケージに対してシステム全体で受諾することができます。/etc/portage/package.license/linux-firmware ファイルで個別の受諾を追加することで、linux-firmware パッケージのみに対して受諾することもできます。

必要であれば、ハンドブックのベースシステムのインストールの章で利用可能な、ソフトウェアライセンスを受諾する方法を再確認して、受け入れられるソフトウェアライセンスのために変更を加えてください。

分析麻痺に陥ってきたなら、次のようにすればよいでしょう:

root #mkdir /etc/portage/package.license
ファイル /etc/portage/package.license/linux-firmwarelinux-firmware パッケージのためにバイナリ再配布可能ライセンスを受諾する
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

インストール

説明や前提条件はさておき、sys-kernel/genkernel パッケージをインストールしてください:

root #emerge --ask sys-kernel/genkernel

生成

genkernel all を実行してカーネルソースをコンパイルしましょう。ただ、genkernel は多種多様に異なるコンピュータアーキテクチャのために、幅広いハードウェアをサポートするカーネルを生成するため、コンパイルが完了するまでにかなりの時間がかかることがあるということに注意しましょう。

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

genkernel が完了したら、カーネルと初期 RAM ファイルシステム (initramfs) が生成され、/boot ディレクトリにインストールされていることでしょう。関連するモジュールは /lib/modules ディレクトリにインストールされるでしょう。initramfs は、(live ディスクイメージ環境でそうであるように) ハードウェアの自動検出を行うために、カーネルをロードした後すぐに開始されます。

root #ls /boot/vmlinu* /boot/initramfs*
root #ls /lib/modules

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

はじめに

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

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

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

root #emerge --ask sys-apps/pciutils
メモ
chroot環境では、lspciが出力していると思われる(pcilib: cannot open /sys/bus/pci/devicesのような)pcilibの警告は、無視しても構いません。

システム情報を得るための別の方法は、lsmodを使ってインストールCDが使っているカーネルモジュールを把握することです。その情報は何を有効にすべきかとてもよいヒントを与えてくれるでしょう。

では、カーネルソースがあるディレクトリに移動して、make menuconfigを実行しましょう。このコマンドはメニューベースの設定画面を起動します。

root #cd /usr/src/linux
root #make menuconfig

Linux カーネルの設定はとても多くのセクションを持っています。まず最初にいくつかの必須オプションを述べましょう(そうでない場合、Gentoo は動作しない、もしくは追加の処置なしには正しく動作しません)。 Gentoo wiki の Gentoo カーネルコンフィギュレーションガイドには、さらに役立つ記述があるでしょう。

必須オプションを有効にする

もし sys-kernel/gentoo-sources を使用する場合は、Gentoo 固有のコンフィギュレーションオプションを有効化することを強く推奨します。これらは、正しく機能するために必要な最小限のカーネルの機能が有効化されることを確実にします:

カーネル Gentoo 固有オプションを有効化する
Gentoo Linux --->
  Generic Driver Options --->
    [*] Gentoo Linux support
    [*]   Linux dynamic and persistent device naming (userspace devfs) support
    [*]   Select options required by Portage features
        Support for init systems, system and service managers  --->
          [*] OpenRC, runit and other script based systems and managers
          [*] systemd

通常、最後の 2 行の選択は init システムの選択(OpenRCsystemd か)に依存します。両方の init システムへのサポートを有効化しても害はありません。

もし sys-kernel/vanilla-sources を使用する場合は、この init システムに関する追加の選択項目は利用できないでしょう。サポートを有効化することは可能ですが、このハンドブックの範囲からは外れることです。

典型的なシステムコンポーネントへのサポートを有効化する

システムのブートに必須となるドライバ (SATA コントローラ、NVMe ブロックデバイスサポート、ファイルシステムサポート等) は、モジュールではなく、カーネルの一部としてコンパイルしなければなりません。そうしないと、システムがまったくブートできない場合があります。

次に正確なプロセッサタイプを選択します。このとき、もし使えるのであればMCE機能を有効にすることが推奨されます。これによりハードウェアの異常が通知されるようになるでしょう。いくつかのアーキテクチャ(x86_64)で、これらのエラーはdmesgでは確認できませんが、/dev/mcelogにログが残ります。この機能を有効にするためにapp-admin/mcelogパッケージが必要になります。

また、Maintain a devtmpfs file system to mount at /devを選択することで、必須となるデバイスファイルがブートプロセスの初期段階で使えるようになります (CONFIG_DEVTMPFSCONFIG_DEVTMPFS_MOUNT):

カーネル devtmpfs サポートを有効にする (CONFIG_DEVTMPFS)
Device Drivers --->
  Generic Driver Options --->
    [*] Maintain a devtmpfs filesystem to mount at /dev
    [*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

SCSI ディスクサポートが有効になっているか確認してください(CONFIG_BLK_DEV_SD):

カーネル SCSI ディスクサポートを有効にする (CONFIG_SCSI, CONFIG_BLK_DEV_SD)
Device Drivers --->
  SCSI device support  ---> 
    <*> SCSI device support
    <*> SCSI disk support
カーネル 基本的な SATA および PATA サポートを有効化する (CONFIG_ATA_ACPI, CONFIG_SATA_PMP, CONFIG_SATA_AHCI, CONFIG_ATA_BMDMA, CONFIG_ATA_SFF, CONFIG_ATA_PIIX)
Device Drivers --->
  <*> Serial ATA and Parallel ATA drivers (libata)  --->
    [*] ATA ACPI Support
    [*] SATA Port Multiplier support
    <*> AHCI SATA support (ahci)
    [*] ATA BMDMA support
    [*] ATA SFF support (for legacy IDE and PATA)
    <*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)

基本的な NVMe サポートが有効になっているか確認してください:

カーネル Linux 4.4.x で基本的な NVMe サポートを有効化する (CONFIG_BLK_DEV_NVME)
Device Drivers  --->
  <*> NVM Express block device
カーネル Linux 5.x.x で基本的な NVMe サポートを有効化する (CONFIG_DEVTMPFS)
Device Drivers --->
  NVME Support --->
    <*> NVM Express block device

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

カーネル 追加の NVMe サポートを有効化する (CONFIG_NVME_MULTIPATH, CONFIG_NVME_MULTIPATH, CONFIG_NVME_HWMON, CONFIG_NVME_FC, CONFIG_NVME_TCP, CONFIG_NVME_TARGET, CONFIG_NVME_TARGET_PASSTHRU, CONFIG_NVME_TARGET_LOOP, CONFIG_NVME_TARGET_FC, CONFIG_NVME_TARGET_FCLOOP, CONFIG_NVME_TARGET_TCP
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
  [*]   NVMe Target Passthrough support
  <M>   NVMe loopback device support
  <M>   NVMe over Fabrics FC target driver
  < >     NVMe over Fabrics FC Transport Loopback Test driver (NEW)
  <M>   NVMe over Fabrics TCP target support

次にFile Systemsで、システムが使用するファイルシステムに必要なサポートを選択しましょう。ルートファイルシステムに使われるファイルシステムをモジュールとしてコンパイルしてはいけません。モジュールにした場合、システムがパーティションをマウントできないおそれがあります。また、ここでVirtual memory/proc file systemも選択してください。システムの必要に応じて以下の選択肢から1個以上を選択してください:

カーネル ファイルシステムサポートを有効化する (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_BTRFS_FS, CONFIG_XFS_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS)
File systems --->
  <*> Second extended fs support
  <*> The Extended 3 (ext3) filesystem
  <*> The Extended 4 (ext4) filesystem
  <*> Btrfs filesystem support
  <*> XFS filesystem support
  DOS/FAT/NT Filesystems  --->
    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
  Pseudo Filesystems --->
    [*] /proc file system support
    [*] Tmpfs virtual memory file system support (former shm fs)

もしインターネットに接続するために、PPPoEもしくはダイヤルアップモデムを使う場合、次のオプションを有効にしてください (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):

カーネル PPPoE サポートを有効化する(PPPoE, CONFIG_PPPOE, CONFIG_PPP_ASYNC, CONFIG_PPP_SYNC_TTY
Device Drivers --->
  Network device support --->
    <*> PPP (point-to-point protocol) support
    <*> PPP over Ethernet
    <*> PPP support for async serial ports
    <*> PPP support for sync tty ports

2つの圧縮オプションは選択しても差し支えありませんが、必須というわけでもありません。PPP over Ethernetオプションも同様です。これはカーネルモードのPPPoEをするために設定された時だけにpppによって使用されるものです。

カーネルにネットワークカード(イーサネットもしくはワイヤレス)のサポートを組み込むことを忘れてはいけません。

多くのシステムではマルチコアを使用できます。Symmetric multi-processing supportを有効にすることは重要です (CONFIG_SMP):

カーネル SMP サポートを有効にする (CONFIG_SMP)
Processor type and features  --->
  [*] Symmetric multi-processing support
メモ
マルチコアシステムでは、それぞれのコアが1プロセッサとカウントされます。

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

カーネル USB とヒューマンインプットデバイスのサポートを有効にする (CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, (CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, CONFIG_USB4)
Device Drivers --->
  HID support  --->
    -*- HID bus support
    <*>   Generic HID driver
    [*]   Battery level reporting for HID devices
      USB HID support  --->
        <*> USB HID transport layer
  [*] USB support  --->
    <*>     xHCI HCD (USB 3.0) support
    <*>     EHCI HCD (USB 2.0) support
    <*>     OHCI HCD (USB 1.1) support
  <*> Unified support for USB4 and Thunderbolt  --->

Optional: Signed kernel modules

To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:

カーネル Sign kernel modules CONFIG_MODULE_SIG_ALL
[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Automatically sign all modules    
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

Optionally change the hash algorithm if desired.

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

カーネル Enforce signed kernel modules CONFIG_MODULE_SIG_FORCE
[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Require modules to be validly signed
    [*]     Automatically sign all modules
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

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

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

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

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

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

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

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
カーネル Specify signing key CONFIG_MODULE_SIG_KEY
-*- Cryptographic API  ---> 
  Certificates for signature checking  --->  
    (/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key

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

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

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

Optional: Signing the kernel image (Secure Boot)

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

カーネル Lockdown for secureboot
General setup  --->
  Kexec and crash features  --->   
    [*] Enable kexec system call                                                                                          
    [*] Enable kexec file based system call                                                                               
    [*]   Verify kernel signature during kexec_file_load() syscall                                                        
    [*]     Require a valid signature in kexec_file_load() syscall                                                        
    [*]     Enable ""image"" signature verification support
</div>  

<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Enable loadable module support  
  -*-   Module signature verification    
    [*]     Require modules to be validly signed
    [*]     Automatically sign all modules
    Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
</div>  

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

  <div lang="en" dir="ltr" class="mw-content-ltr">
[*]   Digital signature verification using multiple keyrings                                                            
  [*]     Enable asymmetric keys support                                                                                     
  -*-       Require all keys on the integrity keyrings be signed                                                              
  [*]       Provide keyring for platform/firmware trusted keys                                                                
  [*]       Provide a keyring to which Machine Owner Keys may be added                                                        
  [ ]         Enforce Machine Keyring CA Restrictions

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

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

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

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

root #emerge --ask app-crypt/sbsigntools
root #sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-image
メモ
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second sperate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.

Then proceed with the installation.

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

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

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

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


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

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

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

カーネルのコンパイルが終了したら、カーネルのイメージを /boot にコピーしましょう。

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


カーネルのインストール

Installkernel

Installkernel may be used to automate, the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.

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

systemd-boot

When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.

On OpenRC systems:

ファイル /etc/portage/package.use/systemd-boot
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils

On systemd systems:

ファイル /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
# Needed for <systemd-254
sys-apps/systemd gnuefi
root #emerge --ask sys-apps/systemd

GRUB

Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel

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

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

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

The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.


Building an initramfs

In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs. The default configuration of the Project:Distribution Kernel requires an initramfs.

Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.

重要
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass --kernel-config=/path/to/kernel.config to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.

Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut

Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:

root #emerge --ask sys-kernel/dracut
root #dracut --kver=3.16.5-gentoo

The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:

root #ls /boot/initramfs*

Optional: Building an Unified Kernel Image

An Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.

An unified kernel image requires a stub loader, currently the only one available is systemd-stub. To enable it:

For systemd systems:

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

For OpenRC systems:

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

Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).

For dracut:

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut uki
ファイル /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

For ukify:

ファイル /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut ukify uki
ファイル /etc/kernel/cmdline
some-kernel-command-line-arguments

Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.

Generic Unified Kernel Image

The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:

ファイル /etc/portage/package.use/generic-uki
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki

セキュアブート

The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.

For dracut:

ファイル /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"

For ukify:

ファイル /etc/kernel/uki.conf
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

Rebuilding external kernel modules

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

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

External kernel modules may also be rebuilt manually with:

root #emerge --ask @module-rebuild

カーネルモジュール

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

メモ
ハードウェアモジュールを手作業で列挙する必要はありません。ほとんどの場合、udev は接続を検出したハードウェアのモジュールを自動でロードします。ですが、自動でロードされるであろうモジュールを列挙することは特に有害ではありません。モジュールが二度ロードされることはありません。モジュールの状態は、ロードされているかいないか、どちらかしかありません。時として変なハードウェアは、ドライバをロードするのにこうした手助けが必要になることがあります。

/etc/modules-load.d/*.conf ファイルに、ブート時に毎回ロードしなければならないモジュールを、1 行ごとに 1 モジュールのフォーマットで追加することができます。モジュールに追加のオプションを与える必要があれば、ここではなく /etc/modprobe.d/*.confファイルで設定すべきです。

特定のカーネルバージョンで利用可能なすべてのモジュールを把握するためには、次の find コマンドを実行してください。"<kernel version>" を検索したいカーネルのバージョンで適切に置き換えることを忘れないでください:

root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less

特定のカーネルモジュールのロードを強制する

3c59x.ko モジュール (これは特定の 3Com ネットワークカードファミリのためのドライバです) をロードするようにカーネルに強制するには、/etc/modules-load.d/network.conf 内にモジュール名を記載してください。

root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf

モジュールの .ko ファイル拡張子はロード機構にとって重要ではなく、設定ファイルから除かれるということに注意してください:

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

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





ファイルシステムの情報

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

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

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

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

重要
LVM ボリューム上に置かれたファイルシステムの UUID と、LVM ボリュームの LVM スナップショットの UUID は同じなので、LVM ボリュームをマウントするために UUID を使用するのは避けるべきです。

パーティションラベルと UUID

GPTルートを選択した人は、/etc/fstab でパーティションを定義する際に '頑丈' な方法を使うことができます。パーティション自体にどのファイルシステムが使用されているかにかかわらず、ブロックデバイスの個々のパーティションを識別するのにパーティションラベルやパーティションのUUIDを使うことができます。パーティションラベルとパーティションのUUIDはそれぞれPARTLABELPARTUUID接頭辞で識別され、そして端末で blkid コマンドを実行すると簡単に調べられます。EFI システムでの出力は以下のようなものになるでしょう:

Output for an amd64 EFI system using the Discoverable Partition Specification UUIDs may like the following:

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: UUID="12c37dea-624b-48b6-88b8-fba427f5f341" TYPE="swap" PARTLABEL="swap" PARTUUID="0657fd6d-a4ab-43c4-84e5-0933c84b4f4f"
/dev/sda3: UUID="9bd83a8f-75c6-4a04-b155-6f6b748509a9" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="rootfs" PARTUUID="4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
/dev/sda1: UUID="166F-2917" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="efi" PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"

パーティションラベルも絶対にとは言えないのに対し、fstab で UUID を使ったパーティション指定を使えば、たとえ将来ファイルシステムが変更されるとしても、ブートローダーがボリューム検出に迷うことはありません。従来のブロックデバイスファイル (/dev/sd*N) を使った指定は、SATA ブロックデバイスの追加または削除とシステムの再起動が頻繁に行われるシステムでは危険です。

ブロックデバイスのファイル名は様々な要素 (ディスクがどんな順番でいくつ接続されているかを含む) によって変化します。またファイル名の順番についても、初期起動プロセス中にカーネルがどのデバイスを最初に検知するかによって変化します。つまり、システム管理者がディスクの順序を頻繁にいじったりしない限りは、デフォルトのブロックデバイスファイルを使うのがシンプルで素直な方法です。

fstab について

Linuxでは、システムで使用するすべてのパーティションは/etc/fstabに記載されていなければなりません。このファイルは、これらパーティションのマウントポイント(これらはファイルシステムに存在しなければなりません)、どのようにマウントされるべきか、また特別なオプション(自動マウントかそうでないか、ユーザー権限でマウントできるかどうか等)を定義します。

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)に設定しましょう。
重要
Gentoo stage ファイルに含まれるデフォルトの /etc/fstab ファイルは有効な fstab ではなく、関連する値を入力するために使用できるテンプレートです。
root #nano /etc/fstab

DOS/レガシー BIOS システム

では、/boot/パーティションをどのように記述すればよいか見てみましょう。これは一つの例です。実際はインストール手順の最初に決めたパーティション構成通りに修正しなければなりません。ここでは ppc64 のパーティション構成の例として、xfs ファイルシステムを使う/dev/sda1パーティションを/boot/にします。このパーティションはブート中にチェックされなければなりません。fstabは以下のようになるでしょう。

ファイル /etc/fstab/etc/fstab の DOS/レガシー BIOS boot 行の例
# Adjust any formatting difference from the "Preparing the disks" step
/dev/sda1            defaults        0 2

あるユーザーはセキュリティを向上させるために/boot/パーティションを自動的にマウントしたくないかもしれません。その場合はdefaultsnoautoで置き換えてください。これは、そのパーティションを使いたいときは都度手動でマウントしなければならないことを意味します。

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

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

ファイル /etc/fstabDOS/レガシー BIOS システム向けの完全な /etc/fstab の例
# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step
/dev/sda1               defaults    0 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            xfs    defaults,noatime              0 1
</div>

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

UEFI システム

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

ファイル /etc/fstabUEFI システム向けの完全な /etc/fstab の例
# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step
               defaults    0 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            xfs    defaults,noatime              0 1
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

DPS UEFI PARTUUID

Below is an example of an /etc/fstab file for a disk formatted with a GPT disklabel and Discoverable Partition Specification (DPS) UUIDs set for UEFI firmware:

ファイル /etc/fstabGPT disklabel DPS PARTUUID fstab example
# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step.
# This example shows a GPT disklabel with Discoverable Partition Specification (DSP) UUID set:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b                                  0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f   none            sw                           0 0
PARTUUID=   /           xfs    defaults,noatime              0 1

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

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

ヒント
パフォーマンスを低下させるため、/etc/fstab 内で discard マウントオプションを定義させるのは推奨されません。cron または timer (systemd) のようなジョブスケジューラを使用して、定期的にブロックの破棄をスケジュールするほうが、一般的により良い方法です。さらなる情報については、Periodic fstrim jobs を確認してください。

再度/etc/fstabを確認して、保存、エディタを終了します。

ネットワーク接続のための情報

重要な注意点として、このセクションは読者がシステムをローカルエリアネットワークに手っ取り早く参加させることができるように、提供しています。

OpenRC を動かしているシステムについては、ネットワーク設定のためのより詳細なリファレンスが、ハンドブックの終わりのほうの高度なネットワーク設定のセクションでカバーされています。より詳細なネットワーク要件のあるシステムは一度そちらへ飛んで、それからここに戻ってきて残りのインストール作業を続ける必要があるかもしれません。

より詳細な systemd のネットワーク設定については、systemd の記事のネットワークの箇所を確認してください。

ホスト名

さて、PCには名前をつけなければいけません。至極簡単に思えますが多くのシステム管理者はホスト名として適切な名前を付けるのに苦労しています。事を早く進めるために、選んだ名前は後で変更できることを知っておいてください。判りやすいように、ここでは単にマシンをtuxと呼ぶことにします。

ホスト名を設定する (OpenRC または systemd)

root #echo tux > /etc/hostname

systemd

現在実行中の systemd についてシステムのホスト名を設定するには、hostnamectl ユーティリティを使うことができます。しかしながらインストールプロセス中は、systemd-firstboot コマンドを代わりに使う必要があります (後でハンドブックの該当箇所を参照してください)。

ホスト名を "tux" に設定するためには、次のようにします:

root #hostnamectl hostname tux

hostnamectl --help または man 1 hostnamectl を実行することで、ヘルプを確認してください。

ネットワーク

ネットワークインターフェースを構成するために利用できる選択肢は多く存在します。この節ではそのうち一部の方法だけをカバーします。必要な構成に最適と思われるものをひとつ選んでください。

dhcpcd での DHCP (どんな init システムでも)

多くの LAN ネットワークは DHCP サーバは運用しています。その場合は、dhcpcd プログラムを使用して IP アドレスを取得するのがおすすめです。

インストールするには:

root #emerge --ask net-misc/dhcpcd

OpenRC システム上で、サービスを有効化して開始するには:

root #rc-update add dhcpcd default
root #rc-service dhcpcd start

systemd システム上で、サービスを有効化するには:

root #systemctl enable dhcpcd

これらのステップが完了したら、次にシステムが起動したときに、dhcpcd が DHCP サーバから IP アドレスを取得するはずです。さらなる詳細については Dhcpcd の記事を確認してください。

netifrc (OpenRC)

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

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

メモ
bonding、ブリッジ、802.1Q VLAN、無線ネットワークに間するより詳細な情報は、追加のネットワーク設定セクションを参照してください。

すべてのネットワーク設定は/etc/conf.d/netにあります。直接的ではありますが、おそらく直感で理解できる構文ではありません。しかし恐れることはありません。すべては以下で説明されます。/usr/share/doc/netifrc-*/net.example.bz2に、多くの異なる設定に対して完全にコメントが付与された例が記載されています。

最初に net-misc/netifrc をインストールします。

root #emerge --ask --noreplace net-misc/netifrc

DHCPはデフォルトで使用されます。DHCPを動かすために、DHCPクライアントをインストールしなければなりません。これは Installing Necessary System Toolsで説明されます。

もし、特別なDHCPのオプションを設定している、もしくはDHCPをまったく使いたくない等の理由で、ネットワーク接続をしなければならないときは、/etc/conf.d/netを編集します。

root #nano /etc/conf.d/net

IPアドレスとルーティングを設定するのはconfig_eth0routes_eth0です。

メモ
ここではネットワークインターフェイスがeth0であると仮定していますが、これはシステムによって違います。もし、最近のインストールメディアから起動しているのであれば、インストール時と同じインターフェイス名が使われると思ってよいでしょう。より詳しい情報はネットワークインターフェースの命名セクションを参照してください。
ファイル /etc/conf.d/net静的 IP アドレスの定義
config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"

DHCPを使う場合は、config_eth0を設定してください。

ファイル /etc/conf.d/netDHCPの定義
config_eth0="dhcp"

さらなる設定オプションのリストについては、/usr/share/doc/netifrc-*/net.example.bz2を参照してください。もし特定のDHCPを設定しなければならないときは、DHCPクライアントのmanページも必ず読みましょう。

もし、システムが複数のネットワークインターフェースを持っている場合は、config_eth1config_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ファイルを更新します。(例えばeth0enp3s0または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
ファイル /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-setupsystemd-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 ステップは有用でしょう。





システムロガー

OpenRC

同じ機能が複数のパッケージによって提供されるツールがいくつかあります。そういったツールはstage3アーカイブには含まれていません。どのパッケージをインストールしたいのかをあなた次第で選んでください。

まずシステムにロギング機構を提供するツールを決定しましょう。UnixとLinuxでは歴史をかけて素晴らしいログ機能を発展させてきました -- お望みならログファイルにシステムで起こった全てを記録できます。

Gentooでは複数のシステムロガーから使いたいものを選択することができます。このうちのいくつかを紹介します。

  • app-admin/sysklogdは、システムのログを取得するための伝統的なデーモンを集めたものです。デフォルトのログ設定をそのまま使ってもうまく働くので、このパッケージは初心者にはいい選択肢です。
  • app-admin/syslog-ngは、進化したシステムロガーです。1つの大きなファイルにログを取る以上のことをするには、何らかの設定が必要です。更に上級のユーザは、ロギングの発展性に基いてこのパッケージを選択できます。スマートなロギングのためには追加の設定が必要になることに注意してください。
  • app-admin/metalogは、高度な設定ができるシステムロガーです。

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

ヒント
もし syslog-ng を使おうと思っているなら、後で logrotate をインストールして設定しましょう。syslog-ng にはログファイルをローテーションする機構がありません。一方で、より新しいバージョン (>= 2.0) の sysklogd は自身でログローテーションを行います。

選択したシステムログツールをインストールするには、それを emerge してください。OpenRC では、rc-update を使ってデフォルトのランレベルにスクリプトを追加してください。次の例では app-admin/sysklogd をインストールして、それをシステムの syslog ユーティリティとして有効化します:

root #emerge --ask app-admin/sysklogd
root #rc-update add sysklogd default

systemd

ここまで OpenRC ベースのシステムのためにロギング機構の選択肢を提示しましたが、一方 systemd には systemd-journald という組み込みのロガーが含まれています。systemd-journald サービスは、上のシステムロガーの節で概説したロギング機能のほとんどを取り扱うことができます。つまり、システムマネージャおよびサービスマネージャとして systemd を実行するシステムのほとんどでは、追加の syslog ユーティリティを追加する部分を問題無く省略することができます。

journalctl を利用したシステムログの検索、閲覧についての詳細は、man journalctl を参照してください。

中央ホストへログを転送する場合などさまざまな理由により、systemd ベースのシステム上で冗長なシステムロギング機構を含めたいことがあるかもしれません。これはハンドブックの典型的想定読者にとっては一般的な事態ではなく、高度なユースケースであるとみなします。そのため、ハンドブックでは取り扱いません。

任意自由選択: cronデーモン

OpenRC

cronデーモンは入れても入れなくてもよく、システムに必須ではありませんが、インストールしておくのが賢明でしょう。

cron デーモンは、予定された間隔を空けてコマンドを実行します。間隔は毎日、毎週、毎月、毎火曜日、隔週、などで設定できます。賢明なシステム管理者は、定型的なシステム管理タスクを、cron デーモンを活用して自動化するでしょう。

すべての cron デーモンは予定されたタスクのための高いレベルの粒度をサポートしており、また通常は、予定されたタスクが期待通り完了しなかった場合に、e メール等の形式で通知を送信する機能を含んています。

Gentoo ではいくつもの cron デーモンを提供しています:

  • sys-process/cronie - cronie はオリジナルの cron をベースとしていて、PAM と SELinux を使用できるなど、セキュリティと設定の改良がなされています。
  • sys-process/dcron - この軽量な cron デーモンは、利便性を損わない範囲で、簡潔で安全であることを目標としています。
  • sys-process/fcron - cron および anacron の機能を含めて拡張されたコマンドスケジューラ。
  • sys-process/bcron - 安全な操作を念頭に入れて設計された、比較的新しい cron システム。これを実現するために、システムは複数の独立したプログラムに分けられていて、それぞれが独立したタスクに責任を持ち、プログラム間の通信は厳密に制御されています。

cronie

次の例では sys-process/cronie を使用します:

root #emerge --ask sys-process/cronie

電源投入時に自動で cronie を開始するために、cronie を default システムランレベルに追加してください:

root #rc-update add cronie default

代替案: dcron

root #emerge --ask sys-process/dcron

cron エージェントとして dcron を使う場合、初期設定のための追加コマンドが必要です。

root #crontab /etc/crontab

代替案: fcron

root #emerge --ask sys-process/fcron

スケジュールされたタスクハンドラとして fcron を選択した場合、追加で emerge ステップが必要です:

root #emerge --config sys-process/fcron

代替案: bcron

bcron は組み込みの特権分離を持つ、新しい cron エージェントです。

root #emerge --ask sys-process/bcron

systemd

システムロギングと同様に、sysmted ベースのシステムには予定されたタスクのためのサポートが、タイマーという形ですぐ使える状態で含まれています。systemd タイマーはシステムレベルでもユーザレベルでも実行することができ、伝統的な cron デーモンが提供するものと同じ機能を含んでいます。冗長な可能性が必要でない限り、cron デーモンのような追加のタスクスケジューラをインストールすることは通常は不要で、問題無く省略することができます。

任意自由選択: ファイルのインデックスを作成

より高速なファイル検索のためにファイルシステム中の各ファイルのインデックスを作成するときは、sys-apps/mlocateをインストールしてください。

root #emerge --ask sys-apps/mlocate

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

ヒント
opensshd のデフォルト設定は、リモートユーザとして root にログインすることを許可していません。必要であれば非 root ユーザを作成して、インストール完了後にアクセスできるように適切に設定するか、root を許可するように /etc/ssh/sshd_config を修正してください。

インストール後、システムにリモートからアクセスできるようにするためには、ブート時に sshd を開始するように設定する必要があります。

OpenRC

OpenRC で sshd init スクリプトを default ランレベルに追加するには:

root #rc-update add sshd default

(たとえばリモートサーバで)シリアルコンソールからアクセスしなければならない場合、agetty を設定する必要があります。

/etc/inittab のシリアルコンソールの部分のコメントを外してください:

root #nano -w /etc/inittab
# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100

systemd

SSH サーバを有効化するには、次を実行してください:

root #systemctl enable sshd

シリアルコンソールサポートを有効化するには、次を実行してください:

root #systemctl enable getty@tty1.service

省略可能: シェル補完

Bash

Bash は Gentoo システムのデフォルトのシェルですので、補完拡張をインストールすることでシステムの管理を効率的かつ便利にすることができます。app-shells/bash-completion パッケージは、Gentoo に固有のコマンドや多くの共通のコマンドとユーティリティで利用できる補完をインストールします:

root #emerge --ask app-shells/bash-completion

インストール後は、各コマンドのための bash 補完を eselect を通じて管理することができます。さらなる詳細については、bash の記事の Shell completion integrations のセクションを参照してください。

時刻同期

システム時刻を同期する方法を利用することは重要です。これは通常 NTP プロトコルおよびソフトウェアによってなされます。Chrony など、NTP プロトコルを使用する他の実装もあります。

例えば、Chrony をセットアップするには:

root #emerge --ask net-misc/chrony

OpenRC

OpenRC では、次を実行してください:

root #rc-update add chronyd default

systemd

systemd では、次を実行してください:

root #systemctl enable chronyd.service

代わりに systemd ユーザは、デフォルトでインストールされている、よりシンプルな systemd-timesyncd NTP クライアントを利用したいかもしれません。

root #systemctl enable systemd-timesyncd.service

ファイルシステムツール

使っているファイルシステムよって、(ファイルシステムの整合性をチェックしたり、ファイルシステムを (再) フォーマットするために) 必須のファイルシステムツールをインストールする必要があるかもしれません。ext4 ユーザ空間ツール(sys-fs/e2fsprogs) は @system 集合の一部としてインストール済みであることに注意してください。

次の表は、インストールされた環境に特定のファイルシステムのツールが必要な場合、どのツールをインストールすべきかを示します。

ファイルシステム パッケージ
XFS sys-fs/xfsprogs
ext4 sys-fs/e2fsprogs
VFAT (FAT32, ...) sys-fs/dosfstools
Btrfs sys-fs/btrfs-progs
ZFS sys-fs/zfs
JFS sys-fs/jfsutils

nvme 等のデバイスとともに適切にスケジューラを動作させるためには、sys-block/io-scheduler-udev-rules をインストールするのがおすすめです:

root #emerge --ask sys-block/io-scheduler-udev-rules
ヒント
Gentooのファイルシステムについてのさらなる情報は、ファイルシステムの記事を参照してください。

ネットワークツール

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

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

重要
多くのユーザはネットワークに接続するために DHCP クライアントが必要になるでしょう。もし DHCP クライアントがひとつもインストールされていない場合、ネットワークに接続できないことになり、これにより DHCP クライアントを後でダウンロードすることができなくなってしまいます。

DHCP クライアントは、netifrc スクリプトを使用して、一つ以上のネットワークインターフェースのために自動的に IP アドレスを取得します。net-misc/dhcpcdがお薦めです (dhcpcd も参照してください):

root #emerge --ask net-misc/dhcpcd

任意自由選択: PPPoE クライアントのインストール

もしインターネットに接続するためにPPPを使うのであれば、net-dialup/pppパッケージをインストールします。

root #emerge --ask net-dialup/ppp

任意自由選択: 無線ネットワークツールのインストール

もしシステムをワイヤレス・ネットワークに接続させるつもりならば、オープンネットワークあるいはWEPネットワークを使用するためにnet-wireless/iwパッケージを、あるいはWPAまたはWPA2ネットワークを使用するためにnet-wireless/wpa_supplicantパッケージをインストールしてください。iwはまた、ワイヤレス・ネットワークの検出のための便利で基本的な診断ツールでもあります。

root #emerge --ask net-wireless/iw net-wireless/wpa_supplicant

次はブートローダーの設定です。






With the kernel configured and compiled and the necessary system configuration files filled in correctly, it is time to install a program that will fire up the kernel when the system boots. Such a program is called a boot loader.

GRUB が PPC64 ベースの Linux マシン向けのブートローダです。

Using GRUB

インストール

root #emerge --ask sys-boot/grub

Setup bootstrap partition

First, prepare the bootstrap partition that was created created during the preparing the disk step. Following the example, this partition should be /dev/sda2. Optionally, confirm this by using parted:

Replace /dev/sda with the correct device if required.

root #parted /dev/sda print
Model: ATA Patriot Burst El (scsi)

Disk /dev/sda: 120GB

Sector size (logical/physical): 512B/512B

Partition Table: mac

Disk Flags:

Number  Start   End     Size    File system  Name       Flags
 1      512B    32.8kB  32.3kB               Apple
 2      32.8kB  852kB   819kB   hfs          bootstrap  boot
 3      852kB   538MB   537MB   ext4         Boot
 4      538MB   54.2GB  53.7GB  ext4         Gentoo

In this output, partition 2 has the bootstrap information so /dev/sda2 is the correct path to use.

Format this partition as HFS using the hformat command which is part of the sys-fs/hfsutils package:

root #dd if=/dev/zero of=/dev/sda2 bs=512
root #hformat -l bootstrap /dev/sda2

Create a directory to mount the bootstrap partition and then mount it:

root #mkdir /boot/NWBB
root #mount --types hfs /dev/sda2 /boot/NWBB

Setup GRUB

root #grub-install --macppc-directory=/boot/NWBB /dev/sda2

If it installs without errors, unmount the bootstrap:

root #umount /boot/NWBB

Next, bless the partition so it will boot:

root #hmount /dev/sda2
root #hattrib -t tbxi -c UNIX :System:Library:CoreServices:BootX
root #hattrib -b :System:Library:CoreServices
root #humount

Finally, build the grub.cfg file:

root #grub-mkconfig -o /boot/grub/grub.cfg


Using yaboot on IBM hardware

On IBM hardware it is not possible to run yabootconfig or ybin. Proceed with the following steps:

  • Emerge the yaboot-static package.
  • Run the following command, filling in XX with the disk and partition for the PReP partition. {{Path|/dev/sda1}
root #dd if=/usr/lib/yaboot/yaboot.chrp of=/dev/sdXX
  • Construct a yaboot.conf file and place it into /etc/. Take a look at the configuration example above, look into the man page for yaboot.conf (man 8 yaboot.conf, or look at the below yaboot.conf example.
  • Assuming the boot device in OpenFirmware is pointing to the hard drive the prep boot partition is on, then it'll just work. If not, at IPL time, go into the multiboot menu and set the boot device to the one with the prep boot partition.

That's it!

ファイル yaboot.confExample yaboot.conf for IBM hardware
device=disk:
partition=2
root=/dev/sda3
default=linux
timeout=50
  
image=/boot/kernel-3.16.5-gentoo
    label=linux
    append="console=ttyS0,9600"
    read-only

For POWER4, POWER5, and blade-based hardware (where the PReP disk partition and the disk partition that contains the kernel are on the same physical disk), it is possible to use a simplified yaboot.conf. The following should be sufficient:

ファイル yaboot.confyaboot.conf for PReP hardware
default = linux
timeout = 100
image=/boot/kernel-3.16.5-gentoo
        label=linux
        read-only
        root = /dev/sda3
        append="root=/dev/sda2"

To verify that yaboot has been copied to the PReP partition:

root #dd if=/dev/sda1 count=10 | grep ELF
Binary file (standard input) matches
10+0 records in
10+0 records out

A match signifies that yaboot was installed correctly.


システムのリブート

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 環境に入ることができたら、最終章のインストールの締めくくりに進むのがよいでしょう。





ユーザー管理

毎日使用するためのユーザを追加します

Unix/Linux システム上で root として作業するのは危険であり、できるだけ避けるべきです。そのため、日常的に使用するための標準のユーザアカウントを、一つまたは複数追加することを、強くお勧めします。

グループは、そのグループに所属するメンバーができることを定義します。次の表はいくつかの重要なグループを示します。

グループ 説明
audio ユーザアカウントがオーディオデバイスにアクセスできるようにします。
cdrom ユーザアカウントが光学デバイスに直接アクセスできるようにします。
cron ユーザアカウントが cron による時間ベースのジョブスケジューリングにアクセスできるようにします。メモ: systemd サービスシステムを実行するシステム上のユーザアカウントは、cron ジョブの代わりに systemd タイマとユーザサービスファイルを使用することができます。
floppy ユーザアカウントが、フロッピードライブとして知られる、古代の機械的デバイスに直接アクセスできるようにします。このグループは現代的なシステムでは通常は使用されません。
games ユーザアカウントがゲームで遊べるようにします。下の video グループも参照してください。
portage ユーザアカウントが、Portage グループでのみ利用可能な特定の資源にアクセスできるようにします。これは Gentoo の開発とトラブルシューティング目的のために有用です。
usb ユーザアカウントが USB デバイスにアクセスできるようにします。
video ユーザアカウントが、ビデオキャプチャのためのハードウェアと、ハードウェアアクセラレーションにアクセスできるようにします。上の games グループも参照してください。
wheel ユーザアカウントが su (substitute user) コマンドを使うことができるようにし、root アカウントや他のアカウントに切り換えることを許可します。root アカウントを持つシングルユーザシステムでは、メインの標準ユーザをこのグループに追加するのが良い考えでしょう。

例えば wheelusersaudio の 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) ユーティリティを使用することです。これらは (正しく設定されれば) とても安全です。

ディスクのクリーンアップ

インストール用配布物の削除

Gentoo のインストールとリブートが完了し、インストールがすべてうまくいっていれば、stage ファイルやその他のインストール用配布物 - DIGEST、CONTENT、*.asc (PGP 署名) ファイルなど - は安全に削除することができます。

ファイルは / ディレクトリに置かれているので、以下のコマンドで削除することができます:

root #rm /stage3-*.tar.*

次にすることは?

次に何をすればいいかわかりませんか?探索する道が多くあります。Gentooには多くの可能性と共にユーザーが存在します。それゆえ、このwikiや他のGentooに関連するサブドメイン群(下の Gentoo オンラインを見てください)を探索するため、多くのドキュメント化された機能を使うことができます(記述量は多くないのですが…)。

さらなるドキュメント

重要な注意事項として、Gentoo で採用できる選択肢の多さから、このハンドブックが提供するドキュメントの範囲は一部に限られています。ハンドブックの主眼は、Gentoo システムを構築して基本的な管理活動を行えるようにすることに置いています。ハンドブックはあえて、グラフィカル環境、セキュリティ強化 (hardening) についての詳細、その他重要な管理タスクについての指示を除外しています。とはいえ、基本的な機能に関して読者を助けるため、ハンドブックのセクションをまだいくつか用意しています。

読者は絶対に、ハンドブックの Gentoo の操作を読むべきです。これにはソフトウェアをどのように最新の状態にしておくのか、追加のソフトウェアパッケージをどのようにインストールするのか、USE フラグや Gentoo の OpenRC 初期システムの詳細や、インストール後の Gentoo システムを扱うことに関する他の様々な有益なトピックについてが説明されています。

ハンドブック以外では、コミュニティから追加提供されるドキュメントを見つけるために、Gentoo wiki の他のコーナーを探索したいと思うでしょう。Gentoo wiki チームは、documentation topic overview を提供しています。これは、この Wiki にある記事のセレクションをカテゴリー別に一覧にしています。例えば、システムをよりあなたの国に適したものとするためには、ローカライゼーションガイドを参照します(特に英語を第二外国語として話すユーザにとって便利なものです)。

デスクトップ用途で利用したい多数派のユーザは、日常的に使用するためのグラフィカル環境をセットアップすることになるでしょう。対応しているデスクトップ環境 (DE)ウィンドウマネージャ (WM) については、コミュニティによって維持されている 'メタ' 記事が多数存在します。それぞれの DE が必要なセットアップ作業は微妙に異なっているため、ブートストラップ作業の複雑性が増えることに注意してください。

その他にも、Gentoo 上で利用可能なソフトウェアについての俯瞰的な概要を提供するメタ記事が多数存在します。

Gentoo オンライン

重要
読者は、すべての公式の Gentoo オンラインサイトが Gentoo の行動規範によって治められていることに注意するべきです。Gentoo のコミュニティで活動することは特権で、権利ではありません。そしてユーザは、行動規範が理由があるために存在することを知っていると見なされます。

Libera.Chatが運営するInternet Relay Chat(IRC)ネットワークと、メーリングリストを除いて、ほとんどのGentooのウェブサイトは質問をしたり、議論を開始したり、バグを報告するために、サイト単位でアカウントを必要とします。

フォーラムと IRC

私たちのGentoo forumsや多くのInternet Relay Chat Channelsの一つに参加することはウェルカムです。新規のGentooのインストールの最中に遭遇した問題が、過去に発見されたか、またその後いくつかのフィードバックの後に解決したかをフォーラムで調べるのは簡単です。初めてのGentoo故に他のユーザがインストールの問題を経験する可能性は驚くべきものです。ユーザはGentooサポートチャンネルで手助けを求める前に、フォーラムやwikiを調べるよう勧められています。

メーリングリスト

フォーラムやIRCでアカウントを作成するよりはむしろ、メール上でサポートやフィードバックを求めるほうがいいというコミュニティメンバーのために、いくつかのメーリングリストが利用可能です。ユーザは特定のメーリングリストを購読するために説明に従う必要があります。

バグ

時々、wikiを見たり、フォーラム内を探したり、IRCチャンネルやメーリングリストにサポートを求めても、問題に対する既知の解決策がない場合があります。一般的にこれは、GentooのBugzillaサイトにバグを公開する合図です。

開発ガイド

Gentooの開発についてより多くのことを学びたいと考えている読者は、開発ガイドを見ると良いでしょう。このガイドにはebuildの書き方、eclassの扱い方についての説明や、Gentooの開発の背後にある、多くの一般概念の定義が載っています.

締めくくり

Gentooは堅固で、柔軟でそして素晴らしく維持されたディストリビューションです。開発者コミュニティは、Gentooをどのようにさらによりよいディストリビューションにするかについてのフィードバックを聞けることを嬉しく思います。

確認として書いておきますが、このハンドブックに対するすべてのフィードバックは、ガイドライン(ハンドブックのはじめにあるどうやってハンドブックを改善しますか?のセクションに詳細があります)に従っているべきです。

We look forward to seeing how our users will choose to implement Gentoo to fit their unique use cases and needs.




Warning: Display title "Gentoo Linux ppc64 ハンドブック: Gentoo をインストールする" overrides earlier display title "ハンドブック:PPC64/フル/インストール".