GRUB の設定を誤ってしまうと、CD-ROM や USB 起動ドライブのような他のデバイスからもブートできなくなってしまいます。 読者の LFS システムをブート可能とするためには、本節の内容は必ずしも必要ではありません。 読者が利用している現在のブートローダー、例えば Grub-Legacy, GRUB2 などの設定を修正することが必要かもしれません。
コンピューターが利用不能に (ブート不能に) なってしまうこともあります。 そんな事態に備えてコンピューターを「復旧
(resucue)」するブートディスクの生成を必ず行ってください。
ブートデバイスを用意していない場合は作成してください。 以降に示す手順を実施するために、必要に応じて BLFS ブックを参照し
libisoburn にある xorriso をインストールしてください。
cd /tmp grub-mkrescue --output=grub-img.iso xorriso -as cdrecord -v dev=/dev/cdrw blank=as_needed grub-img.iso
LFS にはセキュアブートをサポートする基本的なパッケージがありません。 本節の手順に従ってブートプロセスを設定する際には、ファームウェアの設定において Secure Boot は必ずオフに設定してください。 Secure Boot サポートの無効化に関する詳細手順は、利用しているシステムの製造者が提供するドキュメントを参照してください。
GRUB ではドライブやパーティションに対して (hdn,m) といった書式の命名法を採用しています。 n はハードドライブ番号、m はパーティション番号を表します。 ハードドライブ番号はゼロから数え始めます。
一方パーティション番号は、基本パーティションであれば1から(拡張パーティションは5から)数え始めます。
かつてのバージョンでは共にゼロから数え始めていましたが、今はそうではないので注意してください。 例えば sda1 は GRUB では (hd0,1) と表記され、sdb3 は (hd1,3) と表記されます。 Linux システムでの取り扱いとは違って
GRUB では CD-ROM ドライブをハードドライブとしては扱いません。 例えば CD が hdb であり、2番めのハードドライブが hdc であった場合、2番めのハードドライブは (hd1) と表記されます。
BIOS を経由してシステムをブートする場合、GRUB がハードディスクの最初のセクター (マスターブートレコード, MBR と呼ばれる) にスタブを書き込みます。 この領域はファイルシステムに属するものではありません。 BIOS は MBR の内容をロードして実行します。 そしてスタブが、BIOS ブートパーティションからメインの GRUB イメージをロードします。 GRUB イメージはファイルとしてではなく、生のデータとして保存されます (BIOS ブートパーティションにファイルシステムがあってはなりません)。 したがってスタブはファイルシステムを一切サポートする必要がなく、MBR に収まるように充分小さくすることができます。
UEFI を経由してシステムをブートする場合、GRUB はメインの GRUB イメージを PE-COFF
実行ファイルとして保存し機能します。 そしてその保存場所は EFI システムパーティション EFI/BOOT/BOOTX64.EFI (i386-efi の場合は EFI/BOOT/BOOTIA32.EFI) 内にある標準的な場所になります。 UEFI
ファームウェアはその標準的な場所から、その実行ファイルをロードして実行し GRUB を起動します。
GRUB 関数 (Linux カーネルのブートを行うものを含む) の多くは、メインの GRUB イメージの中にはありません。 それは
GRUB モジュールとしてファイルシステム内に保存されています。 そのファイルシステムは、たいていの Linux
ディストリビューションでは、/boot/grub にマウントされ GRUB
モジュールにアクセスできます。
このことが「にわとりが先かタマゴが先か」の問題とならないように、このファイルシステムへのアクセスに必要となるモジュールを
grub-install がメインの
GRUB イメージの中に埋め込みます。 これにより他のモジュールをロードすることができるようになります。
ブートパーティションをどこにするかは各人に委ねられていて、それによって設定方法が変わります。
推奨される1つの手順としては、ブートパーティションとして独立した小さな (200MB 程度のサイズの)
パーティションを設けることです。 こうしておくと、この後に LFS
であろうが商用ディストリビューションであろうが、同一のブートファイルを別のブートシステムに対しても利用できます。
この方法をとるなら、新たなパーティションをマウントした上で、現在 /boot ディレクトリにある全ファイルを (例えば前節にてビルドした Linux カーネルも)
新しいパーティションに移動させる必要があります。 そしていったんパーティションをアンマウントし、再度 /boot としてマウントしなおすことになります。 これを行った後は/etc/fstab を適切に書き換えてください。
ホストディストロが /boot
に対して個別のパーティションを用いていて、かつ LFS も /boot
に対してそのパーティションを利用したいのであれば、そのパーティションをホストディストロの $LFS/boot にマウントしてください。 Linux
カーネルでは、複数のマウントポイントに対して 1 つのパーティションをマウントする機能がサポートされています。
現時点での LFS パーティションにて /boot
を残しておいても問題なく動作します。 ただし複数システムを取り扱うための設定は、より複雑になります。
ブートパーティションのレイアウトに関する具体的な話については、「新しいパーティションの生成」 に分かり易いかもしれません。
ここまでの情報に基づいて、ルートパーティションの名称を (あるいはブートパーティションを別パーティションとするならそれも含めて)
決定します。 以下では例として、ルートパーティション (あるいは別立てのブートパーティション) が sda2 であるとします。
これ以降の節では BIOS または UEFI を使ったブート方法について説明していきます。 BIOS、64 ビット UEFI、32 ビット UEFI のそれぞれに対する GRUB インストールは共存が可能であり、同一の設定を共有することができます。 GRUB イメージやデータは、それぞれに異なる場所に配置されるため、BIOS ブートパーティションと EFI システムパーティションを同時に生成しておくこともでき、サポートされるファームウェアのタイプすべてに対して GRUB をインストールすることができます (grub-install を 3 回実行することになります)。 利用しているファームウェアタイプが何かがよく分からない場合、またはハードディスクを別コンピューターに移転しようとしている場合は、共存させるという手法が必要になるかもしれません。
UEFI ブートを行おうとしているのに Grub ブートパーティションを生成してしまった場合、UEFI ブートが思うように動かないかもしれないことから、BIOS 向けコマンドを実行しておくのが良いでしょう。
GRUB によるブートはただ一つの方法だけ実現すれば十分であるなら、複数に対処するために複数回コマンドを実行する必要はありません。 必要としているブート向けのコマンドだけを実行すれば十分です。
BIOS を使ったブートでは、ブートパーティションがマウントされていて (個別のパーティションを用意している場合)、BIOS
ブートパーティションが存在していることを確認してください。 GRUB ファイル類を /boot/grub にインストールしたら、ブートトラックを設定します。
以下のコマンドを実行すると、それまでのブートローダーを上書きします。 これを避けたい場合はコマンドを実行しないでください。 たとえば MBR の管理を行うサードパーティー製のブートマネージャーを利用している場合などです。
grub-install /dev/sda --target=i386-pc
UEFI を使ったブートでは、ブートパーティションがマウントされていて (個別のパーティションを用意している場合)、EFI
システムパーティションが /boot/efi
にマウントされていることを確認してください。 その上で GRUB ファイル類を /boot/grub に、またメインの GRUB イメージを /boot/efi/EFI/BOOT/BOOTX64.EFI にインストールします。
以下のコマンドは /boot/efi/EFI/BOOT/BOOTX64.EFI ファイルを上書きします。
すでにこのファイルが存在していたとしたら、それは別のブートローダー (たとえばホストディストロからの GRUB
インストール、あるいは Windows ブートマネージャー) によって導入されているものかもしれません。
後々の復元のことを考慮して、あるいは新たな GRUB インストールによって構成される 2 つめのブートローダー用として
(「chainloading」と呼ばれる GRUB 機能として)
ロードできるように、このファイルのバックアップを取っておいてください。
grub-install --target=x86_64-efi --removable
上のコマンドは、64 ビット UEFI ファームウェアを利用している場合のものです。 32 ビット UEFI
ファームウェア用としてシステムブートを行いたい場合は、x86_64-efi の部分を i386-efi に置き換えてコマンド実行してください。
--removable オプションは
grub-install
が標準的なインストール場所 EFI/BOOT/BOOTX64.EFI
(i386-efi の場合は EFI/BOOT/BOOTIA32.EFI) を用いるように指定するものです。
これを指定しなかった場合 GRUB は EFI/GRUB/GRUBX64.EFI または EFI/GRUB/GRUBIA32.EFI をインストール先とします。
標準的ではない場所を用いたとしても、EFI 変数が指定されていれば、その場所に正しくインストールされます。 しかし LFS では
BLFS パッケージ
efibootmgr が導入されていません。 これがないと GRUB がその位置を EFI
変数に保存しておくことができません。
特定の条件のもとでは、標準的なパスがうまく動作しないことがあります。
UEFI ファームウェアの中には標準的な EFI パスを完全に無視する実装が存在しています。
「有名な」ブートローダー (特に Windows ブートマネージャー) が同一の EPS 内にある場合、UEFI ファームウェアによっては、標準的なパス上にはないブートローダーを代わりに起動するものがあります。
マルチブートの設定において、一方のオペレーティングシステムが、標準の EFI パス上にあるファイルを (特にシステムアップデートの際に) 上書きすることがあります。 これが起きると、LFS の grub インストールに支障が起きる可能性があります。
上のような状況の場合、UEFI 向けのブートエントリを生成するために、BLFS パッケージである efibootmgr をインストールすることが必要になるかもしれません。 その場合は、はじめにそのパッケージをインストールします。 そしてファイルシステムのマウントをまだ行っていないのであれば、EFI 変数を使ってファイルシステムをマウントします。
mountpoint /sys/firmware/efi/efivars || mount -v -t efivarfs efivarfs /sys/firmware/efi/efivars
LFS 固有のディレクトリに GRUB をインストール、EFI 向けに「LFS」と命名したエントリを追加します。
efibootmgr -B -LLFSgrub-install --target=x86_64-efi --bootloader-id=LFS
efibootmgr -B
コマンドを実行すると、前回の LFS インストール (それが存在する場合) におけるブートエントリを削除します。 複数の
LFS システムを同一マシン上にインストールしている場合は、LFS の部分を適切に書き換えてください。
そうしてブートローダーを個々に維持するようにしてください。
(不具合のある) ファームウェアでは efibootmgr
-c コマンドの直接実行を必要とするものがあります。 そういったファームウェアの実装においては
grub-install
からは受け渡されないパラメーターを追加で指定する必要があるためです。 そのパラメーターとはたとえば --full-dev-path や -e 1 -E といったものです。 efibootmgr -c コマンドの実行方法については
man ページ efibootmgr(8)
を参照してください。 grub-install コマンドから呼び出される
efibootmgr -c
コマンドがどのようなものかは、--debug |&
efibootmgr を追加すれば分かります。 これを行えば編集に役立ちます。 編集した
efibootmgr -c
コマンドを実行するにあたっては、事前に efibootmgr
-B コマンドを実行して、grub が生成したエントリを削除しておくことを忘れないでください。
そして EFI 変数をアンマウントします。 これはこれ以降、ブート処理には不要です。 ファイルシステムは EFI 変数の操作に対してのみ用いられるからです。
umount -v /sys/firmware/efi/efivars
/boot/grub/grub.cfg ファイルを生成します。
cat > /boot/grub/grub.cfg << "EOF"
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
insmod part_gpt
insmod ext2
set root=(hd0,2)
set gfxpayload=1024x768x32
menuentry "GNU/Linux, Linux 7.2.10-lfs-r13.1-28" {
linux /boot/vmlinuz-7.2.10-lfs-r13.1-28 root=/dev/sda2 ro
}
EOF
insmod コマンドは
GRUB モジュールである part_gpt、ext2
をロードします。 そしてその名前こそ ext2
となっていますが、このモジュールは実際には ext2,
ext3, ext4 の各ファイルシステムをサポートしています。 通常の設定では part_gpt と ext2
の各モジュールが、grub-install
によって GRUB のメインイメージに埋め込まれています。 したがってこれらのモジュールを insmod に対して用いても何も起きません。
これは問題を引き起こすものではなく、特殊な設定を行った際には必要となるかもしれません。
set gfxpayload=1024x768x32 コマンドは VESA フレームバッファーの解像度と色の深さを設定するものであり、これがカーネルに受け渡されます。 VESA フレームバッファー向けにカーネルの SimpleDRM ドライバーを用いる場合にこの指定が必要になります。 モニター画面に最適な解像度や色深さを選んでください。 その指定行は、システムが UEFI 経由のブート時には何も行わず、書かれていても何も問題はありません。
GRUB にとってカーネルファイル群は、配置されるパーティションからの相対位置となります。 したがって /boot パーティションを別に作成している場合は、上記の linux の行から /boot の記述を取り除いてください。 また set root 行でのブートパーティションの指定も、正しく設定する必要があります。
GRUB のパーティション指示子は、(USB
サムデバイスといったリムーバルディスクを含め)ディスクの加除によって変わることがあります。
その加除が原因で起動に失敗することがありますが、それは grub.cfg において「古い」指示子を用いているからです。
こういった問題を避けようとおもったら、パーティション指定にあたって GRUB 指定子を用いずに、パーティションやファイルシステムの
UUID を用いることが考えられます。 lsblk -o
UUID,PARTUUID,PATH,MOUNTPOINT を実行してください。
ファイルシステムの UUID が UUID 列に示されます。
またパーティションは PARTUUID 列に示されます。 そうしたら
set root=(hdx,y) の記述を search --set=root --fs-uuid に書き換え、同様に <カーネルがインストールされているファイルシステムの
UUID>root=/dev/sda2 を root=PARTUUID= に書き換えます。
<LFS
がビルドされたパーティションの UUID>
パーティションの UUID と、そのパーティション内のファイルシステムの UUID は全く異なります。
オンラインから得られる情報において、root=PARTUUID= ではなく
<パーティション UUID>root=UUID=
を用いるように説明している場合があります。 これを行うには initramfs が必要であり、これは LFS
の範囲を超えるものです。
<ファイルシステム UUID>
/dev
内のパーティションに対するデバイスノード名も変わります(複数の NVME
ディスクを有するシステムでは頻繁に発生することがあります)。 /etc/fstab において記述するデバイスノードへのパスは、たとえば
/dev/sda1 を PARTUUID= に置き換えることができます。
これによりデバイスノード名が変更になった場合の、潜在的な起動エラーを回避することができます。
<パーティション
UUID>
GRUB は大変強力なプログラムであり、ブート処理に際しての非常に多くのオプションを提供しています。 これにより、各種デバイス、オペレーティングシステム、パーティションタイプに幅広く対応しています。 さらにカスタマイズのためのオプションも多く提供されていて、グラフィカルなスプラッシュ画面、サウンド、マウス入力などについてカスタマイズが可能です。 オプションの細かな説明は、ここでの手順説明の範囲を超えるため割愛します。
grub-mkconfig というコマンドは、設定ファイルを自動的に生成するものです。 このコマンドは /etc/grub.d/ にある一連のスクリプトを利用しており、それまでに設定していた内容は失われることになります。 その一連のスクリプトは、ソースコードを提供しない Linux ディストリビューションにて用いられるのが主であるため、LFS では推奨されません。 商用 Linux ディストリビューションをインストールする場合には、それらのスクリプトを実行する、ちょうど良い機会となるはずです。 こういった状況ですから、grub.cfg のバックアップは忘れずに行うようにしてください。