ハンドブック:HPPA/インストール/Stage
stage tarballをインストールする
日時を設定する
Gentoo をインストールする前に、時刻を正しく設定しなくてはなりません。Gentoo のウェブベースのサービスではセキュリティ証明書を利用しているため、システム時刻があまりにもずれていると、インストール用ファイルをダウンロードできないかもしれません。また、初期のインストールが完了した後で時刻を修正した場合、未来の日付で保存されたファイルがおかしなエラーを引き起こすことがあるかもしれません。
date コマンドを実行して、現在の日付と時刻が正しいか確認してください。
root #dateMon Oct 3 13:16:22 PDT 2021
表示された日時が 2、3 分以上ずれている場合は、正確を期すため、以下に示す方法のうちいずれかに従って更新してください。
自動
ほとんどの読者は、タイムサーバを利用してシステムに自動で時刻を更新させることを望むでしょう。
一部のマザーボードは、システムの電源がオフになっている間も比較的正確な時刻を保つための、リアルタイムクロック (RTC) を搭載していないことがあります。これらのシステムでは、システム起動のたびに、そしてその後定期的に、システム時刻を時刻サーバと自動的に同期するように設定するのがとても重要です。これは RTC を搭載しているけれど、バッテリーがだめになってしまったシステムについても、同様に重要です。
公式 Gentoo live 環境には、chronyd コマンド (net-misc/chrony パッケージを通して利用可能です) と、ntp.org 時刻サーバを指定した設定ファイルも含まれています。これによって、時刻サーバを利用して、システム時刻を UTC 時刻と自動で同期することができます。この方法はネットワーク設定を必要とし、アーキテクチャによっては利用できないかもしれません。
自動時刻同期によって犠牲になるものもあります。例えば、システムのIPアドレスや、関連するネットワークの情報が、時刻サーバ(下の例では ntp.org)に明らかにされます。プライバシーが心配なユーザーは、下記の方法でシステム時刻を設定する前に、このことを理解しておくべきです。
root #chronyd -q手動
タイムサーバにアクセスできないシステムについては、date コマンドをシステム時刻を手動設定するのにも使えます。引数として、次のフォーマットを使います: MMDDhhmmYYYY 形式 (Month (月)、Day (日)、Hour (時)、minute (分)、Year (年))。
すべての Linux システムでは UTC で時刻を設定することが推奨されます。タイムゾーンはインストール中にあとで設定します。タイムゾーンを設定すると、時刻の表示がローカル時刻に切り替わります。
例えば、2021年の10月3日 13時16分に設定するには、以下を実行してください:
root #date 100313162021stage tarballを選択する
すべてのアーキテクチャが multilib オプションを持っているわけではありません。多くは、ネイティブコードでしか動作しません。multilib が最もよく適用されているのは amd64 です。
multilib (32ビットと64ビット)
ベースとなるtarballを適切に選ぶことで、この後に続くインストールプロセスの相当な時間を短縮できます。特に適切なプロファイルを選ぶで効果があります。ステージtarballの選択はこの後のシステム設定に直接影響し、頭痛の種もしくはtwo later on down the lineを減らします。multilib tarballは64ビットのライブラリを使えるときはそれを使用し、互換性を必要とする場合は32ビットのライブラリを使用します。これはインストールされるほとんどのソフトにとってすばらしい選択肢となります。プロファイルを簡単に変更できるシステムが必要な場合は、そのプロセッサアーキテクチャにあったmultilib tarballをダウンロードしなければなりません。
大部分のユーザは、'advanced'なtar ballを選択すべきではありません。これらは特定のソフトウェアもしくはハードウェアのみに必要です。
非 multilib (64 ビットのみ)
システムのベースとして非multilibのtarballを選択することで、完全な64ビット環境を構築できます。これは事実上、multilibプロファイルへの変更を（可能ではありますが）困難にします。
非 mutilib を必要とする明確な理由がなく、単に Gentoo を使いたいというケースでは、非 multilib を選択すべきではありません。非 multilib から mutilib システムへの変更は、Gentoo の深い知識と低レベルのツールチェーンが必要です (これはおそらく私たちの Toolchain developers を身震いさせるでしょう)。これは気の弱い人への警告ではなく、このガイドの範囲外になるということです。
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 の記事 を確認してください。
Gentoo がインストールされたシステムを OpenRC から systemd に、あるいはその逆に変更することは、技術的には可能です。しかし、変更には多大な労力が必要で、このインストールマニュアルの範囲外です。stage tarball をダウンロードする前に、OpenRC または systemd のどちらをターゲット init システムとして利用するか決定して、対応する stage tarball をダウンロードしてください。
stage tarball をダウンロードする
ルートファイルシステムがマウントされている場所、Gentooのマウントポイント（おそらく/mnt/gentoo）に移動してください。
root #cd /mnt/gentooグラフィカルブラウザ
完全なグラフィカルウェブブラウザがある環境を使っているひとには、stageファイルのURLをメインウェブサイトのダウンロードセクションからコピーするのに何の問題も無いでしょう。単純に適切なタブを選択して、stageファイルへのリンクを右クリックして、Copy Linkしてクリップボードにリンクをコピーして、コマンドライン上でwgetユーティリティにリンクをペーストして、stage tarballをダウンロードします。
root #wget <PASTED_STAGE_URL>コマンドラインブラウザ
伝統的な読者や'古参'の Gentoo ユーザで、コマンドラインのみで作業をする人たちは、グラフィカル環境を必要としないメニュー形式のブラウザである links (www-client/links) を使うほうを好むかもしれません。stage をダウンロードするために、Gentoo ミラーリストに飛んでください。
root #links https://www.gentoo.org/downloads/mirrors/linksでHTTPプロキシを使うには、-http-proxyオプションにプロキシのURLを渡してください。
root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/links に似た lynx (www-client/lynx) というブラウザもあります。links と同じくグラフィカル環境を必要としませんが、メニューはありません。
root #lynx https://www.gentoo.org/downloads/mirrors/プロキシを定義する必要があるならば、http_proxyやftp_proxy変数をexportしてください。
root #export http_proxy="http://proxy.server.com:port"
root #export ftp_proxy="http://proxy.server.com:port"ミラーリストから、近くのミラーを選んでください。通常はHTTPミラーで十分ですが、他のプロトコルも使えます。releases/hppa/autobuilds/ ディレクトリに移動してください。入手可能なすべてのstageファイルが列挙されています。ファイルは、サブアーキテクチャにちなんだ名前のサブティレクトリの中にあることもあります。ファイルを選び、dを押してダウンロードしてください。
stage ファイルのダウンロードが完了したら、整合性を検証して stage tarball のコンテンツが正当か確認することができます。興味のあるひとは次節へ進んでください。
stage ファイルの検証と確認に興味が無いひとは、q を押すことでコマンドラインブラウザを終了して、stage tarball を展開する節へすぐに進むことができます。
検証して確認する
今では、ほとんどの stage は init システムの種類に応じて明示的に (openrc または systemd と) 接尾辞が付けられていますが、アーキテクチャによっては、これらがまだ無いものもあります。
Minimal インストール CD のときと同じく、stage ファイルを検証して確認するためのファイルもダウンロードすることができます。これらの手順は飛ばしてもかまいませんが、ダウンロードしたファイルの整合性を気にするユーザのためにこれらのファイルが提供されています。これらの追加のファイルはミラーディレクトリのルートの下から取得できます。ハードウェアアーキテクチャとシステムプロファイルごとの適切な場所にブラウザで移動して、関連する .CONTENTS.gz、.DIGESTS、そして .sha265 ファイルをダウンロードしてください。
root #wget https://distfiles.gentoo.org/releases/- .CONTENTS.gz は stage tarball 内のファイル一覧を含む圧縮ファイルです。
- stage ファイルの、複数の暗号学的ハッシュアルゴリズムを用いたチェックサムを含む .DIGESTS ファイル。
- stage ファイルの、SHA256 ハッシュアルゴリズムのみを用いたチェックサムを含む .sha265 ファイル。このファイルはすべての stage tarball で取得できるとは限らないことに注意してください。
openssl、sha256sum、または sha512sum などの暗号ツールおよびユーティリティを使用し、その出力を提供された .DIGESTS ファイルに含まれるチェックサムと比較することができます。
例えば、openssl で SHA512 チェックサムを検証するには:
root #openssl dgst -r -sha512 stage3-hppa-<release>-<init>.tar.xzdgst は openssl コマンドにメッセージダイジェストのサブコマンドを使うように指示し、-r はダイジェスト出力を coreutils フォーマットで印字し、-sha512 は SHA512 ダイジェストを選択します。
openssl で BLAKE2B512 チェックサムを検証するには:
root #openssl dgst -r -blake2b512 stage3-hppa-<release>-<init>.tar.xzチェックサムコマンドの出力を、.DIGESTS ファイルに含まれているハッシュとファイル名の値の組み合わせと比較してください。これらの値の組み合わせはチェックサムコマンドの出力と一致している必要があります。一致していない場合、ダウンロードしたファイルが破損しているため、削除して再ダウンロードするべきです。
sha256sum ユーティリティを使用して、関連する .sha265 ファイルに含まれる SHA256 ハッシュを検証するには:
root #sha256sum --check stage3-hppa-<release>-<init>.tar.xz.sha256--check オプションは sha256sum に期待されるファイルと対応するハッシュのリストを読み込ませ、各ファイルごとに、正しく計算できれば "OK" を、そうでない場合は "FAILED" を印字するように指示します。
ISO ファイルと同様に、tarball が改竄されていないことを確認するために、gpg を使って .tar.xz ファイルの電子署名を検証することもできます。
公式 Gentoo live イメージに関しては、自動化されたリリースのために sec-keys/openpgp-keys-gentoo-release パッケージが PGP 署名鍵を提供しています。鍵を検証に使用するためには、まずユーザのセッションに鍵をインポートする必要があります:
root #gpg --import /usr/share/openpgp-keys/gentoo-release.asc非公式 live イメージでは、live 環境内で gpg と wget を提供していれば、Gentoo 鍵を含むバンドルを取得してインポートすることができます:
root #wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --importtarball の署名と、追加で関連するチェックサムファイルを検証してください:
root #gpg --verify stage3-hppa-<release>-<init>.tar.xz.asc
root #gpg --verify stage3-hppa-<release>-<init>.tar.xz.DIGEST
root #gpg --verify stage3-hppa-<release>-<init>.tar.xz.sha256
検証に成功した場合は、上のコマンドの出力に "Good signature from" が含まれるでしょう。
リリースメディアに署名するのに使用された OpenPGP 鍵のフィンガープリントは、リリースメディアの署名ページで確認できます。
stage tarball を展開する
次に、ダウンロードした stage を解凍しましょう。tar ユーティリティを使って次のように進めてください:
root #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner上のコマンドと同じオプション (xpf と --xattrs-include='*.*') を使っていることを確認してください。x は展開 (extract) を示し、p はパーミッションを保持 (preserve) すること、v は詳細 (verbose) な出力、f は tar が標準入力からストリームを読む代わりにファイル (file) を展開することを示しています。
ダッシュ 2 本 (--) で始まるオプションには短い記法がありません。--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.confmake.conf.example ファイルを読めば、記述形式は分かるでしょう。コメント行は # で始まり、他の行は「変数="内容"」の形式で変数を定義します。これらの変数のうちのいくつかについて、次の節で見ていきます。
CFLAGS と CXXFLAGS
CFLAGSとCXXFLAGS変数はそれぞれ、GCC CコンパイラとC++コンパイラのための最適化フラグを定義します。この2つの変数は通常ここで定義されますが、真に最高のパフォーマンスを発揮するためには、このフラグはプログラム毎に別々に設定する必要があるでしょう。すべてのプログラムは異なるからです。しかし、それでは管理が大変なので、make.confファイルでこれらのフラグを定義します。
make.confでは、一般にシステムの応答が速くなるように最適化フラグを設定するべきです。この変数に実験的な設定を書かないでください。過剰な最適化はプログラムの挙動をおかしくすることがあり、クラッシュや誤動作の元となります。
ここではすべての最適化オプションを説明することはしません。すべてを理解するためには、GNUオンラインマニュアルやGCC infoページ（info gcc - Linuxシステムでのみ使えます）を読んでください。make.conf.exampleファイルにはたくさんの設定例と情報が含まれているので、これを読むこともお忘れなく。
最初の設定は-march=または-mtune=フラグです。これはターゲットアーキテクチャの名前を指定します。可能な選択肢はmake.conf.exampleファイル内にコメントとして書かれています。nativeを指定すると、コンパイラは（Gentooをインストールしようとしている）現在のシステムのアーキテクチャをターゲットとして選択してくれるので、よく使われます。
ふたつめの設定は-Oフラグ（ゼロではなく大文字のオー）です。これはgcc最適化クラスフラグを指定します。可能なクラスは、s（サイズ最適化）、0（ゼロ、最適化無し）、1、2、3（速度最適化）です。速度最適化については、各クラスは1段階前のクラスが持つものと同じフラグに加えて、追加のフラグを持ちます。-O2は推奨されるデフォルト設定です。-O3をシステム全体で使うと問題を起こすことが知られているので、-O2にとどめることをおすすめします。
他によく使われる最適化フラグには-pipeがあります。これは、コンパイルステージ間での連絡方法として、一時ファイルではなくパイプを使うよう指定します。生成されるコードには影響しませんが、より多くのメモリを使うようになります。メモリの少ないシステムでは、gccが強制終了するかもしれません。そのような場合には、このフラグは使わないでください。
-fomit-frame-pointerを使うと、必要の無い場合にはフレームポインタをレジスタに保持しなくなります。これはアプリケーションのデバッグ時に深刻な影響を与えるかもしれません。
CFLAGSとCXXFLAGS変数を定義するときには、最適化フラグは1つの文字列として結合してください。stage3アーカイブから解凍したデフォルト値で十分でしょう。以下に例を示します:
# すべての言語において設定するコンパイラフラグ
COMMON_FLAGS="-march=2.0 -O2 -pipe"
# 同じ設定を両方の変数に使用
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
各種コンパイルオプションがどのようにシステムに影響するかについては GCC の最適化 の記事に詳しい情報がありますが、初心者がシステムの最適化を始めるには Safe CFLAGS の記事のほうがもっと実践的な場所かもしれません。
MAKEOPTS
MAKEOPTS 変数は、パッケージのインストール時にどれだけ並行してコンパイルを走らせるかを定義します。Portage バージョン 3.0.31[1] 時点において、未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS 値は nproc が返すスレッド数と同じ数に設定されます。
CPU のスレッド数か、システム全体の RAM 容量を 2 GiB で割った数のうち、小さい方を選択するのがよい選択とされています。
ジョブ数を大きくすると、メモリ使用量にきわめて大きな影響を及ぼします。目安は、指定したジョブ数の各ジョブに対し、最低 2 GiB の RAM が割り当てられるようにすることです (つまり、例えば
-j6 は最低でも 12 GiB を要求します)。メモリが枯渇しないようにするには、利用可能なメモリ容量に合うようにジョブ数を減らしてください。並列 emerge を使用する (
--jobs) と、実効的なジョブ数が指数関数的に (make ジョブ数 × emerge ジョブ数まで) 増大することがあります。これに対しては、localhost-only distcc 構成によって、ホスト当たりのコンパイラインスタンス数を制限することで対処することができます。/etc/portage/make.confmake.confのMAKEOPTSの設定例# 未定義のままの場合、Portage のデフォルトの挙動では MAKEOPTS 値は `nproc` が返すスレッド数と同じ数に設定されます
MAKEOPTS="-j4"
さらなる詳細については man 5 make.conf 内で MAKEOPTS を検索してください。
よーい、ドン！
好みの設定に合わせて /mnt/gentoo/etc/portage/make.conf を変更し、保存してください。nano では Ctrl+o で変更を保存して、Ctrl+x で終了できます。
それでは Gentoo ベースシステムのインストールに進んでください。
参照