ハンドブック:パート/インストール/Gentooベースシステムのインストール

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


警告
Handbook:Parts 名前空間 (このページのことです!) の手順に直接従うべきではありません。以下に表示されている文章は、コンピュータアーキテクチャごとのハンドブックに情報をトランスクルードするための骨格として使用されるもので、そのため重要な情報が抜けています

対象のコンピュータアーキテクチャ向けの手順を読むには、ハンドブックのリストを確認してください。
Parts ハンドブック
インストール
インストールについて
メディアの選択
ネットワーク設定
ディスクの準備
stage ファイル
ベースシステムのインストール
カーネルの設定
システムの設定
ツールのインストール
ブートローダの設定
締めくくり
Gentoo の操作
Portage について
USE フラグ
Portage の機能
Init スクリプトシステム
環境変数
Portage の操作
ファイルとディレクトリ
変数
ソフトウェアブランチの併用
追加ツール
カスタムパッケージリポジトリ
高度な機能
OpenRC ネットワーク設定
はじめに
高度な設定
モジュール式ネットワーク
無線
機能の追加
動的な管理


chroot する

DNS 情報をコピーする

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

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

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

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

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

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

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

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

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

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

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

新しい環境に入る

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

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

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

root #mkdir /efi
root #mount /dev/sda1 /efi

DOS/レガシー BIOS システム

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

root #mount /dev/sda1 /boot

Portage を設定する

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

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

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

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

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

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


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

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

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

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

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

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

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

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

root #emerge --sync

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

root #emerge --sync --quiet

ニュースを読む

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

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

ニュース項目は、Gentoo ebuild リポジトリを通じて、ユーザーに重要なメッセージを通知するためのコミュニケーション手段です。これらニュース項目を管理するためにeselect newsを使用します。eselectはGentooに固有のユーティリティで、システム管理のための共通の管理インターフェースを提供します。この場合、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/amd64/23.0 *
  [2]   default/linux/amd64/23.0/desktop
  [3]   default/linux/amd64/23.0/desktop/gnome
  [4]   default/linux/amd64/23.0/desktop/kde
メモ
コマンドの出力は一例で、常に更新されています。
メモ
systemd を使用するには、名前に "systemd" を含んだプロファイルを選択してください。逆もまた然りです。

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

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

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

root #eselect profile set 2
メモ
This is a placeholder for architecture-specific profile information
メモ
developerサブプロファイルはGentoo Linux開発向けの固有のプロファイルであり、通常のユーザーが使用するものではありません。

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

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

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

リポジトリの構成

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

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

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

ファイル /etc/portage/binrepos.conf/gentoobinhost.confCDN ベースのバイナリパッケージホストの例
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

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

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

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

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

ファイル /etc/portage/make.confデフォルトでバイナリパッケージを使用するように Portage を設定する
# FEATURES 変数内の値のリストに getbinpkg を追加してください
FEATURES="${FEATURES} getbinpkg"
# 署名を要求する
FEATURES="${FEATURES} binpkg-request-signature"

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

root #getuto

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

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

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

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

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

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

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

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

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

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

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

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

/etc/portage/make.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 --oneshot app-portage/cpuid2cpuflags

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

root #cpuid2cpuflags

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

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

VIDEO_CARDS

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

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

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

各種 GPU ごとの詳細は、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 フラグが設定されている。

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

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

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

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

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

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

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

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


タイムゾーン

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

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

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

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

OpenRC

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

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

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

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

systemd

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

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

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

ロケールの設定

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

ロケールの生成

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

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

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

root #nano /etc/locale.gen

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

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

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

root #locale-gen

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

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

ロケールの選択

この時点で、システム全体で有効になるロケールを設定できます。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 2

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

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

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

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

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

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

参照