GRUB
GRUB 2(GRand Unified Bootloader version 2)は、GRUB2 とも表記され、一般的には GRUB とも呼ばれ、多くのシステムアーキテクチャ上で、様々なファイルシステムからカーネルをロードすることができる、マルチブート 2 次ブートローダです。GRUB は PC BIOS、PC EFI、IEEE 1275 (Open Firmware)、SPARC、MIPS Lemote Yeeloong をサポートしています。
GRUB はオリジナルの GRUB Legacy ブートローダとは全く新しく作られており、シェルライクな構文を利用することで高度なスクリプトの作成が可能なのが特徴としており、オリジナルを置き換えるものです。
クイックセットアップアプローチが必要なら、GRUB2 Quick Startを参照してください。
システムを GRUB レガシーから GRUB2 に移行する方法については、GRUB2 Migration を見てください。
インストール
Gentoo では GRUB Legacy (grub-0.97) と GRUB2 はスロット化されているので、両バージョンの GRUB を同じシステムに同時にインストールすることができますが、ハードディスク上のマスターブートレコード(MBR)にはどちらか1つのバージョンのGRUBのみをインストールすることができます。
GRUB2 は Legacy の機能をすべてサポートしているので、すべてのシステムは GRUB2 にアップグレードすることが推奨されます。Legacy は Gentoo ebuild リポジトリから削除されました。
前提条件
GRUB をどのプラットフォームにインストールするかコントロールするには、 make.conf において GRUB_PLATFORMS 変数をセットしてください。 amd64 アーキテクチャは多くのシステムで動作するプロファイルのデフォルト値を含んでいます。
/etc/portage/make.conf
EMU, EFIとPCをサポートするGRUB_PLATFORMS変数の設定例GRUB_PLATFORMS="emu efi-32 efi-64 pc"
ターゲットのCPU毎に、次のプラットフォームがサポートされています:
Target | |||||||
---|---|---|---|---|---|---|---|
Platform | i386 | ia64 | mips | mipsel | powerpc | sparc64 | x86_64 |
ARC | No | No | No | Yes | No | No | No |
Coreboot | Yes | No | No | No | No | No | 32-bit |
EFI | Yes | Yes | No | No | No | No | Yes |
EMU | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
IEEE 1275 (Open Firmware) | Yes | No | No | No | Yes | Yes | 32-bit |
Loongson | No | No | No | Yes | No | No | No |
Multiboot | Yes | No | No | No | No | No | 32-bit |
QEMU | Yes | No | No | No | No | No | 32-bit |
QEMU-MIPS | No | No | Yes | No | No | No | No |
PC | Yes | No | No | No | No | No | 32-bit |
いかなる場合でも環境変数GRUB_PLATFORMSの値が変更された際には、変更されたバイナリをビルドするためGRUBを必ず再emergeする必要があります。以下のemerge sectionで示したとおり、必ず
--newuse --deep
オプションを使用してください。amd64プロファイルでは、(U)EFIサポートが既定で有効になっています。BIOSベースのシステムを使っている場合、余計な依存ファイルのインストールを避けるため、環境変数GRUB_PLATFORMSにはpc
を指定して下さい。
USE フラグ
USE flags for sys-boot/grub GNU GRUB boot loader
device-mapper
|
Enable support for device-mapper from sys-fs/lvm2 |
doc
|
Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally |
efiemu
|
Build and install the efiemu runtimes |
fonts
|
Build and install fonts for the gfxterm module |
libzfs
|
Enable support for sys-fs/zfs |
mount
|
Build and install the grub-mount utility |
nls
|
Add Native Language Support (using gettextGNU locale utilities) |
sdl
|
Add support for Simple Direct Layer (media library) |
test
|
Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) |
themes
|
Build and install GRUB themes (starfield) |
truetype
|
Build and install grub-mkfont conversion utility |
Emerge
通常の emerge シンタックスを用いてGRUBをインストールします。
root #
emerge --ask --newuse --deep sys-boot/grub
追加のソフトウェア
必要なら、os-prober ユーティリティ(sys-boot/os-prober で提供されます)をインストールして、grub-mkconfig コマンドを実行した際にGRUBが他のオペレーティングシステムを探索してブートエントリを生成するようにしてください。たいていの場合、これでGRUBが自動で他のオペレーティングシステム(Windows 7, Windows 8.1, 10や他のLinuxディストリビューションなど)を検出できるようになります。
root #
emerge --ask --newuse sys-boot/os-prober
GRUB(と、場合によってはsys-boot/os-prober)をインストールしても、ブートローダの機能は自動では有効化されません。これらは、オペレーティングシステムにブートローダソフトウェアをインストールするだけです。(システムのブート時にそれが使われるようにするために)システムそのものにブートローダをインストールするには、追加のステップが必要になります。これについては設定セクションで解説します。
設定
GRUB の設定には2つの重要な作業があります:
- GRUB のソフトウェアを、システムのセカンダリブートローダーとしてインストール
- GRUB ブートローダー自体の設定
GRUBソフトウェアのインストールはシステムのタイプによってそれぞれ異なり、ブートローダーのインストールで解説します。まず、ブートローダそのものの設定について解説します。
メインの設定ファイル
grubの設定を生成するために、grub-mkconfig スクリプトを使います。これは /etc/grub.d/* 以下のスクリプト及び /etc/default/grub 設定ファイルを用い、最終的な /boot/grub/grub.cfg を――GRUB自体が使用する唯一の設定ファイルを――生成します。
ファイル | フォーマット | 編集すべきか? | |
---|---|---|---|
/usr/sbin/grub-mkconfig | POSIX シェルスクリプト | No | sys-boot/grub:2 パッケージの一部としてインストールされます。 下に説明されるファイルを設定した後、このスクリプトを実行して /boot/grub/grub.cfg を生成します。 |
/boot/grub/grub.cfg | GRUB シェルスクリプト | No | grub-mkconfig が生成するファイルです。このファイルはGRUBのビルトインスクリプトインタプリタによって評価されるもので、必ずしもすべてのPOSIXコマンドやシンタックスをサポートするものではありません。サポートされる機能については、GRUBマニュアルの scripting reference を参照してください。このファイルに対する変更は、次回 grub-mkconfig が実行されたとき保持されないことに注意してください。 |
/etc/grub.d/* | POSIX シェルスクリプト | Maybe | /etc/grub.d/* 以下の、実行可能属性がセットされたスクリプトは順番に評価され、標準出力が結合されて最終的な /boot/grub/grub.cfg(もしくは grub-mkconfig -o オプションで指定された何らかのファイル)を形成します。これらのスクリプトはその時のシステムのシェルを使うので、あらゆるサポートされたシンタックスを使うことができます。理想的にはPOSIX互換のスクリプトであるべきであり、また、出力されるスクリプトはGRUBのインタプリタと互換性のあるものでなければなりません。スクリプトを無効にしたり追加したりすることが必要かもしれません。例えば、自動では生成できないようなメニュー項目を追加したい時など。
|
/boot/grub/custom.cfg | GRUB shell script | Maybe | このファイルが存在する場合、/etc/grub.d/41_custom のスクリプトがこのファイルを参照して起動時に読み込まれます。このファイルは新たなメニュー項目やコマンドを追加するために提供されており、grub.cfgを再生成する必要がありません。 |
/etc/default/grub | POSIX シェルスクリプト | Yes | ほとんどの場合、直接変更されるべきファイルはこのファイルただ一つです。これは主に、 /etc/grub.d のスクリプトで用いられる変数を設定して、使える設定ファイルを生成するために利用されます。サポートされる変数については、GRUB configuration variables もしくは official reference を参照してください。 |
GRUBは、(GRUB Legacy や LILO のような)管理者によるブートオプション設定の手動での維持を必要としません。その代わりに、grub-mkconfig コマンドを用いて、設定ファイル(/boot/grub/grub.cfg)を生成することができます。このユーティリティは /etc/grub.d/ にあるスクリプトと /etc/default/grub の設定を使用します。
ソフトウェアRAIDを使用しているとき、grub-mkconfig ユーティリティは正しく動作しません。/etc/grub.d/ にあるスクリプトの手動設定が必要になり、そうしなければ、インストール後にシステムはブート不能な状態におかれることになるでしょう。
何らかの設定を変更したら、grub-mkconfig ユーティリティを /boot/grub/grub.cfgにある出力ファイル(これはGRUBのデフォルトの出力場所です)を指定した -o
オプション付きで実行します:
root #
grub-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.3.0-gentoo done
grub-mkconfig ユーティリティが呼ばれるたびに、新しい設定が生成されます。
もし grub-mkconfig が見つかった項目を報告してこない場合、それはひとつも項目が見つかっていないということです。この場合、GRUBはシステムの再起動のあとブートオプションをひとつも提供してくれないことになり、解決に時間のかかるトリッキーな状況になるかもしれません。システムを再起動する前に、出力が申し分ないかどうか確かめてください。
設定パラメータのセット
/etc/default/grub にある次の変数はGRUBがどのように機能するかをコントロールするために設定される最も一般的なものです:
変数 | 説明 | デフォルト値 |
---|---|---|
GRUB_DEFAULT | ブート時に最初に選択される項目を定義する変数です。番号の数字かメニュータイトル、あるいは"saved"を設定します。 | 最初に検出された項目がデフォルトになります。 |
GRUB_TIMEOUT | デフォルトのメニュー項目をブートする前の遅延を秒で指定します。0 に設定すると瞬時にブートし、-1 にすると無期限に待ちつづけます。
|
デフォルトは5秒です。 |
GRUB_CMDLINE_LINUX | すべてのLinuxメニュー項目のカーネルコマンドラインに与える引数を設定します。例えば、ハイバーネーションをサポートするためには、swapパーティションが /dev/sdXY なら、 GRUB_CMDLINE_LINUX="resume=/dev/sdXY" を追加する必要があります。
|
|
GRUB_CMDLINE_LINUX_DEFAULT | リカバリ以外のLinuxメニュー項目のカーネルコマンドラインに与える引数を設定します。 | |
GRUB_DEVICE | 初期ルートデバイス(つまり、カーネルの root= 引数)を設定します。これを設定すると、 grub-mkconfig コマンドの自動検知したルートデバイスがオーバーライドされます。例えば、 GRUB_DEVICE=/dev/ram0 と設定すると、カーネルコマンドラインで強制的に root=/dev/ram0 が使われるようになります。
|
より完全なリストについては、configuration variablesサブページとgrub-mkconfigのinfoページを参照してください。
パラメータを変更したら、grub-mkconfig でGRUBの設定ファイルを再生成してください。
設定スクリプトの有効化と無効化
/etc/grub.d/ ディレクトリには、 grub-mkconfig が grub.cfg ファイルの生成に用いるスクリプトが含まれます。デフォルトでは、このディレクトリの中身は次のようなものであるはずです:
user $
ls /etc/grub.d/
00_header 10_linux 20_linux_xen 30_os-prober 40_custom 41_custom README
GRUBは、インストールされたスクリプトのうち、実行可能に設定されたすべてのスクリプト(デフォルトでは全部がそうです)を利用します。いずれかのスクリプトを無効にするには、 chmod コマンドを用い、単にスクリプトのファイルパーミッションから実行可能ビットを取り除いてください。次の例では、 00_header と 10_linux を除く全てのスクリプトを無効にします。
root #
chmod -x /etc/grub.d/{20_linux_xen,30_os-prober,40_custom,41_custom}
スクリプトを変更したり、実行可能ビットを取り除いたりした後は、 grub-mkconfig を用いて設定ファイルを再生成してください。
設定スクリプトに手を加える
いくつかの機能は、設定スクリプトの書き換えによってのみ利用することができます。例えば、FreeBSDとのデュアルブートをサポートするには次の操作が必要です。
/etc/grub.d/40_custom スクリプトを以下のように変更します:
/etc/grub.d/40_custom
デュアルブートの追加menuentry "FreeBSD" --class freebsd --class bsd --class os { insmod ufs2 insmod bsd set root=(hd0,1) kfreebsd /boot/kernel/kernel kfreebsd_loadenv /boot/device.hints set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0s1a set kFreeBSD.vfs.root.mountfrom.options=rw set kFreeBSD.hw.psm.synaptics_support=1 }
/dev/sda1 もしくは (hd0,1)
が、FreeBSDが置かれているパーティションです。FreeBSDパーティションに通常のUFSインストールが行われたなら、/dev/sda1 はコンテナになっています(論理パーティションのようなものです)。これはswapとルートパーティションからなります。ls -la /etc/grub.d/40_custom を実行し、40_custom が実行可能であることを確認してください。もし実行可能ビットがセットされていない場合は、chmod u+x 40_custom コマンドでセットしてください。
GRUB レガシーに慣れてきたユーザは、GRUB では、パーティション番号は 0 からではなく 1 から始まっていることに注意してください。
次に、GRUBをインストールし、設定ファイルを更新してください。
root #
grub-install /dev/sda
root #
grub-mkconfig -o /boot/grub/grub.cfg
ブートローダーのインストール
GRUB をシステムのブートローダーとしてインストールする方法は、システムがどのようにブートするのか (どの種類のファームウェアか、例えば PC では、レガシーな BIOS か、その後継である UEFI か) と、ブートローダーがインストールされるディスクがどのようにパーティションされているのか (例えば PC では、パーティションレイアウトが MBR か GPT か) によって変わってきます。
この記事では次の場合についてをカバーします:
- BIOS と MBR、または CSM ('BIOS モード' あるいは 'レガシー/互換性モード' とも) を使用する場合の (U)EFI
- BIOS と GPT
- UEFI と GPT、ネイティブ (U)EFI ブートモード
- PowerPC 上の Open Firmware (IEEE 1275)
システムに対して適切なインストール方法の解説を選んでください。
BIOS と MBR
このシステムで Microsoft Windows などの他の (インストール済みの) オペレーティングシステムとデュアルブートする場合、Linux ブートローダが両方のオペレーティングシステムを共存させる、つまりデュアルブートすることができることを確認してください。PC では、インストール済みのシステムと同じブート方法を使用することが推奨されます。例えば、Windows がレガシー MBR パーティショニングを使用しているときは、ブートローダも 'legacy BIOS' モード (UEFI ではこれを Compatibility Support Module、略して CSM と呼びます、つまるところ BIOS エミュレーションです) で起動します。モードが変更された場合、例えば EFI-CSM (BIOS モード) からネイティブ (U)EFI モードに変更された場合、インストール済みのシステムはほぼ確実にブート不可能になるでしょう。
/boot を確実に利用可能にしてください。もしこれが独立したパーティションなら、確実にマウントしてください:
root #
mount /boot
関連するファイルを /boot/grub にコピーするために、 grub-install コマンドを実行してください。PCプラットフォームではさらに、これによってマスターブートレコード(MBR)かパーティションのブートセクタにブートイメージがインストールされます。もしすべてがうまくいけば、 grub-install の実行後、以下のような出力が得られることが期待されます:
root #
grub-install /dev/sda
Installation finished. No error reported.
grub-install は、CPUアーキテクチャとシステムプラットフォームを指定するための --target
オプションを受け付けます。指定しなかった場合、 grub-install は適切な値を推測しようとします。amd64/x86 システムにおいては、デフォルトで i386-pc
が使用されます。 grub-install はまた、ブートファイルを探す場所をGRUBインストーラに知らせるための --boot-directory
オプションを受け付けます。これはデフォルトでは /boot ですが、ルートパーティションを移動しようとしている場合などに有用です。
BIOS と MBR でのパーティショニング
最初のパーティションの前に十分な空き領域を用意しておいてください。最初のパーティションをセクタ2048で開始すれば、少なくとも1MiBのディスク領域がマスターブートレコードに残されることになります。GRUBのための"BIOSブートパーティション"とよばれる追加パーティションを作成することが(必須ではありませんが)推奨されます。このパーティションは定義される必要があるだけで、フォーマットは必要ありません。これは後からシステムがGPTパーティションレイアウトに移行される時に必要です。MBRを使い続ける限りは必要ありません。
もしGentoo installation instructionsに従ったのなら、BIOSブートパーティションはすでに有効なはずです。
BIOS と GPT
GPT was not designed for the legacy BIOS, yet with the protective MBR it includes a provision for it. Also, dual-boot with legacy operating systems designed to be booted from MBR, which is the de facto standard on computers with a BIOS, will need to access their partitions through the MBR, which can be accomplished by creating GPT/MBR hybrid partitions. This technique, however, has specific constraints.
On a BIOS system with GPT partitioning, GRUB relies on a partition call "BIOS boot partition". This partition is not formatted with a file system, instead grub-install will copy parts of the boot loader to it. The "BIOS boot partition" is not the same partition as a /boot partition.
もし /boot パーティションが必要ならば、 /boot パーティションのマウントから始めましょう。
root #
mount /boot
すべてがうまくいけば、 grub-install コマンドの実行後、以下のような出力が得られることが期待されます:
root #
grub-install /dev/sda
Installation finished. No error reported.
grub-install は、CPUアーキテクチャとシステムプラットフォームを指定するための --target
オプションを受け付けます。指定しなかった場合、 grub-install は正しい値を推測しようとします。amd64/x86 システムにおいては、BIOS モードではデフォルトで i386-pc
が使用され、GUID パーティションテーブル (GPT) との組み合わせで "BIOS ブートパーティション" が存在している場合は、自動的にこれが使用されます。
grub-install はまた、ブートファイルを探す場所を GRUB インストーラに知らせるための --boot-directory
オプションを受け付けます。これはデフォルトでは /boot ですが、ルートパーティションを移動しようとしている場合などに有用です。
Windows とのデュアルブート
このシステムで、BIOS モードでインストールされた Microsoft Windows とデュアルブートする場合、ネイティブ GPT パーティショニングの機能を完全に使用することはできません。Windows は、'CSM' と呼ばれる (U)EFI の BIOS エミュレーションモードも含めて、BIOS モードでは MBR パーティションからしかブートできません。一方で Linux では、BIOS (または EFI-CSM) モードからでも GPT パーティショニング方式を使用できますが、Windows とのデュアルブートのためにハイブリッドパーティショニングとする必要があります: 4 個までのパーティションが GPT と MBR のパーティションテーブルの両方に同時に定義できます。
従来 x86-PC はファームウェアとして BIOS を使用していました。PC での (U)EFI への切り替え (2005 年ごろ) 後は、'Compatibility Support Module' (CSM) と呼ばれる BIOS エミュレーションがあり、それにより PC は既存のオペレーティングシステムとの互換性を保っていました。EFI-CSM は 2020 年頃から PC 市場の主流から消えつつあります。2020 年以前でも、サーバなどの一部の (U)EFI 実装では CSM を完全に欠いた製品もあります。そのため、'Legacy BIOS mode' は現代の UEFI システムではもう利用できません。ネイティブブートモードの UEFI は GUID パーティションテーブル (GPT) を要求するので、インストール済みのオペレーティングシステムは既に GPT パーティショニング方式を使用しているでしょう。
ブートモードまたはパーティショニング方式を変更すると、インストール済の Windows はブート不能になるでしょう。さらに、古い Windows は GPT も EFI もまったくサポートしておらず、BIOS または EFI-CSM を MBR とともに使用することを要求します。Windows が EFI をサポートしている場合、ネイティブ UEFI モードと GPT パーティショニング方式で再インストールし、Linux も同様にすることができます。UEFI と GPT のセクションを見てください。
GPT と MBR のハイブリッドパーティショニングは、有効な GPT パーティションテーブルと有効な MBR パーティションテーブルを同時に作成しますが、MBR のプライマリパーティション数が最大 4 個である制限から、ハイブリッドパーティションの総数は 4 個までに制限されます。ESP (EFI ブートローダを保存する EFI システムパーティション) が 1 個のパーティションを取ることから、MBR と GPT で共有されるパーティションは 3 個だけしか残りません。そのうち 1 個を Windows のために、1 個を Linux のために使用すると、それ以外の用途に、例えば分離された Linux /boot パーティションや、2 つのオペレーティングシステム間で共有されるデータのパーティションとして利用できるハイブリッドパーティションは、1 個だけです。
GPT パーティションテーブルは通常、ディスク全体にまたがる 1 パーティションだけを含む MBR パーティションテーブルも作成します。これによって、古いソフトウェアによってディスクが '空' であると誤認識されないようになるしょう。この保護パーティションを持つ MBR は、そのため '保護 MBR' と呼ばれ、GPT 仕様に含まれています。 ハイブリッドパーティションを定義すると、この GPT の保護機能は失われます! レガシーソフトウェアがハイブリッド MBR を解析しても、使用済み領域を認識できなくなるでしょう。GPT を認識せず MBR しか認識しないソフトウェアは、MBR 上定義されていないディスク領域を、未使用の空き領域として誤認識するかもしれません。MBR で定義されたパーティションの外へのデータの書き込みは、背後にある GPT パーティションのデータ損失を引き起こすおそれがあります!
If there are two physical disks available to the system, a great solution is to have one disk use the GPT and the other the MBR partitioning scheme. Normally, the Windows installation uses only one partition as 'system partition' and 'boot partition', called 'drive C:'. When in BIOS mode the initial partition for booting, the 'system partition', must be an MBR partition. This applies to every Windows version since Windows XP and includes Windows 10. Since Windows Vista (actually Windows XP x64 Edition) the Microsoft operating system supports accessing GPT partitions. The solution is to relocate the 'system partition' part of an installation to the MBR partitioned disk, and convert the 'boot partition' (the one containing \WINDOWS) into a GPT partitioned disk. Windows can thereafter access all the GPT partitions on the one disk, and will continue to use the MBR partitions (or hybrid partitions) on the disk containing the 'system partition'. The Windows installation (containing \WINDOWS) would be a GPT partition, even when booted in BIOS mode. Windows 11 no longer supports BIOS/CSM/MBR mode.
BIOS と GPT でのパーティショニング
GPTパーティションテーブルがシステムに存在するとき、タイプ EF02
の小さな"BIOSブートパーティション"(タイプ EF00
の"EFIシステムパーティション(ESP)"とは異なります)を有効にする必要があります。動作させるには1MiBで十分ですが、2-4MiBがより安全な選択でしょう。このBIOSブートパーティションがブートローダーのステージ2を保持することになります。BIOSブートパーティションはファイルシステムでフォーマットされる必要はありません。grub-install コマンドが独自のファイルシステムで既存のファイルシステムを上書きします。
BIOSブートパーティションと一般的に/bootがマウントされるパーティションは同じではありません。 /boot と BIOSブートは別のパーティションにあるため、それぞれ別々に扱われるべきです。BIOSブートパーティションは絶対にシステムにはマウントされません。 (例えば/etc/fstabに定義されていないはずです)。対して/bootパーティションは何ら問題なく必ずマウントされるので、/etc/fstabファイルで定義することもできます。
パーティションをBIOSパーティションとして設定するには、コマンドラインツールの parted (sys-block/parted) を用い、以下のようにタイプしてください(1
をBIOSブートパーティションに設定したいパーティションの番号に置きかえてください!):
(parted)
set 1 bios_grub on
sys-apps/gptfdisk の cgdisk ユーティリティでは、これはパーティションタイプを 0xEF02
に設定し、 gptbios
というラベルを設定することで全うされます。
EFIシステムパーティションは必要ではありませんが、システムのマザーボードがUEFIのボードにアップグレードされたとき、後からこれに変更できるよう、BIOSブートパーティションを十分大きくしておくのはまともな判断でしょう。
次に示すのは、BIOSブート [0xEF02] パーティションとEFI [0xEF00] パーティションの両方を含むGPTパーティションのディスクで gdisk ユーティリティを用い、 p キーを押したときの出力です:
root #
gdisk /dev/sdc
GPT fdisk (gdisk) version 0.8.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): p Disk /dev/sdc: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): AA369F4D-37A4-4C0D-A357-DC24B99A6337 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 828377087 395.0 GiB 8E00 Linux LVM 2 828377088 891291647 30.0 GiB 0700 Microsoft basic data 3 891291648 975177727 40.0 GiB 0700 Microsoft basic data 4 975177728 976754687 770.0 MiB 8300 Linux filesystem 5 976754688 976756735 1024.0 KiB EF02 BIOS boot partition 6 976756736 976773134 8.0 MiB EF00 EFI System Command (? for help):
fdiskをGPTで用いるときは、十六進数の
0x
接頭辞の入力は必要ありません。同様のセットアップに対し、parted ユーティリティはやや異なる記法で出力を返します:
root #
parted /dev/sdc
GNU Parted 3.0 Using /dev/sdc (parted) print ... Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 424GB 424GB Linux LVM lvm 2 424GB 456GB 32.2GB Microsoft basic data 3 456GB 499GB 42.9GB Microsoft basic data 4 499GB 500GB 807MB ext2 Linux filesystem 5 500GB 500GB 1049kB BIOS boot partition bios_grub 6 500GB 500GB 8396kB EFI System boot (parted)
gdisk でのパーティションの作成は、すでに fdisk パーティショニングユーティリティに慣れているユーザーにとっては理解しやすいでしょう。gdisk を開始したら、メインメニューで(newを意味する) n をタイプし、(必要なら)開始と終了のセクタを与え、EFIシステムパーティションに EF00
パーティションタイプを設定してください。
Gentoo installation instructionsに従ったユーザーならば、すでに適切なパーティションレイアウトに設定されているはずです。
UEFI と GPT
UEFI-CSM を使用する場合は、こちらではなく BIOS と MBR または BIOS と GPT を参考にしてください。CSM は 'Compatibility Support Module' の略称で、これは BIOS エミュレーションといって、UEFI を BIOS のように動作させることができます。ファームウェア設定画面では 'Legacy Mode' または 'Compatibility Mode' と呼ばれていることも多いです。UEFI-CSM は必須の機能ではなく、主流市場のシステム (PC 等) からは 2020 年から消えつつあります。
/boot が利用可能であることを確認してください。もし別のパーティションにあるなら、マウントされていることを確認してください:
root #
mount /boot
grub-install コマンドを実行することで必要なファイルが/boot/grubにコピーされます。これによりGRUBが/boot/grubにインストールされ、そのコアイメージを/boot/efi/EFI/gentoo/grubx64.efiにコピーしたのちefibootmgrを呼び出してブートエントリを追加します。
root #
grub-install --efi-directory=/boot/efi
Installation finished. No error reported.
上のコマンドは、FAT でフォーマットされた EFI システムパーティション (ESP) が /boot/efi にマウントされていることを前提にします。もし ESP が /boot に直接マウントされているなら、代わりに
--efi-directory=/boot
としてください。grub-install は、CPUアーキテクチャとシステムプラットフォームを指定するための --target
オプションを受け付けます。指定がない場合、grub-installは適切な値の推測を試みます。
amd64/x86 システムにおいては、デフォルトで i386-pc
が使用されます。 grub-install はまた、ブートファイルを探す場所をGRUBインストーラに知らせるための --boot-directory
オプションを受け付けます。これはデフォルトでは /boot ですが、ルートパーティションを移動しようとしている場合などに有用です。
UEFI と GPT でのパーティショニング
UEFI GPTブートには、システムに必ずFATファイルシステムを含んだ専用のEFIシステムパーティションが必要です。
EFIパーティションは/dev/sda1上の/bootの役割を、 /dev/sda1上の/boot/efiへと移すことができます。つまりGRUBを使ったUEFIブートの場合でも、計2つ(スワップパーティションがあるなら計3つ)のパーティション、つまりルートパーティションとEFIパーティションで可能ということです。この設定を使うと、/bootフォルダはルート / と同じパーティションに置かれ、EFIパーティションは/bootフォルダの中の/boot/efiにマウントされます。下記の /etc/fstab の例を見るとはっきりするでしょう。
/etc/fstab
UEFIに対応したswapパーティションを含む /etc/fstab ファイルの例:/dev/sda1 /boot/efi vfat noauto,noatime 1 2 /dev/sda2 none swap sw 0 0 /dev/sda3 / ext4 noatime 0 1
/boot/efi は100MBもあれば複数の *.efi ファイルを格納するのには十分です(そもそも複数のエントリが必要になることは滅多になく、ほとんどのシステムは1つしか使いません)。
選びぬかれたパーティションツールを使ってパーティションを作成してください。gdisk (sys-apps/gptfdisk) と parted (sys-block/parted) はツールはこの目的には持って来いです。gdiskを使うときは必ずtype EF00
を利用してください。
続いて次の例のように、 mkfs.fat を用いてEFIシステムパーティション上にFATファイルシステムを作成し、 /etc/fstab へ項目を追加してください。
root #
mkfs.fat -F 32 -n efi-boot /dev/sda1
root #
mkdir /boot/efi
/etc/fstab
/boot/efi マウント項目の追加/dev/sda1 /boot/efi vfat noauto,noatime 1 2
root #
mount /boot/efi
/etc/portage/make.confファイルにて 環境変数GRUB_PLATFORMS を設定しておくと便利です。これはGRUBが適切なEFIターゲットを検出する際にどのオプションを用いるかを決定する助けになるでしょう。32ビットUEFIシステムには
efi-32
を、64ビットシステムには efi-64
を利用してください。"x86-64" または "x64" と呼ばれる 64-bit x86 プロセッサがレガシー 32-bit ソフトウェアの実行に対応していても、EFI 実装も同じことができるとは限りません。64-bit EFI が 32-bit .efi ローダを実行することはできないでしょう!
GRUBを適切にインストールするためには grub-install コマンドを実行する前に、必ずEFIディレクトリがマウントされていて、かつ
efivars
カーネルモジュールもロードされている必要があります代替案: デフォルトのUEFIファームウェアの場所を利用する
もしシステムのUEFIファームウェアがGRUBのEFIファイルを見つけられない場合、既定のブートローダの場所を利用することで解決するでしょう。このときefibootmgrが提供するブートメニューを使えないため機能は減りますが、エラーは起きづらくなります。これを行うためには、EFIパーティションが/boot/efiにマウントされていることを確認した上で/boot/efi/EFI/gentoo/grubx64.efiにあるgrubx64.efiファイルを/boot/efi/EFI/BOOT/BOOTX64.EFIにコピーして下さい。なおこの例では 64-bit UEFI システムを前提としています。32-bit UEFI システムでは "X64" を "IA32" で置き換えて (つまり、/boot/efi/EFI/BOOT/BOOTIA32.EFI として) ください。
PowerPC 上の Open Firmware (IEEE 1275)
こちらをご覧ください。
拡張機能
GRUB 2 は、その多くの機能によって、非常にパワフルなブートローダーとなっています。サポートされる機能は:
- UEFIパーティションからのブート
- ハイブリッドMBRを必要としない、GPTでパーティションされたドライブからのブート(ハイブリッドMBRは、必要なら互換性と移植性のために有効にできます)
- btrfs でフォーマットされた /boot パーティションからのブート
- ZFSプールからのブート
- 初期マウントセットアップのための initramfs を必要としない、btrfs raidセットからの直接のブート
- 論理ボリューム管理からの直接のブート(たとえば LVM2)
- DM-RAID(RAID 0, 1, 4, 5, 6, 9 と 10)をサポートしたブート
- 暗号化されたデバイス(LUKS)からのブート
次にいくつかの項目について詳しく説明します。
チェーンロード
GRUB 2 は GRUB Legacy よりはるかに優れたチェーンロードモードが備わっています。他のブートローダーをチェーンロードするには、 chainloader
オプションを利用してください。
/etc/grub.d/40_custom
ほかのブートローダに引き継ぐ(チェインロード)menuentry "Custom Super Bootloader Example" { insmod part_msdos insmod chain chainloader (hd1,1)+1 }
さらなるチェーンロードの情報については Chainloading サブ記事を参照してください。
GRUBのメニューのパスワード保護
ブートパラメータを変更できないようにしたり、コマンドラインを使用できなくすることでGRUBを安全にするには、ユーザ/パスワードの組み合わせをGRUBの設定ファイルに追加してください。grub-mkpasswd-pbkdf2がGRUB用のパスワードのハッシュを作成します:
user $
grub-mkpasswd-pbkdf2Password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.9CA4611006FE96BC77A...
そして、以下を追加してください:
/etc/grub.d/35_auth:
# Grubユーザ名 echo 'set superusers="username"' # Grubパスワード echo 'password_pbkdf2 <username> <password>'
フレームバッファディスプレイを使う
GRUB で framebuffer のグラフィカルな表示を利用するには、 truetype
USE flag を有効にして再emergeしてください。これによりfont変換ツールの他にデフォルトの True Type フォントがインストールされます。
root #
emerge --ask --newuse sys-boot/grub:2
次に、/etc/default/grub にあるデフォルト設定ファイルを設定します。例えば、
/etc/default/grub
フレームバッファに関する設定# 解像度と色深度の設定 GRUB_GFXMODE=1366x768x32 # カーネルのロードの際に解像度を保つ GRUB_GFXPAYLOAD_LINUX=keep # 背景画像の設定 GRUB_BACKGROUND="/boot/grub/bg.png" # grub-mkfontユーティリティで変換したカスタムフォントを使う GRUB_FONT="/boot/grub/fonts/roboto.pf2" # メニューの色を設定する GRUB_COLOR_NORMAL="light-blue/black" GRUB_COLOR_HIGHLIGHT="light-cyan/blue"
HiDPI ディスプレイ
UHD (3840x2160) などの高い解像度 ("HiDPI") を備えた新しいディスプレイ上では、標準のフォントは非常に小さく見えるでしょう。カーネルと同じフォントを利用したい場合、Terminus を利用することができます。これは BIOS 組み込みテキストモードフォントによく似ています……。
CONFIG_FONT_TER16x32: Terminus Font is a clean, fixed width bitmap font, designed for long (8 and more hours per day) work with computers. This is the high resolution, large version for use with HiDPI screens. If the standard font is unreadable for you, say Y, otherwise say N.
このフォントをカーネル内で選択するには、CONFIG_FONT_TER16x32
を有効化する必要があります。
Library routines ---> [*] Select compiled-in fonts [*] Terminus 16x32 font (not supported by all drivers)
これと同じフォントが media-fonts/terminus-font としても利用でき、インストールすればこれを GRUB でも使うことができます。
root #
emerge --ask media-fonts/terminus-font
root #
grub-mkfont -s 32 -o /boot/grub/fonts/terminus32b.pf2 /usr/share/fonts/terminus/ter-u32b.otb
上の例では、grub-mkfont
の出力ファイル名を terminus32b.pf2
としています。フォントのパスはブート中に GRUB からアクセスできる必要があるので、GRUB と同じマウントポイントに置くべきです。この例では /boot/grub/fonts
を使用しています。次にこれを使用するために、/etc/default/grub
でフォントを GRUB_FONT
として設定する必要があります。
/etc/default/grub
フレームバッファ関連の設定# grub-mkfont ユーティリティを利用して変換されたカスタムフォントを使う GRUB_FONT="/boot/grub/fonts/terminus32b.pf2"
GRUB 設定ファイル grub.cfg
を更新すると、新しいフォントを使用する設定が有効化されます。
root #
grub-mkconfig -o /boot/grub/grub.cfg
トラブルシューティング
さらなるトラブルシューティングについては、Troubleshooting サブ記事を参照してください。
ほとんどの問題は、正しいパーティションレイアウトを確実に設定することで解決できます。ディスクの最初のパーティションの前に十分な領域を確保するか、任意で確実に"BIOSブートパーティション"が利用できるようにしてください。さらに、/boot/grub/grub.cfg が grub-mkconfig で正しく生成されているか確認するか、あるいはカスタムのメニュー項目で生成してください。
os-prober が動作していない
grub-mkconfig コマンドを実行したときに、os-prober がインストールされているのに、期待通り動作していません:
root #
grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.11.14-gentoo-x86_64 Found initrd image: /boot/amd-uc.img /boot/initramfs-5.11.14-gentoo-x86_64.img Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... done
これは /etc/default/grub ファイルで GRUB_DISABLE_OS_PROBER 変数を false
に設定することで修正できます。
/etc/default/grub
GRUB_DISABLE_OS_PROBER=false
次の実行時に、grub-mkconfig はブート可能なパーティションを追加で見つけるはずです:
root #
grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.11.14-gentoo-x86_64 Found initrd image: /boot/amd-uc.img /boot/initramfs-5.11.14-gentoo-x86_64.img Warning: os-prober will be executed to detect other bootable partitions. It's output will be used to detect bootable binaries on them and create new boot entries. Found Windows Boot Manager on /dev/nvme0n1p2@/efi/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for UEFI Firmware Settings ... done
.EFI ファイルを検知しないマザーボードファームウェア
一部メーカー製の特に古い (2020 年以前の) マザーボードには、EFI システムパーティション (ESP) 内の .EFI ファイルの置き場所として、フォールバックまたはリムーバブルメディア用のパス 1 箇所しかサポートしていないものがあるようです。これに当てはまると思われる場合、単純に GRUB のデフォルトファイルを /efi/boot/ に移動してください。まず、ESP がマウントされていることを確認してください。ESP が (ハンドブック で推奨されているように) /boot/efi にマウントされているとして、以下を実行してください:
root #
mkdir -p /boot/efi/efi/boot
root #
cp /boot/efi/efi/gentoo/grubx64.efi /boot/efi/efi/boot/bootx64.efi
32-bit EFI 実装では、代わりに bootia32.efi
を使用してください:
root #
cp /boot/efi/efi/gentoo/grubia32.efi /boot/efi/efi/boot/bootia32.efi
removable
パラメータを使用して、このファイルを grub-install コマンドで自動的に作成することができます:
root #
grub-install --efi-directory=/boot/efi --removable
Installation finished. No error reported.
これでマザーボードのファームウェアがGRUBの実行可能ファイルを読み込めるようになるはずです。システムを再起動して、ファームウェアが正しくGRUBを読み込むようになったか見てみましょう。
chroot環境下でのos-proberとUEFI
sys-boot/os-prober を使用すると、Microsoft WindowsなどのLinuxの代わりにインストールされたOSを検出できます。これを正しく動作させるには、EFIシステムパーティションのテストのためlive環境のudevの情報にアクセスできるようにする必要があります。
下記のコマンドをホスト環境で実行すると必要なファイルが得られます (この例では、Handbookにある通りGentooは/mnt/gentooにマウントされているものとしています)。
root #
mkdir -p /mnt/gentoo/run/udev
root #
mount -o bind /run/udev /mnt/gentoo/run/udev
root #
mount --make-rslave /mnt/gentoo/run/udev
新しいカーネルをインストール
新しいカーネルをGRUBに認識させるため、カーネルをインストールした際には必ずGRUBを再設定しなければなりません。下記のように、 grub-mkconfigを実行することで再設定が可能です。あるいは手動で行うこともできます。
このステップでは /boot がマウントされている必要があります。
root #
grub-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ... Found linux image: /boot/kernel-3.3.8-gentoo Found initrd image: /boot/initramfs-genkernel-x86_64-3.3.8-gentoo Found linux image: /boot/kernel-3.2.12-gentoo Found initrd image: /boot/initramfs-genkernel-x86_64-3.2.12-gentoo done
GRUBは単に「再設定」が必要なだけで、「再インストール」が必要なわけではありません。一方、GRUB自身が更新された際にはハードディスク上のGRUB2を再インストールする必要がありますが、このときには普通、再設定は必要ありません。
関連項目
- Chainloading には GRUBで他のブートローダーを利用する方法が書かれています。これはデュアルブートやISOファイルのブートを構成する必要がある場合には重要です。
- Advanced storage には RAIDや論理ボリューム、暗号化ファイルシステムなど、より最新のストレージを利用する際のGRUBインストール方法や利用方法が書かれています。
- Configuration variables には /etc/default/grub で利用可能なすべての GRUB configuration variable がまとめられています。
- Troubleshooting にはよくあるGRUBのエラー(とそれらの解決策)が挙げられています。
- Hybrid partition table には MBR/GPTが混合したハイブリッドパーティションの設定方法と、そのGRUBでの利用方法がまとめられています。
外部の情報
さらなる情報については、以下を参照してください:
- GNU GRUB 2 manual page
- Legacy BIOS issues with GPT article
- GPT and Hybrid MBR article
- GPT fdisk utility page
- Arch Linux GRUB 2 wiki article
- Fedora GRUB2 wiki article : Encountering the dreaded GRUB2 boot prompt
- ubuntu UEFI booting help
- https://unix.stackexchange.com/questions/109272/dualboot-freebsd-gentoo-with-grub2-mbr
- A blog post entry on locking specific GRUB2 boot entries with a password