Unified Extensible Firmware Interface
Unified Extensible Firmware Interface (もしくは省略して UEFI や EFI)はオペレーティングシステムとファームウェア間のインターフェイスのモデルです。オペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。
UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては Arch ブートプロセス を見てください。UEFI ブートローダをセットアップするには ブートローダー を見てください。
目次
- 1 UEFI のバージョン
- 2 UEFI ファームウェアのビット数
- 3 UEFI の Linux カーネル設定オプション
- 4 UEFI 変数
- 5 UEFI シェル
- 6 UEFI ドライバ
- 7 UEFI ブータブルメディア
- 8 ネイティブサポートのない環境で UEFI をテストする
- 9 トラブルシューティング
- 9.1 Windows で固まった際に Arch Linux に戻る
- 9.2 ファンクションキー無しでファームウェアセットアップに入る
- 9.3 ユーザスペースのツールが UEFI 変数のデータを変更できない
- 9.4 efibootmgr でブートエントリを新規作成できない
- 9.5 UEFI モードで Windows 7 が起動しない
- 9.6 Windows によってブート順序が変わってしまう
- 9.7 USB メディアが黒画面で固まる
- 9.8 ファームウェアのメニューに UEFI ブートローダーが表示されない
- 9.9 ハードウェアが変更された後や他のオペレーティングシステムを起動した後にシステムが EFI シェルに入る
- 9.10 efibootmgr で作成したブートエントリが UEFI に表示されない
- 9.11 UEFI ブートエントリが、参照するドライブを取り外すと消える
- 10 参照
UEFI のバージョン
- UEFI は Intel の EFI としてバージョン 1.x で始まりました。
- その後、the UEFI Forum とよばれる企業のグループが開発を引き継ぎ、EFI は Unified EFI へと名前を変え、バージョン 2.0 になりました。
- EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。
- Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。また、以下の手順は明白に書かれている部分を除き、一般的な UEFI を対象としており、場合によっては手順のいくつかは Apple Mac では動かなかったり違っていたりする可能性があります。
最新の UEFI 仕様は https://uefi.org/specifications にて確認できます。
UEFI ファームウェアのビット数
UEFI においては、すべてのプログラムは OS ローダーであろうとユーティリティ(メモリテストやリカバリツール)であろうと、UEFI ファームウェアのビット数/アーキテクチャに対応する EFI アプリケーションであるべきです。
最近の Apple Mac を含む UEFI ファームウェアの大部分は x86_64 UEFI ファームウェアを使用します。IA32 (32ビット) の UEFI を使うことが知られているデバイスは古い(2008年以前) Apple Mac や Intel Atom System-on-Chip システム(2013年11月2日現在)[1]、そして Intel EFI 1.10 ファームウェア上で動作することが知られている一部の古い Intel のサーバーボードだけです。
x86_64 UEFI ファームウェアは 32ビットの EFI アプリケーションの起動をサポートしません(x86_64 Linux とそのようなサポートを含む Windows のバージョン とは違って)。それゆえ、EFI アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。
UEFI ファームウェアのビット数を調べる
ファームウェアのビット数は起動されたオペレーティングシステムから確認できます。
Linux で
Linux カーネル 4.0 以上が走るディストリビューションでは、UEFI ファームウェアのビット数は sysfs インターフェイスを通して確認できます。以下を実行してください:
$ cat /sys/firmware/efi/fw_platform_size
このコマンドは、64ビット(x86_64) UEFI の場合は 64、32ビット(IA32) UEFI の場合は 32 を返します。このファイルが存在しない場合は UEFI モードで起動していないということです。
macOS で
2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年以降の Mac のファームウェアはほとんど x86_64-efi です。Mac OS X Snow Leopard を動かすことのできる全ての Mac は x86_64 EFI 1.x ファームウェアを使っています。
Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください:
$ ioreg -l -p IODeviceTree | grep firmware-abi
コマンドの返事が EFI32 なら、IA32 (32ビット) EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x86_64 EFI ファームウェアです。ほとんどの Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI 2.x の仕様に完全には準拠していないからです。
Microsoft Windows で
64ビット Windows は 32ビット UEFI からの起動をサポートしていません。なので、UEFI モードで 32ビット Windows を起動している場合は 32ビット UEFI を使用しているということになります。
ビット数を調べるには msinfo32.exe を実行してください。システムの要約を開き、"システムの種類"と"BIOS モード"の値を見てください。
64ビット UEFI 上で動作している 64ビット Windows では システムの種類: x64-ベース PC、BIOS モード: UEFI となります。32ビット UEFI 上で動作する 32ビット Windows では システムの種類: x86-ベース PC、BIOS モード: UEFI となります。もし、"BIOS モード" が UEFI でない場合、Windows は UEFI モードで起動していないということです。
UEFI の Linux カーネル設定オプション
UEFI システムのために必要な Linux カーネル設定オプション[2]は:
CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_X86_SYSFB=y CONFIG_FB_SIMPLE=y CONFIG_FRAMEBUFFER_CONSOLE=y
UEFI Runtime Variables Support (efivarfs ファイルシステム - /sys/firmware/efi/efivars)。このオプションは /usr/bin/efibootmgr などのツールを使って UEFI ランタイム変数を操作するのに必要なので重要です。次の設定オプションはカーネル 3.10 以上で追加されています。
CONFIG_EFIVAR_FS=y
UEFI Runtime Variables Support (古い efivars sysfs インターフェイス - /sys/firmware/efi/vars)。このオプションは efivars と sysfs-efivars がともに有効な場合の潜在的な問題を回避するため無効にしてください。
CONFIG_EFI_VARS=n
GUID Partition Table (GPT) 設定オプション - UEFI サポートのために必須
CONFIG_EFI_PARTITION=y
EFI mixed-mode サポート - IA32 UEFI で x86_64 カーネルを起動するのに必要:
CONFIG_EFI_MIXED=y
UEFI 変数
UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:
$ efivar --list
Linux カーネルでの UEFI 変数のサポート
Linux カーネルは efivarfs (EFI VARiable FileSystem) インターフェイスを通して UEFI 変数のデータをユーザスペースに公開します(CONFIG_EFIVAR_FS)。このインターフェイスは efivarfs カーネルモジュールを使って /sys/firmware/efi/efivars にマウントされます。変数ごとの最大サイズ制限は無く、UEFI Secure Boot 変数をサポートします。これはカーネル 3.8 で導入されました。
UEFI 変数のサポートを正しく動作させるための必要条件
- カーネルが EFISTUB(任意で ブートマネージャー)を通して、またはブートローダーによって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
- EFI Runtime Services サポートがカーネルに存在する必要があります (
CONFIG_EFI=y)。zgrep CONFIG_EFI /proc/config.gzで確認できます。 - カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり
noefiカーネルパラメータは使わないで下さい。 efivarfsファイルシステムが/sys/firmware/efi/efivarsにマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい。efivarはエラーを出さずに EFI 変数をリストアップ (-l/--listオプション) するはずです。
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
- UEFI 変数のリストアップ(
efivar -l)の際にefivar: error listing variables: Function not implementedと言うメッセージが出て、かつ、システムがリアルタイムカーネルで起動する場合、カーネルパラメータにefi=runtimeを追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。 - さらなるドラブルシューティング手順は #ユーザスペースのツールが UEFI 変数のデータを変更できない を見てください。
efivarfs のマウント
efivarfs が起動中にsystemd によって自動的に /sys/firmware/efi/efivars にマウントされない場合、UEFI 変数を efibootmgr のようなユーザースペースツールに公開するために efivarfs を手動でマウントする必要があります:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
カーネルドキュメントの efivarfs.html を参照してください。
ユーザースペースツール
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
- efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
- efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール
- uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。
- efitools — UEFI セキュアブートプラットフォームを操作するための UEFI ツール
- Ubuntu's Firmware Test Suite — Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート
efibootmgr
efibootmgr パッケージをインストールする必要があります。
efibootmgr を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:
- EFI システムパーティション (ESP) を含むディスク (例:
/dev/sda/dev/nvme0n1)。 - そのディスク上にある ESP のパーティション番号。
/dev/sdaYや/dev/nvme0n1pYのYの部分のことです。 - EFI アプリケーションへのパス (ESP のルートからの相対パス)
例えば、/efi が ESP のマウントポイントである場合に /efi/EFI/refind/refind_x64.efi 用のブートオプションを追加したい場合、以下を実行してください:
$ findmnt /efi
TARGET SOURCE FSTYPE OPTIONS /efi /dev/sda1 vfat rw,flush,tz=UTC
この例では、ESP がディスク /dev/sda 上にあり、そのパーティション番号が 1 であることを示しています。EFI アプリケーションへの、ESP をルートとした相対パスは /EFI/refind/refind_x64.efi となっています。故に、ブートエントリを以下のように作成することになります:
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
さらなる情報は efibootmgr(8) または efibootmgr README を見てください。
UEFI 変数へのアクセスを無効化
UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[3]
ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。
可能な方法は:
efivarsを fstab を用いて読み取り専用モードでマウントする。例えば:efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
noefiカーネルパラメータを使用して、OS から UEFI へのアクセスを完全に無効化する。
UEFI シェル
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
UEFI シェルを入手する
Tianocore EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:
- Shell v2:
- Arch インストールメディアの
/shellx64.efi。ISO がビルドされたときの/usr/share/edk2-shell/x64/Shell_Full.efiのコピーです。 - edk2-shell パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
- uefi-shell-gitAUR パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル
- Arch インストールメディアの
- Shell v1:
- TianoCore 由来の プリコンパイル済み UEFI Shell v1 バイナリ (2014/1/10 から上流は一度もアップデートされていません)。
- 派生版:
- プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg - Clover EFI ブートローダ由来。
- 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ - OpenCore ブートローダ由来。リリースアーカイブでは:
EFI/OC/Tools/OpenShell.efi。
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkg や Inclusion of UEFI shell in Linux distro iso を見て下さい。
UEFI シェルの起動
数少ない Asus や他の AMI Aptio x86_64 UEFI ファームウェアベースのマザーボード(Sandy Bridge 以降)では、Launch EFI Shell from filesystem device と呼ばれるオプションが提供されています。これらのマザーボードでは、x86_64 UEFI Shell を EFI システムパーティション のルートに shellx64.efi という名前で コピーしてください。
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており F6, F11, F12 キーのどれかで起動できます。
重要な UEFI シェルコマンド
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。利用できるコマンドを表示するには help -b を実行してください。
詳しい情報は Intel Scripting Guide 2008 と Intel "Course" 2011 を見てください。
bcfg
bcfg コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては UEFI Shell Specification 2.2 ドキュメントの 96 ページ (Section 5.3) で詳しく説明されています。
現在のブートエントリのリストを出力するには:
Shell> bcfg boot dump -v
4番目の（番号は0から始まります）オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには:
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
FS0: は EFI System Partition に、FS0:\EFI\refind\refind_x64.efi は起動するファイルにそれぞれ適切にマッピングしてください。
ブートローダ無しでシステムを直接ブートするエントリを追加するには、カーネルを EFISTUB として使用してブートオプションを設定してください:
Shell> bcfg boot add N fsV:\vmlinuz-linux "Arch Linux" Shell> bcfg boot -opt N "root=/dev/sdX# initrd=\initramfs-linux.img"
N は優先度、V は EFI システムパーティションのボリューム番号、/dev/sdX# はルートパーティションです。
4番目のブートオプションを削除するには:
Shell> bcfg boot rm 3
ブートオプション #3 を #0 (つまり UEFI ブートメニューの最初のエントリ) に移動するには:
Shell> bcfg boot mv 3 0
bcfg のヘルプを見るには
Shell> help bcfg -v -b
もしくは
Shell> bcfg -? -v -b
map
map はデバイスマッピング (つまり、利用可能なファイルシステム (FS0) とストレージデバイス (blk0) の名前) の一覧を表示します。
cd や ls などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります:
Shell> fs0: fs0:\> cd EFI/
edit
edit コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
例として、システムパーティションの rEFInd の refind.conf を編集するには (ファームウェア内の FS0:)
Shell> edit FS0:\EFI\refind\refind.conf
ヘルプを出すには Ctrl+e を押して下さい。
UEFI ドライバ
UEFI ブータブルメディア
ISO から UEFI ブータブル USB を作成する
USB インストールメディア#ISO をそのまま使う(BIOS と UEFI) を参照してください。
光学メディアから UEFI ブートサポートを削除する
ほとんどの32ビット EFI Mac と一部の64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。光学メディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があるかもしれません。
UEFI 特有のディレクトリを除いて ISO を展開してください:
$ mkdir extracted_iso $ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-version-x86_64.iso -C extracted_iso
そして、libisoburn の xorriso(1) を使って ISO を再ビルドしてください。この時、UEFI 光学メディアのブートサポートを除いてください。正しいボリュームラベルを設定してください(例えば ARCH_202103)。ボリュームラベルは、オリジナルの ISO に対して file(1) を使うことで得られます。
$ xorriso -as mkisofs \
-iso-level 3 \
-full-iso9660-filenames \
-joliet \
-joliet-long \
-rational-rock \
-volid "ARCH_YYYYMM" \
-appid "Arch Linux Live/Rescue CD" \
-publisher "Arch Linux <https://archlinux.org>" \
-preparer "prepared by $USER" \
-eltorito-boot syslinux/isolinux.bin \
-eltorito-catalog syslinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \
-output archlinux-version-x86_64-noUEFI.iso extracted_iso/
archlinux-version-x86_64-noUEFI.iso を光学メディアに焼いて、通常のインストールを続けてください。
ネイティブサポートのない環境で UEFI をテストする
仮想マシン用の OVMF
OVMF は仮想マシンで UEFI サポートを有効にする TianoCore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
edk2-ovmf をインストールできます。
仮想マシンの非揮発性変数のローカルコピーを作成することが推奨されています:
$ cp /usr/share/edk2-ovmf/x64/OVMF_VARS.fd my_uefi_vars.fd
OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください:
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=my_uefi_vars.fd
例えば:
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd …
BIOS システム用の DUET
DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする TianoCore プロジェクトです。この方法については https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ で広く議論されています。ビルド済み DUET イメージは https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer にあるリポジトリのどれかからダウンロードできます。DUET をセットアップする特定の方法については https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt で見られます。しかし、2018年11月に DUET のコードが TianoCore git リポジトリから削除されました。
また、修正 DUET イメージを提供する https://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の修正が含まれており gitlab リポジトリと比べて頻繁に更新されています。
トラブルシューティング
Windows で固まった際に Arch Linux に戻る
Windows で固まった際に Arch Linux に戻るには、Windows PowerShell コマンド shutdown /r /o、または Settings > Update & Security > Recovery > Advanced startup の Restart now を選んで Windows の Advanced startup に進んでください。Advanced startup メニューに行き着いた際に、Use a device を選んでください。これには実際の UEFI ブートオプションが含まれています(USB や CD に限らず、ハードドライブ内の OS も起動できます)。そして、"Arch Linux" を選んでください。
ファンクションキー無しでファームウェアセットアップに入る
en:Lenovo XiaoXin 15are 2020 のような一部のノート PC では、F2 や F12 のようなキーを使用しても何も起こりません。OEM にノート PC を返却しメインボード情報の修復を行えばおそらく修正可能ですが、時々これが不可能である、または望ましくない場合があります。しかし、ファームウェアセットアップに入る他の方法が存在します:
- systemctl を使用:
$ systemctl reboot --firmware-setup
これによりコンピュータが再起動され、ファームウェアセットアップに入ります。 - GRUB を使用: コマンドラインに入るために
cを押し、GRUB コマンドラインでfwsetupを使用してファームウェアセットアップに入る。 - Windows で: Advanced Startup に入る。#Windows で固まった際に Arch Linux に戻る を見てください。
ユーザスペースのツールが UEFI 変数のデータを変更できない
如何なるユーザスペースツールを持ってしても UEFI 変数のデータを変更できない場合、/sys/firmware/efi/efivars/dump-* ファイルが存在するかどうかを確認してください。存在する場合、それらを削除し、再起動して再び試してみてください。
この手順でもこの問題を解決できない場合、efi_no_storage_paranoia カーネルパラメータを使用して起動してみてください(このカーネルパラメータは、UEFI 変数の書き込み/変更を妨げてしまうカーネル UEFI 変数ストレージスペースチェックを無効化します)。
efibootmgr でブートエントリを新規作成できない
カーネルと efibootmgr のバージョンの組み合わせによっては、ブートエントリの新規作成ができなるなるかもしれません。これは NVRAM の空き領域の不足によるものであることがあります。#ユーザスペースのツールが UEFI 変数のデータを変更できない の解決策を試すことができます。
また、efibootmgr をバージョン 0.11.0 までダウングレードしてみることもできます。このバージョンは Linux バージョン 4.0.6 で機能します。詳細はバグのディスカッション FS#34641、特に closing comment を見てください。
UEFI モードで Windows 7 が起動しない
Windows を GPT パーティションの別のハードディスクにインストールしていてコンピュータに MBR でパーティションされたハードディスクを接続している場合、UEFI BIOS が (MBR パーティションを起動するための) CSM サポートを起動しているせいで Windows が起動できなくなっている可能性があります。解決するには MBR ハードディスクを GPT パーティションに結合するか、MBR ハードディスクが接続されている SATA ポートを無効化する、もしくはハードディスクから SATA コネクタを抜いて下さい。
この問題が起こるマザーボード:
- Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS バージョン F19e)
- UEFI を起動するための UEFI BIOS オプションだけでは UEFI BIOS による CSM の起動を阻止できません
Windows によってブート順序が変わってしまう
Windows と Arch のデュアルブートをしていて、マザーボードがあなたの選んだ EFI アプリケーションではなく Windows を即座に起動する場合、いくつかのあり得る原因と回避策があります。
- 高速スタートアップが Windows の電源オプションで無効化されていることを確認してください。
- セキュアブートがファームウェアで無効化されていることを確認してください(署名済みのブートローダを使用していない場合)。
- UEFI のブート順序で Windows Boot Manager が1番めに設定されていないことを確認してください(例: efibootmgr を使用)。一部のマザーボードは、Windows によって efibootmgr を使って設定したものを検出するとデフォルトで上書きします。これは Packard Bell ノート PC で確認されています。
- マザーボードがデフォルトブートパス (
\EFI\BOOT\BOOTx64.EFI) を起動する場合、このファイルは Windows ブートローダで上書きされる場合があります。efibootmgr などを使用して、正しい
ブートパスを設定してみてください。
- 前の手順でうまく行かなかった場合、Windows ブートローダに異なる EFI アプリケーションを実行するように指示することができます。Windows 管理者コマンドプロンプトから
bcdedit /set "{bootmgr}" path "\EFI\path\to\app.efi"。 - または、
efibootmgr -A -b bootnumberを root として実行することで Windows Boot Manager を無効化する。bootnumberの部分は実際の Windows Boot Manager のブート番号に置き換えてください。efibootmgrをオプション足で実行することでブート番号を確認できます。 - または、Windows を起動するたびにブート順序が正しく設定されているかを確認するスタートアップスクリプトを Windows で設定することができます。
- 管理者権限でコマンドプロンプトを開き、
bcdedit /enum firmwareを実行して、お望みのブートエントリを見つけてください。 - カッコも含めて識別子をコピーしてください。例:
{31d0d5f4-22ad-11e5-b30b-806e6f6e6963} - 次のコマンドを含むバッチファイルを作成してください:
bcdedit /set "{fwbootmgr}" DEFAULT "{コピーしたブート識別子}" - gpedit.msc を開き、Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) にある Startup をクリックしてください。
- Scripts タブに行き、Add ボタンをクリックし、そのバッチファイルを選択してください。
- 管理者権限でコマンドプロンプトを開き、
- または、Windows でスタートアップするクリプトを実行するためにタスクスケジューラを使用することができます:
- 上記の1から3の手順に従って、バッチファイルを作成してください。
- taskschd.msc を実行し、Action メニュから Create Task... を選んでください。
- General タブで:
- 適当な任意の Name と Description を入力してください。
- 選択したユーザアカウントが "Administrator" (管理者)であることを確認してください。"Standard User" であってはなりません。
- "Run whether user is logged in or not" を選択してください。
- "Run with highest privileges" を選択してください。
- Triggers タブで、メニューから "At startup" を選択して、その後 OK を押してください。
- Actions タブで、New... をクリックし、Browse... をクリックし、手順1 で作成したバッチファイルを選択してください。
- Conditions tab タブで、Power オプションのチェックを解除してください。そうすれば、バッテリ駆動時にスクリプトが実行されます(ラップトップの場合)。
- OK をクリックして、パスワードのプロンプトが表示された場合は手順4で選択したユーザアカウントのパスワードを入力してください。
USB メディアが黒画面で固まる
この問題は KMS の問題によって起こることがあります。USB を起動するときは KMS を無効化してみて下さい。
ファームウェアのメニューに UEFI ブートローダーが表示されない
一部のファームウェアはカスタムのブートエントリをサポートしていません。そのようなファームウェアはハードコードされたブートエントリからしか起動しません。
典型的な回避策は、NVRAM のブートエントリに頼るのではなく、EFI システムパーティション内の共通フォールバックパスの一つにブートローダーをインストールすることです。
以下のセクションではそのフォールバックパスについて説明しています。
リムーバブルドライブのデフォルトブートパス
UEFI 仕様では、リムーバブルメディアから起動するための EFI バイナリのデフォルトファイルパスが定義されています。関連するものとしては:
esp/EFI/BOOT/BOOTx64.EFI- x86_64 UEFI 用esp/EFI/BOOT/BOOTIA.EFI- IA32 UEFI 用
仕様では、これらはリムーバブルドライブのみ用であると定義されている一方、ほとんどのファームウェアはこれらの起動をすべてのドライブでサポートしています。
ブートローダーをデフォルト/フォールバックブートパスにインストール/統合する方法については適切なブートローダーの記事を見てください。
Microsoft Windows ブートローダの場所
Itenl Z77 チップセット搭載の一部のボードのような特定の UEFI マザーボードでは、UEFI シェルから efibootmgr/bcfg を使用してエントリを追加することができません。NVRAM に追加したあとにエントリがブートメニューに表示されないためです。
この問題はマザーボードが Microsoft Windows しか読み込めないため発生します。これを解決するには、Windows が使用する場所に .efi ファイルを配置する必要があります。
Arch Linux インストールメディア(FSO:) からハードドライブ(FS1:)上の ESP パーティション内の Microsoft ディレクトリへ BOOTx64.EFI ファイルをコピーしてください。EFI シェルを起動し、以下を実行してください:
Shell> mkdir FS1:\EFI\Microsoft Shell> mkdir FS1:\EFI\Microsoft\Boot Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi
再起動後、NVRAM に追加したエントリがブートメニュに表示されるはずです。
ハードウェアが変更された後や他のオペレーティングシステムを起動した後にシステムが EFI シェルに入る
EFI は状態をマザーボード上に格納します(EFIVARS と呼ばれます)。ブートローダー(例: GRUB)は、場合によっては起動するためにその変数を特定の方法でセットアップする必要があります。あなたのハードウェア構成が変更されたり、マザーボードが交換されたり、これらの変数を上書きする他の OS (Windows) を起動したりした場合、EFI シェルや(あなたのデバイスがリストに無い)ブートメニューに入る場合があります。Arch Linux を起動しようとしても、EFIVARS が正しくないので、EFI がブートローダを見つけることができません。
この時点で、ブートローダを手動で見つける/起動させるために EFI シェルを使用することができます。通常、以下のように:
Shell> ls fs0: EFI\ initramfs-linux.img intel-ucode.img loader\ vmlinuz-linux Shell> ls fs0:EFI\ BOOT\ Linux\ systemd Shell> ls fs0:EFI\BOOT\ BOOTx64.EFI Shell> fs0:EFI\BOOT\BOOTx64.EFI Starting fs0:EFI\BOOT\BOOTx64.EFI...
EFI シェルに再び入らないようにするために、デフォルトの EFI ブートパスにブートローダをインストールすることができます。GRUB の grub-install を使ってこれを行う場合、GRUB#デフォルト/フォールバックのブートパス を見てください。
「デフォルト/フォールバックのブートパス」の方法がうまく行く保証はありません。一部のボードファームウェア(例: AsRock C2550D4I、C2750D4I)はリムーバブルドライブのデフォルトパスしか検索/ブートしません。非リムーバブルドライブ(例: 内部 HDD、NVMe, etc)から起動するには、efivars を修復する必要があります。例えば、efibootmgr を使用して:
# efibootmgr --create --disk /dev/nvme0n1 --label "Arch Linux" --loader /vmlinuz-linux --unicode "root=PARTUUID=cd3a4f01-035a-25e3-b1ac-ea834e75aac1 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img" --verbose
efibootmgr で作成したブートエントリが UEFI に表示されない
efibootmgr は EDD 3.0 の検出に失敗する可能性があり、その結果、NVRAM に利用不可能なブートエントリを作成してしまいます。詳細は efibootmgr issue 86 を見てください。
これを回避するには、ブートエントリを手動で作成する際に、-e 3 オプションを efibootmgr コマンドに追加してください。例:
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose -e 3
grub-install や refind-install のようなブートローダインストーラを修復するには、/usr/local/bin/efibootmgr ラッパースクリプトを作成し、それを実行可能にしてください:
/usr/local/bin/efibootmgr
#!/bin/sh exec /usr/bin/efibootmgr -e 3 "$@"
UEFI ブートエントリが、参照するドライブを取り外すと消える
一部のファームウェアは、参照されているドライブが起動中に存在しない場合、そのブートエントリを削除します。これは、ドライブを頻繁に取り付け/取り外ししたり、リムーバブルドライブから起動する際に問題となりえます。
解決策は、ブートローダーをデフォルト/フォールバックブートパスにインストールすることです。
参照
- Wikipedia:ja:UEFI
- UEFI Forum - 公式の UEFI の仕様書 - GUID Partition Table は UEFI の仕様に含まれています
- UEFI boot: how does that actually work, then? - AdamW によるブログ記事
- Linux カーネル x86_64 UEFI ドキュメント
- Intel の EFI に関するページ
- Intel Architecture Firmware Resource Center
- Matt Fleming - The Linux EFI Boot Stub
- Matt Fleming - Accessing UEFI Variables from Linux
- Rod Smith - Linux on UEFI: クイックインストールガイド
- 一部の新しいマシンでの UEFI ブート問題 (LKML)
- LPC 2012 Plumbing UEFI into Linux
- LPC 2012 UEFI チュートリアル : part 1
- LPC 2012 UEFI チュートリアル : part 2
- Intel の Tianocore プロジェクト 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
- FGA: The EFI boot process
- Microsoft の Windows と GPT の FAQ
- 再インストールせずに Windows x64 を BIOS-MBR モードから UEFI-GPT モードに移行
- Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成
- Rod Smith - A BIOS to UEFI Transformation
- - Intel ドキュメント
- UEFI Shell - Intel ドキュメント
- UEFI Shell - bcfg コマンドの情報
- The bootstrap process on EFI systems