efibootmgr

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Efibootmgr and the translation is 91% complete.

efibootmgr は、UEFI ブートエントリを管理するためのツールです。

これは、ブートローダではありません。ブートマネージャとして動作するのはシステムの EFI ファームウェアそれ自体です。efibootmgr は、これを操作するためのツールです。efibootmgr を用いることで、ブートエントリを作成したり順序を変えたり削除したりすることが可能になります。

インストール

カーネル

CONFIG_EFIVAR_FS サポートを有効化する必要があります。

メモ
efivarfs を EFI ランタイムサービス抜きで使用することはできません。もしこれがデフォルトで無効化されている場合 (CONFIG_EFI_DISABLE_RUNTIME=y)、カーネルコマンドラインオプション efi=runtime によって有効化することもできます。

Emerge

sys-boot/efibootmgr には USE フラグがありませんから、ただ単にインストールすればよいです:

root #emerge --ask sys-boot/efibootmgr

設定

EFI 変数

efibootmgr が正しく動作するには、 EFI 変数ファイルシステムにアクセス可能になっていなければなりません。そのためには、システムが(ファームウェア(BIOS)の MBR モードではなく)EFI モードでブートされている必要があります。そうでないと EFI 変数へのアクセス自体が不可能です。システムが MBR モードになっていたら、再起動して、システムのファームウェアに EFI モードで起動するように指示する必要があります。大概は、ファームウェアの設定オプションを変えたり、システムのブートメニューで EFI ブートエントリを選んだりすることで解決します。

システムが EFI モードにあるとき、マウント済みの efivarfs が存在するか調べるには、以下のコマンドを実行してください:

root #mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,relatime)

これは sysfs init スクリプトで読み込み専用 (ro) としてマウントされているので、以下のコマンドを使用して、手動で読み書き可能 (rw) として再マウントする必要があります:

root #mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars

前提条件

EFI システムパーティション (ESP) が存在しない場合は作成する必要があります。EFI システムパーティションを参照してください。

使い方

ブートエントリの一覧表示

古いバージョンの efibootmgr を使用している場合は、オプション --verbose または -v が必要です:

root #efibootmgr
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0003,0002,0000,0004
Boot0000* CD/DVD Drive  BIOS(3,0,00)
Boot0001* Hard Drive    BIOS(2,0,00)
Boot0002* Gentoo        HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\boot\bootx64.efi)
Boot0003* Hard Drive    BIOS(2,0,00)P0: ST1500DM003-9YN16G

ブートエントリを作成する

EFI のブートエントリを作成するには、efibootmgr に対していくつかのオプションを与えます:

  • --create または -c 新しいエントリの作成;
  • --part または -p EFI システムパーティションのあるパーティション番号;
  • --disk または -d EFI システムパーティションのあるディスク名;
  • --label または -L ブートエントリに使用したいラベル名;
  • --loader または -l ブートする EFI イメージの置いてあるパス
重要
EFI イメージのパスでは、/(スラッシュ)ではなく \(バックスラッシュ)を使用しなければなりません
重要
くわえて、ESP が既に他の OS によって作成済の場合は、/efi/EFI とは異なる名前が付いている場合があります。ESP が他の OS によって作成済の場合、EFI ブートエントリは、/efi の後に続くこのディレクトリ名で始めてください。

どのようにして UEFI エントリを作成すればよいか、以下にいくつかの例を示します。もしフォルダ構造が以下のようになっていれば:

root #tree /efi/ -L 3
/efi/
└── EFI
    ├── Grub
    │   └── grubx64.efi
    └── Gentoo
        └── bzImage.efi

ローダのパスは以下のようになるでしょう:

root #efibootmgr -c -L "Grub" -l '\EFI\Grub\grubx64.efi'
root #efibootmgr -c -L "Gentoo" -l '\EFI\Gentoo\bzImage.efi'

例えば:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l '\efi\boot\bootx64.efi'

カーネルのコマンドラインに渡すパラメータを追加することもできます。すべての UEFI 実装でサポートされているとは限りません[1]が:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l '\efi\boot\bootx64.efi' -u 'root=/dev/sda3 initrd=\efi\boot\initramfs.img quiet'

必要に応じて、追加のカーネルをインストールして UEFI ファームウェアに登録しておくことができます。これは、より多くのカーネルをテストしたい場合やもう一つのオペレーションシステムとデュアルブートしたい場合に特に便利です。これらは通常、システムの初期化中の適切な時にキーボードのホットキーを押した後にブート選択ダイアログに表示されます。最後に追加したエントリが常に最も高いブート優先度を得るので、これがデフォルトになります。ホットキーの組み合わせがわからなければ、コンピューターの製造業者の公式ドキュメントを探してみてください。通常、この情報を探すのは難しいことではありません。

ブートエントリを削除する

エントリを削除するにはまず、そのエントリのID番号を見つけなければなりません。

例えば Gentoo のエントリが前記のようであれば(Boot0002 がID であれば)、efibootmgr に対して --bootnum または -b でID番号を指定し --delete-bootnum または -B でエントリの削除を命令します。

root #efibootmgr -b 2 -B 2

リムーバブルメディア

リムーバブルメディア上の EFI ブートローダはブートエントリとして構成されないので、efibootmgr のようなツールは必要ではありません。代わりにコンピュータのファームウェアが、事前に定義されたパス内の、使用中のシステムアーキテクチャごとに異なる事前に定義されたファイル名を探して、リムーバブルブートオプションを特定します。[2]

Some (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[3] This is against specification and should be avoided, but may help on a system with a buggy (U)EFI. Only one such fallback bootloader is possible on a specific system (i.e. architecture), due to the standardized boot path and file names.

アーキテクチャ 略称 ファイル名 PE 実行可能形式のマシンタイプ
x86 32 ビット IA-32 \efi\boot\bootia32.efi 0x14c
x86-64 x64 \efi\boot\bootx64.efi 0x8664
Itanium IA-64 \efi\boot\bootia64.efi 0x200
ARM 32 ビット AArch32 \efi\boot\bootarm.efi 0x01c2
ARM 64 ビット AArch64 \efi\boot\bootaa64.efi 0xAA64
RISC-V 32 ビット \efi\boot\bootriscv32.efi 0x5032
RISC-V 64 ビット \efi\boot\bootriscv64.efi 0x5064
RISC-V 128 ビット \efi\boot\bootriscv128.efi 0x5128
Loongson 32 ビット LoongArch32 \efi\boot\bootloongarch32.efi 0x6232
Loongson 64 ビット LoongArch64 \efi\boot\bootloongarch64.efi 0x6264
メモ
To boot from removable media, the firmware has to look for compatible bootloaders on supported devices, which can be configured in the firmware setup. Like most firmwares, (U)EFI provides a hotkey to show a boot selection (formally known as "BIOS Boot Selection" or BBS), otherwise (U)EFI will use the configured default boot entry. However, a buggy (U)EFI may default to the removable media boot path even on internal drives.

To use the removable media boot path it is sufficient to copy the EFI bootloader to the required path and file name. Should the firmware make use of this fallback, this may also remove the ability to select between configured boot entries, meaning that boot options (as listed with efibootmgr) through (U)EFI will not work. Even though every EFI bootloader can be used as fallback, it may be advisable to use a boot manager that itself has the ability to select between boot options, such as GRUB. From the above example for x64 (amd64):

root #cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
メモ
The FAT file system of the EFI System Partition is not case-sensitive, but case-preserving (VFAT), while Unix and Linux is strictly case-sensitive at all times. Because of this, the path /efi/EFI/boot/bootx64.efi may not work on all systems, as it could be using capital letters, e.g. /efi/EFI/BOOT or /efi/EFI/Boot; the same goes for bootx64.efi. Running tree -L 3 /efi, when the ESP is mounted under /efi, will show the names in use on the individual system, to which the above command has to be changed accordingly.
重要
The fallback bootloader is not automatically updated! Every time e.g. GRUB is re-installed (like after a version update, which may contain security fixes), it has to be copied to the fallback boot path again, overwriting (updating) the previous version!

The boot manager included in systemd, systemd-boot (formally Gummiboot), will automatically install to the removable media boot path. When sys-apps/systemd with the boot USE flag is updated, it is necessary to run bootctl again in order to update both bootloader files.

root #bootctl update

削除

Unmerge

root #emerge --ask --depclean --verbose sys-boot/efibootmgr

関連項目

参照