10.4. GRUB を用いたブートプロセスの設定

10.4.1. はじめに

警告

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

10.4.2. セキュアブートの無効化

LFS にはセキュアブートをサポートする基本的なパッケージがありません。本節の手順に従ってブートプロセスを設定する際には、ファームウェアの設定において Secure Boot は必ずオフに設定してください。 Secure Boot サポートの無効化に関する詳細手順は、利用しているシステムの製造者が提供するドキュメントを参照してください。

10.4.3. GRUB の命名規則

GRUB ではドライブやパーティションに対して (hdn,m) といった書式の命名法を採用しています。 n はハードドライブ番号、m はパーティション番号を表します。ハードドライブ番号はゼロから数え始めます。一方パーティション番号は、基本パーティションであれば１から（拡張パーティションは５から）数え始めます。かつてのバージョンでは共にゼロから数え始めていましたが、今はそうではないので注意してください。例えば sda1 は GRUB では (hd0,1) と表記され、sdb3 は (hd1,3) と表記されます。 Linux システムでの取り扱いとは違って GRUB では CD-ROM ドライブをハードドライブとしては扱いません。例えば CD が hdb であり、２番めのハードドライブが hdc であった場合、２番めのハードドライブは (hd1) と表記されます。

10.4.4. 設定作業

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 カーネルでは、複数のマウントポイントに対してパーティションをマウントする機能がサポートされています。

現時点での LFS パーティションにて /boot を残しておいても問題なく動作します。ただし複数システムを取り扱うための設定は、より複雑になります。

ブートパーティションのレイアウトに関する具体的な話については、「新しいパーティションの生成」に分かり易いかもしれません。

ここまでの情報に基づいて、ルートパーティションの名称を (あるいはブートパーティションを別パーティションとするならそれも含めて) 決定します。以下では例として、ルートパーティション (あるいは別立てのブートパーティション) が sda2 であるとします。

これ以降の節では BIOS または UEFI を使ったブート方法について説明していきます。 BIOS、64 ビット UEFI、32 ビット UEFI のそれぞれに対する GRUB インストールは共存が可能であり、同一の設定を共有することができます。 GRUB イメージやデータは、それぞれに異なる場所に配置されるため、BIOS ブートパーティションと EFI システムパーティションを同時に生成しておくこともでき、サポートされるファームウェアのタイプすべてに対して GRUB をインストールすることができます (grub-install を 3 回実行することになります)。利用しているファームウェアタイプが何かがよく分からない場合、またはハードディスクを別コンピューターに移転しようとしている場合は、共存させるという手法が必要になるかもしれません。

注記

UEFI ブートを行おうとしているのに Grub ブートパーティションを生成してしまった場合、UEFI ブートが思うように動かないかもしれないことから、BIOS 向けコマンドを実行しておくのが良いでしょう。

注記

GRUB によるブートはただ一つの方法だけ実現すれば十分であるなら、複数に対処するために複数回コマンドを実行する必要はありません。必要としているブート向けのコマンドだけを実行すれば十分です。

10.4.4.1. BIOS を使ったブート

BIOS を使ったブートでは、ブートパーティションがマウントされていて (個別のパーティションを用意している場合)、BIOS ブートパーティションが存在していることを確認してください。 GRUB ファイル類を /boot/grub にインストールしたら、ブートトラックを設定します。

警告

以下のコマンドを実行すると、それまでのブートローダーを上書きします。これを避けたい場合はコマンドを実行しないでください。たとえば MBR の管理を行うサードパーティー製のブートマネージャーを利用している場合などです。

grub-install /dev/sda --target=i386-pc

10.4.4.2. UEFI を使ったブート

UEFI を使ったブートでは、ブートパーティションがマウントされていて (個別のパーティションを用意している場合)、EFI システムパーティションが /boot/efi にマウントされていることを確認してください。その上で GRUB ファイル類を /boot/grub に、またメインの GRUB イメージを /boot/efi/EFI/BOOT/BOOTX64.EFI にインストールします。

警告

以下のコマンドは /boot/efi/EFI/BOOT/BOOTX64.EFI ファイルを上書きします。すでにこのファイルが存在していたとしたら、それは別のブートローダー (たとえばホストディストロからの GRUB インストール、あるいは Windows ブートマネージャー) によって導入されているものかもしれません。後々の復元のことを考慮して、あるいは新たな GRUB インストールによって構成される 2 つめのブートローダー用としてロードできるように、このファイルのバックアップを取っておいてください。

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 が導入されていません。これがないと EFI 変数を取り扱うことはできません。

注記

UEFI ブートローダーの中には、極めてまれな例として、ハードコーディングされた EFI パスを無視するものがあります。そのようなシステムというのは、Lenovo ThinkPads とか HP デスクトップ/ノートパソコンに見られる、かなり古いものです。ブートエントリが BIOS 内にない場合、BLFS パッケージ efibootmgr をインストールして UEFI 向けのブートエントリを生成しないといけないかもしれません。簡易な方法として、ホストディストリビューションのパッケージマネージャーがそのパッケージに対応していて、それをインストールし、LFS システム上ではなくホストシステム上にて利用するということも考えられます。これが可能であれば、LFS システムに別パッケージを導入しなくても済みます。

はじめにそのパッケージをインストールします。そしてファイルシステムのマウントをまだ行っていないのであれば、EFI 変数を使ってファイルシステムをマウントします。

mountpoint /sys/firmware/efi/efivars ||
  mount -v -t efivarfs efivarfs /sys/firmware/efi/efivars

そして EFI 向けのブートエントリを生成します。

efibootmgr -c -d /dev/sd<x> \
  -p <y> -L "LFS" -l '\EFI\BOOT\BOOT<X64>.EFI'

/dev/sd<x> の部分は LFS をインストールしている場所となるよう適切に記述してください。またパーティション番号 <y> は、ESP をマウントしている番号に合わせてください。 ESP を /dev/sda2 にしている場合、パーティション番号は 2 となります。 32 ビット UEFI の設定時は <X64> の部分を IA32 に置き換えてください。

(不具合のある) ファームウェアでは efibootmgr に対してさらなるパラメーターが必要になる場合があります。たとえば --full-dev-path や -e 1 -E といったものです。詳しくは man ページ efibootmgr(8) を参照してください。

そして EFI 変数をアンマウントします。これはこれ以降、ブート処理には不要です。ファイルシステムは EFI 変数の操作に対してのみ用いられるからです。

umount -v /sys/firmware/efi/efivars

10.4.5. GRUB 設定ファイルの生成

/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)

# For UEFI
insmod efi_gop
insmod efi_uga

set gfxpayload=1024x768x32

menuentry "GNU/Linux, Linux 6.19.12-lfs-r13.0-67" {
        linux   /boot/vmlinuz-6.19.12-lfs-r13.0-67 root=/dev/sda2 ro
}
EOF

insmod コマンドは GRUB モジュールである part_gpt、ext2、efi_gop、efi_uga をロードします。そしてその名前こそ ext2 となっていますが、このモジュールは実際には ext2, ext3, ext4 の各ファイルシステムをサポートしています。 UEFI システムでは efi_gop と efi_uga がビデオ機能をサポートします。具体的には GOP (Graphics Output Protocol) を用いるのが最新式であり、UGA (UGA Draw Protocol) を用いるのがレガシーな方式です。通常の設定では 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=<ファイルシステム UUID> を用いるように説明している場合があります。これを行うには initramfs が必要であり、これは LFS の範囲を超えるものです。

/dev 内のパーティションに対するデバイスノード名も変わります（複数の NVME ディスクを有するシステムでは頻繁に発生することがあります）。 /etc/fstab において記述するデバイスノードへのパスは、たとえば /dev/sda1 を PARTUUID=<パーティション UUID> に置き換えることができます。これによりデバイスノード名が変更になった場合の、潜在的な起動エラーを回避することができます。

GRUB は大変強力なプログラムであり、ブート処理に際しての非常に多くのオプションを提供しています。これにより、各種デバイス、オペレーティングシステム、パーティションタイプに幅広く対応しています。さらにカスタマイズのためのオプションも多く提供されていて、グラフィカルなスプラッシュ画面、サウンド、マウス入力などについてカスタマイズが可能です。オプションの細かな説明は、ここでの手順説明の範囲を超えるため割愛します。

注意

grub-mkconfig というコマンドは、設定ファイルを自動的に生成するものです。このコマンドは /etc/grub.d/ にある一連のスクリプトを利用しており、それまでに設定していた内容は失われることになります。その一連のスクリプトは、ソースコードを提供しない Linux ディストリビューションにて用いられるのが主であるため、LFS では推奨されません。商用 Linux ディストリビューションをインストールする場合には、それらのスクリプトを実行する、ちょうど良い機会となるはずです。こういった状況ですから、grub.cfg のバックアップは忘れずに行うようにしてください。

Linux From Scratch - Version r13.0-67

第10章 LFS システムのブート設定