ブートローダーの設定
ブートローダを選ぶ
これまでLinuxカーネルを設定すると共に、システムツールをインストールし、設定ファイルを修正してきました。そして今、最も重要なLinuxインストールの最後の一片をインストールします。それがブートローダーです。
ブートローダーは、ブート中にLinuxカーネルを起動することに責任を負っています。ブートローダーがないと、システムは電源ボタンが押されたときに、どう事を進めればいいのかわからなくなってしまいます。
amd64 に対して私たちは、DOS/レガシー BIOS ベースのシステムについては GRUB または LILO を設定する方法を、UEFI システムについては GRUB または efibootmgr を設定する方法を文書化しています。
このセクションでは、ブートローダーパッケージの "emerge" と、ブートローダーのシステムへの "インストール" という表現を使っています。ここでいう "emerge" とは Portage を使ってソフトウェアパッケージがシステムで利用できるようにすることです。そして "インストール" はブートローダーが必要なファイルをコピーしたりディスク上の特定の領域に変更を加えることで、ブートローダーを有効化し次回起動時に使用可能な状態にすることを指します。
デフォルト: GRUB
デフォルトでは、大半の Gentoo システムが GRUB Legacy の後継である GRUB (sys-boot/grub パッケージで利用できます) を使用しています。GRUB は追加の設定なしに従来の BIOS ("pc") システムで使うことができ、それ以外のプラットフォームでもビルド前のわずかな設定で済みます。詳しくは、GRUB ページの前提条件節をご覧ください。
Emerge
MBR パーティションテーブルのみをサポートする従来の BIOS システムを使う場合、GRUBをインストールするのに追加の設定は必要ありません:
root #emerge --ask --verbose sys-boot/grubUEFI ユーザーの方へ: 上記のコマンドを実行すると、現在有効な GRUB_PLATFORMS 値が表示されます。UEFI 対応のシステムでは GRUB_PLATFORMS="efi-64" が有効になっていることを確認してください (これがデフォルトです) 。もし有効になっていなければ、GRUB パッケージを EFI の機能付きでビルドするために、 GRUB を emerge する前に /etc/portage/make.conf にGRUB_PLATFORMS="efi-64" を追加しなければなりません。
root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.confroot #emerge --ask sys-boot/grubなんらかの経緯で GRUB_PLATFORMS="efi-64" を有効にしていない状態で GRUB が emerge されてしまった場合は、この行を make.conf に追加して、 emerge に --update --newuse オプションを渡せば、 world パッケージセット の依存関係を再計算することができます:
root #emerge --ask --update --newuse --verbose sys-boot/grubこれで GRUB ソフトウェアがシステムにマージされましたが、二次ブートローダとしてのインストールはまだ完了していません。
インストール
つぎに、 grub-install コマンドを使って、必要な GRUB ファイルを /boot/grub/ ディレクトリにインストールします。もし（システムがブートする）一番目のディスクにインストールするなら、 /dev/sda ですので、以下のどちらかのコマンドでインストールすることができます:
DOS/レガシー BIOS システム
DOS/レガシー BIOS システムでは:
root #grub-install /dev/sdaUEFI システム
grub-install を実行する前に EFI システムパーティションがマウントされているか必ず確認してください。 grub-install が GRUB EFI ファイル (grubx64.efi) を間違ったディレクトリにインストールしてしまい、しかも間違ったディレクトリが使われた形跡をまったく残さないということが起こりえます。
UEFI システムでは:
root #grub-install --efi-directory=/efiInstalling for x86_64-efi platform. Installation finished. No error reported.
インストールに成功したら、出力は上のコマンドの出力と一致するはずです。出力が完全に一致していない場合は、GRUB をデバッグするへと進み、そうでない場合は設定の手順へと進んでください。
追加可能: セキュアブート
sys-boot/grub パッケージは secureboot USE フラグを認識しません。これは、GRUB EFI 実行可能形式はパッケージによってインストールされるのではなく、grub-install コマンドによってインストールされるからです。そのため GRUB は、ブートパーティションにインストールした後に手動で署名しなくてはなりません。また、GRUB はモジュール化されたブートローダですが、セキュアブートが有効化されているときにはモジュールのロードは禁止されています。そのため、必要なモジュールはすべて GRUB EFI 実行可能形式の中にコンパイルしなてくはなりません。いくつかの基本的なモジュールを含める例を以下に示します。より高度な構成のためには微調整する必要があるかもしれません:
root #emerge --noreplace sbsigntoolsroot #export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"root #grub-install --target=x86_64-efi --efi-directory=/efi --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csvroot #sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efiセキュアブートを有効化して正常にブートするためには、UEFI ファームウェアによって使用された証明書が受け入れられるか、shim をプリローダとして使用しなくてはなりません。shim はサードパーティの Microsoft の証明書によって署名済みで、ほとんどの UEFI マザーボードによってデフォルトで受け入れられます。
カスタム鍵を受け入れるように UEFI ファームウェアを設定する方法はファームウェアの製造元によって異なり、このハンドブックの対象外です。代わりに以下に shim をセットアップするための方法を示します:
root #emerge sys-boot/shim sys-boot/mokutil sys-boot/efibootmgrroot #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/GRUB/shimx64.efiroot #cp /usr/share/shim/mmx64.efi /efi/EFI/GRUB/mmx64.efiShims MOKlist は DER 形式の鍵を要求します。ここの例で生成された OpenSSL 鍵は PEM 形式なので、まず変換する必要があります:
root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DERここで使用されるパスは、生成された鍵に属する証明書を含む pem ファイルへのパスでなくてはなりません。この例では鍵と証明書は同じ pem ファイル内にあります。
そして、変換された証明書を Shims MOKlist にインポートしてください:
root #mokutil --import /path/to/kernel_key.der最後に、UEFI ファームウェアに Shim を登録します。次のコマンドでは、boot-disk と boot-partition-id はそれぞれ、EFI システムパーティションのディスクとパーティションの識別子で置き換えてください:
root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\GRUB\shimx64.efi' --label 'shim' --unicodeGRUB をデバッグする
GRUB をデバッグするとき、新しい live イメージ環境へと再起動することなくインストール済みのシステムをブート可能にできるかもしれない簡単な解決策がいくつか存在します。
出力の中のどこかに "EFI variables are not supported on this system" が表示されている場合は、おそらく live イメージが EFI モードでブートされておらず、現在レガシー BIOS ブートモードにある可能性が高いです。解決方法としては、以下で言及されている removable オプションを使う GRUB の手順を試してください。これは /EFI/BOOT/BOOTX64.EFI にある実行可能 EFI ファイルを上書きします。EFI モードで再起動できれば、マザーボードファームウェアはこのデフォルトブートエントリを実行し、GRUB を実行できるかもしれません。
grub-install が "Could not prepare Boot variable: Read-only file system" というエラーを返し、live 環境が正しく UEFI モードでブートされている場合は、efivars という特別なマウントを読み書き可能な状態で再マウントしたうえで先述の grub-install コマンドを再実行できるはずです:
root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivarsこれは特殊な EFI ファイルシステムをデフォルトではマウントしない、特定の非公式 Gentoo 環境によって引き起こされます。上のコマンドが実行できない場合は、公式 live イメージ環境を EFI モードで使用して再起動してください。
一部のマザーボードメーカの貧弱な UEFI 実装では、EFI システムパーティション (ESP) 内の .EFI ファイルの置き場所として /EFI/BOOT ディレクトリしかサポートしていないようです。GRUB のインストーラは、インストールコマンドに --removable オプションを付けることで、自動でこの場所に .EFI ファイルを作成することができます。ESP がマウントされていることを確認してから、以下のコマンドを実行してください; (以前に定義した通り) /efi にマウントされているとして、以下を実行してください:
root #grub-install --target=x86_64-efi --efi-directory=/efi --removableこのコマンドは UEFI 仕様で定義されている'デフォルトの'ディレクトリを作成し、デフォルトの名前 BOOTX64.EFI を持つファイルを作成します。
設定
次に、/etc/default/grub ファイルと /etc/grub.d スクリプトで指定されたユーザ固有の設定をもとに、GRUB 設定ファイルを生成します。GRUB はどのカーネルを起動するか（/boot/ 内で利用可能な最上位のもの）、どれがルートファイルシステムかを自動で検出してくれるので、ほとんどの場合、ユーザによる設定の必要はありません。カーネルパラメータは /etc/default/grub の GRUB_CMDLINE_LINUX 変数で指定することができます。
最終的な GRUB の設定ファイルを生成するには、 grub-mkconfig コマンドを実行します:
root #grub-mkconfig -o /boot/grub/grub.cfgGenerating grub.cfg ... Found linux image: /boot/vmlinuz-6.6.21-gentoo Found initrd image: /boot/initramfs-genkernel-amd64-6.6.21-gentoo done
このコマンドの出力を見て、ブートに必要な Linux イメージが見つかったという報告が少なくともひとつあることを確認してください。もし initramfs を使っているか genkernel でカーネルをビルドしている場合は、正しい initrd イメージが認識されていることも確認してください。もし確認できなかった場合、/boot/ にそれらのファイルが存在するかどうか ls コマンドで確かめてください。必要なファイルが存在していなければ、カーネルの設定とインストールをやり直さなければなりません。
接続されたドライブからほかのOSを検出するために、os-prober ユーティリティを使うこともできます。Windows 7、8.1、10、あるいはほかの Linux ディストリビューションが検出できるようになります。このようなデュアルブート環境を作るには、sys-boot/os-prober パッケージをインストールしてから grub-mkconfig コマンドを再実行するとよいでしょう。検出がうまくいかない時は、Gentoo コミュニティに助けを求める前に GRUB 記事をよく読み直してみてください。
代替案 1: LILO
Emerge
LILO (the LInuxLOader) は検証済みで、かつとても有用なLinuxのブートローダーです。しかしながら、GRUB と比べるといくつかの機能を欠いています。いくつかのシステムでは LILO は動作するものの GRUB は動作しないため、 LILO が今でも使われています。もちろん、 LILO をよく知っており使い続けたいと思っている人々もこれを使っています。どちらにしても、Gentoo は両方のブートローダーをサポートしています。
LILO のインストールは簡単です; emerge を使います。
root #emerge --ask sys-boot/lilo設定
LILO の設定をするにはまず、/etc/lilo.conf を作成します:
root #nano -w /etc/lilo.conf設定ファイルではブートできるカーネルを参照するためにセクションを使用しています。この設定ファイルで入力する必要があるので、カーネルファイル (カーネルバージョンも含む) や initramfs ファイルを確認しておいてください。
ルートファイルシステムが JFS の場合には読み書き可能なマウントの前にログをリプレイする必要があるため、
append="ro" という行を各ブート項目の後に書き加えてください。/etc/lilo.confLILO の設定例boot=/dev/sda # MBRにLILOをインストールする
prompt # ユーザに他のセクションを選択させる機会を与える
timeout=50 # デフォルトのセクションを起動する前に5秒間待つ
default=gentoo # タイムアウトに達した場合、"gentoo"セクションを起動する
compact # これは劇的にロード時間を減らし、マップファイルをより小さくし続ける。いくつかのシステムでは失敗する場合がある。
image=/boot/vmlinuz-6.6.21-gentoo
label=gentoo # このセクションの名前
read-only # ルートを読み込み専用で始める。変えないこと！
root=/dev/sda3 # ルートファイルシステムの場所
image=/boot/vmlinuz-6.6.21-gentoo
label=gentoo.rescue # このセクションの名前
read-only # ルートを読み込み専用で始める。変えないこと！
root=/dev/sda3 # ルートファイルシステムの場所
append="init=/bin/bb" # Gentooの静的レスキューシェルを起動する
# 次の2行はWindowsとのデュアルブートのための行です。
# この例では、Windowsは/dev/sda6に格納されているとします。
other=/dev/sda6
label=windows
異なるパーティション構成やカーネルイメージを使用している場合はそれに応じて調整してください。
initramfs が必要な場合、設定を変更してその initramfs ファイルを参照し、また initramfs に root デバイスの場所を渡すようにします:
/etc/lilo.confブートエントリーに initramfs の情報を加えるimage=/boot/vmlinuz-6.6.21-gentoo
label=gentoo
read-only
append="root=/dev/sda3"
initrd=/boot/initramfs-genkernel-amd64-6.6.21-gentoo
追加のオプションをカーネルに渡す必要がある場合には append 文を使います。たとえばフレームバッファーを有効化するために video 文を追加するには:
/etc/lilo.confブートオプションに video パラメータを追加するimage=/boot/vmlinuz-6.6.21-gentoo
label=gentoo
read-only
root=/dev/sda3
append="video=uvesafb:mtrr,ywrap,1024x768-32@85"
genkernel を使用したユーザーは、そのカーネルがインストール CD に使われたのと同じブートオプションを使用することを知っておいてください。たとえば SCSI デバイスのサポートを有効化する必要がある時は doscsi をカーネルオプションとして追加します。
それではファイルを保存して終了します。
インストール
仕上げに実行ファイル /sbin/lilo を起動して、LILO に /etc/lilo.conf の設定をシステムへ適用させます (つまり、自身をディスクにインストールさせます)。新しいカーネルをインストールしたりカーネルのファイル名が変更された際には、システムをブートさせるために lilo.conf ファイルに変更を加えるたびに /sbin/lilo を実行しなければならないことを覚えておいてください。
root #/sbin/lilo代替案 2: efibootmgr
UEFI ベースのファームウェアを搭載したコンピュータシステムは、カーネルをブートするために二次ブートローダ (GRUB 等) を厳密には必要としません。二次ブートローダはブートプロセス中の UEFI ファームウェアの機能を拡張するために存在しています。GRUB を使用する (以前の節を参照してください) ほうが、ブート時のカーネルパラメータを簡単に変更するためのより柔軟なアプローチを提供しているので、典型的にはより簡単で、より堅牢です。
システムのブートについて最小限かつ厳格なアプローチをとるシステム管理者は、二次ブートローダを使用せずに、EFI スタブとして Linux カーネルをブートすることができます。
sys-boot/efibootmgr アプリケーションは、システムの一次ブートローダである UEFI ファームウェアと通信するためのツールです。通常このツールは、ファームウェアのブート可能エントリの一覧にブートエントリを追加または削除するために使われます。また、既にブート可能エントリとして追加されている Linux カーネルを追加のオプションとともに実行できるように、ファームウェア設定を更新することもできます。これらの通信は EFI 変数と呼ばれる特別なデータ構造を通して行われます (したがって、EFI 変数のカーネルサポートが必要です)。
続ける前に EFI スタブカーネルの記事を必ず確認してださい。カーネルを UEFI ファームウェアから直接ブートできるようにするには、特有のオプションを有効化しなければなりません。このサポートを組み込むために、カーネルの再コンパイルが必要になる場合があります。
追加の情報を得るために efibootmgr の記事を見てみるのも良い考えです。
繰り返しますが、efibootmgr は UEFI システムのブートにおいて必須ではありません; 単に UEFI ファームウェアに EFI スタブカーネルのためのエントリを追加するためだけに必要なものです。EFI スタブのサポート付きで適切にビルドされた Linux カーネルは、それ自体直接ブートさせることができます。追加のカーネルコマンドラインオプションも Linux カーネルの中に組み込むことができます (CONFIG_CMDLINE というカーネルの設定オプションがあります)。同様に、initramfs のサポートもカーネルの中に'組み込む'ことができます。これらの決定はカーネルのコンパイルに先立って行わなくてはならず、結果としてブートの構成はより静的なものとなります。
efibootmgr ソフトウェアをインストールしてください:
root #emerge --ask sys-boot/efibootmgr/efi/EFI/Gentoo を作成して、カーネルをその中に bzImage.efi という名前でコピーしてください:
root #mkdir -p /efi/EFI/Gentoo
root #cp /boot/vmlinuz-* /efi/EFI/Gentoo/bzImage.efi
UEFI の定義には、ディレクトリパスの区切りにはバックスラッシュ (\) を用いなければなりません。
新しくコンパイルされた EFI スタブカーネルに対応する "gentoo" という名称のブートエントリを、UEFI ファームウェア内に作成してください:
root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\EFI\Gentoo\bzImage.efi"初期 RAM ファイルシステム (initramfs) を用いるときには、適切なブートオプションを加えてください:
root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\EFI\Gentoo\bzImage.efi" --unicode "initrd=\efi\initramfs-genkernel-amd64-6.6.21-gentoo"上のコマンドは、bzImage.efi ファイルと同じ ESP 内のディレクトリに initramfs ファイルがコピーされていることを前提としていることに注意してください。
これらの変更が完了したら、システムを再起動後から、"gentoo" という名称のブートエントリーが利用可能になります。
Unified カーネルイメージ
installkernel が unified カーネルイメージをビルドしてインストールするように構成されているなら、unified カーネルイメージはすでに EFI システムパーティション上の EFI/Linux ディレクトリにインストールされているはずです。もしそうなっていない場合は、ディレクトリが存在することを確認してから、ハンドブックで既に説明した通りにカーネルインストールを再度実行してください。
インストールされた unified カーネルイメージのためのブートエントリを直接追加するには:
root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader /efi/EFI/Linux/gentoo-x.y.z.efi代替案 3: Syslinux
Syslinux は amd64 アーキテクチャ用のもう一つの代替ブートローダーです。MBR をサポートしており、バージョン 6.00 からは EFI ブートもサポートしています。また、PXE (ネットワーク) ブートやあまり知られていないオプションもサポートします。Syslinux は多くの人々に人気のあるブートローダーですが、このハンドブックではサポートしていません。このブートローダーの emerge やインストールに関する情報は Syslinux の記事で得ることができます。
代替案 4: systemd-boot
別の選択肢として systemd-boot もあり、これは OpenRC と systemd のマシンの両方で動作します。これは薄いチェーンローダであり、セキュアブートと合わせてうまく動作します。
systemd-boot をインストールするには:
root #bootctl installbootctl install を実行する前に、EFI システムパーティションがマウントされていることを確認してください。
このブートローダを使用するときは、リブートする前に、以下を使用してブート可能なエントリが存在することを確認してください:
root #bootctl list新しいエントリが存在しない場合は、sys-kernel/installkernel パッケージが systemd-boot USE フラグを有効化した状態でインストールされていることを確認して、カーネルインストールを再実行してください。
ディストリビューションカーネルについては:
root #emerge --ask --config sys-kernel/gentoo-kernel手動で設定およびコンパイルされたカーネルについては:
root #make installsystemd-boot 向けにカーネルをインストールする場合、root= カーネルコマンドライン引数はデフォルトでは追加されません。initramfs を使用する systemd システム上で、ブート時にルートパーティションを自動的に見つけるためには、ユーザは代わりに systemd-gpt-auto-generator に頼ることができます。そうしない場合ユーザは、/etc/kernel/cmdline 内で、使用すべき他のカーネルコマンドライン引数と並んで root= を設定することで、手動でルートパーティションの場所を指定するべきです。その後、上記の通りにカーネルを再インストールしてください。
追加可能: セキュアブート
secureboot USE フラグが有効化されている場合、systemd-boot EFI 実行可能形式は自動的に署名されるでしょう。bootctl install は自動的に署名されたバージョンをインストールするでしょう。
セキュアブートを有効化して正常にブートするためには、UEFI ファームウェアによって使用された証明書が受け入れられるか、shim をプリローダとして使用しなくてはなりません。shim はサードパーティの Microsoft の証明書によって署名済みで、ほとんどの UEFI マザーボードによってデフォルトで受け入れられます。
カスタム鍵を受け入れるように UEFI ファームウェアを設定する方法はファームウェアの製造元によって異なり、このハンドブックの対象外です。代わりに、systemd-boot を自動的に更新して shim とともに構成するための postinst フックが systemd-boot wiki ページで提供されています。しかし、初回は以下の手順に従って、これを手動で行うべきです:
root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgrroot #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFIroot #cp /usr/share/shim/mmx64.efi /efi/EFI/BOOT/mmx64.efiroot #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efishim は grubx64.efi をロードするようにハードコードされています。そのため systemd-boot ブートローダには、あたかもそれが GRUB であるかのように名前を付けなくてはなりません。
Shims MOKlist は DER 形式の鍵を要求します。ここの例で生成された OpenSSL 鍵は PEM 形式なので、まず変換する必要があります:
root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DERここで使用されるパスは、生成された鍵に属する証明書を含む pem ファイルへのパスでなくてはなりません。この例では鍵と証明書は同じ pem ファイル内にあります。
そして、変換された証明書を Shims MOKlist にインポートしてください:
root #mokutil --import /path/to/kernel_key.der最後に、UEFI ファームウェアに Shim を登録します。次のコマンドでは、boot-disk と boot-partition-id はそれぞれ、EFI システムパーティションのディスクとパーティションの識別子で置き換えてください:
root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\BOOT\BOOTX64.EFI' --label 'shim' --unicode
システムのリブート
chroot環境を出て、全てのパーティションをアンマウントします。次に、最終かつ真のテストを実行するためのマジカルコマンドrebootを入力しましょう。
(chroot) livecd #exitlivecd~#cd
livecd~#umount -l /mnt/gentoo/dev{/shm,/pts,}
livecd~#umount -R /mnt/gentoo
livecd~#rebootlive イメージを取り出すのを忘れないでください。そうしないと新しくインストールされた Gentoo ではなく、live イメージが再度ブート対象になってしまうかもしれません！
リブートして新しい Gentoo 環境に入ることができたら、最終章のインストールの締めくくりに進むのがよいでしょう。