「Unified Extensible Firmware Interface」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(1版 をインポートしました)
(5人の利用者による、間の80版が非表示)
1行目: 1行目:
[[Category:Boot process (日本語)]]
+
[[Category:ブートプロセス]]
 
[[en:Unified Extensible Firmware Interface]]
 
[[en:Unified Extensible Firmware Interface]]
 
[[es:Unified Extensible Firmware Interface]]
 
[[es:Unified Extensible Firmware Interface]]
 
[[it:Unified Extensible Firmware Interface]]
 
[[it:Unified Extensible Firmware Interface]]
 
[[ru:Unified Extensible Firmware Interface]]
 
[[ru:Unified Extensible Firmware Interface]]
[[zh-CN:Unified Extensible Firmware Interface]]
+
[[zh-hans:Unified Extensible Firmware Interface]]
{{Related articles start (日本語)}}
+
{{Related articles start}}
  +
{{Related|Arch ブートプロセス}}
{{Related2|Arch Boot Process (日本語)|Arch Boot Process}}
 
{{Related2|Master Boot Record (日本語)|Master Boot Record}}
+
{{Related|Master Boot Record}}
  +
{{Related|EFI システムパーティション}}
{{Related2|GUID Partition Table (日本語)|GUID Partition Table}}
 
  +
{{Related|GUID Partition Table}}
  +
{{Related|セキュアブート}}
  +
{{Related|Unified カーネルイメージ}}
 
{{Related articles end}}
 
{{Related articles end}}
   
  +
[https://www.uefi.org/ Unified Extensible Firmware Interface] (UEFI、EFI の後継) はオペレーティングシステムとファームウェア間のインターフェイスです。オペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。
'''Unified Extensible Firmware Interface''' (もしくは省略して UEFI) は新しいタイプのファームウェアで、もともとは Intel によって Itanium を使ったシステム用に設計されました (その時の名前は EFI)。UEFI は [[Wikipedia:ja:BIOS|BIOS]] システムで一般的に使われている "[[Master Boot Record (日本語)|MBR]] ブートコード" メソッドとは異なる新しい OS 起動方法を取り入れています。Intel によって EFI がバージョン 1.x としてリリースされたのに始まり、それから UEFI Forum という業界団体によって開発が引き継がれ、Unified EFI という名前でバージョン 2.0 がリリースされました。2013年7月24日現在、UEFI の仕様は 2.4 が一番新しいバージョンです (2013年6月11日にリリース)。
 
   
  +
UEFI は [[Wikipedia:ja:BIOS|BIOS]] システムで一般的に使われている "[[Master Boot Record|MBR]] ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては [[Arch ブートプロセス]] を見てください。UEFI ブートローダをセットアップするには [[ブートローダー]] を見てください。
{{Note|
 
* このページでは UEFI ブートローダの設定は説明しません。そのような情報は[[Boot Loaders (日本語)|ブートローダー]]を見て下さい。
 
* EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。また、以下の手順は明白に書かれている部分を除き、一般的なものであり、場合によっては手順のいくつかは Mac では動かなかったり違っていたりする可能性があります。Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。}}
 
   
  +
{{Note|初期のベンダー UEFI 実装は BIOS のものよりも多くのバグを含んでいる場合があります。そのようなシステムで解決不可能な問題に直面した場合は、レガシー BIOS を使用して起動することを検討してください。}}
== BIOS ==
 
   
  +
== UEFI のバージョン ==
BIOS (Basic Input-Output System) はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラム(ファームウェア)です。ほとんどの場合マザーボード上のフラッシュメモリに保存されており、システムのストレージとは独立しています。BIOS は BIOS のディスク順で一番最初のディスクから最初の 440 バイト ([[Master Boot Record (日本語)|Master Boot Record]]) を起動します。440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、通常は [[GRUB (日本語)|GRUB]], [[Syslinux (日本語)|Syslinux]], [[LILO]] などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。詳しくは [[Arch Boot Process (日本語)|Arch ブートプロセス]]を参照してください。
 
   
  +
* UEFI は Intel の EFI としてバージョン 1.x で始まりました。
== UEFI ==
 
  +
* その後、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 を対象としており、場合によっては手順のいくつかは [[MacBook|Apple Mac]] では動かなかったり違っていたりする可能性があります。
   
  +
最新の UEFI 仕様は https://uefi.org/specifications にて確認できます。
UEFI は分かりやすいファイルシステムとパーティションテーブル、その両方の読み込みをサポートしています。従って BIOS 環境であったような 440 バイトのコード制限 (MBR ブートコード) は存在しません。
 
   
  +
== UEFI ファームウェアのビット数 ==
一般的に使われている UEFI ファームウェアは MBR と GPT 両方のパーティションテーブルをサポートしています。Apple-Intel Mac の EFI は MBR と GPT のほかに Apple Partition Map もサポートしていることが知られています。ほとんどの UEFI ファームウェアは HDD 内の FAT12 (フロッピーディスク)、FAT16 と FAT32 ファイルシステムへのアクセスと CD/DVD 内の ISO9660 (と UDF) へのアクセスをサポートしています。Apple-Intel Mac の EFI はそれらに加えて HFS/HFS+ ファイルシステムへのアクセスができます。
 
   
  +
UEFI においては、すべてのプログラムは OS ローダーであろうとユーティリティ(メモリテストやリカバリツール)であろうと、UEFI ファームウェアのビット数/アーキテクチャに対応する EFI アプリケーションである必要があります。
MBR にブートコードがあろうとなかろうと UEFI はそれを実行しません。かわりに、UEFI は "EFI SYSTEM PARTITION" という名前のパーティションテーブル内の特別なパーティションを使います、そしてその中にファームウェアによって起動するために必要なファイルが保存されています。各ベンダーは {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} フォルダの下にそのファイルを置きます。そしてファームウェアやシェル (UEFI シェル) を使ってブートプログラムを実行できます。EFI システムパーティションは (大抵) FAT32 もしくは FAT16 でフォーマットされています。
 
   
UEFI では、OS ローダーであろうとユーティリティ (メモリテストアプリやリカバリツール) であろうと、全てのプログラムは EFI ファームウェアアーキテクチャに対応する UEFI アプリケーションでなくてはなりません。最近の Apple Mac を含む、市場に出ているほとんどの UEFI ファーウェアx86_64 EFI ファームウェアを使っています。IA32 (32ビット) EFI を使ているデバイスは古い (2008年以前) Apple Mac と最近の Intel Cloverfield を使っている ultrabook だけです。また古い Intel Server ボートには Intel EFI 1.10 ファームウェアを使っているがあります。
+
最近の Apple Mac を含む x86_64 システの大部分x64 (64 ビット) UEFI ファームウェアを使用します。IA32 (32ビット) の UEFI を使うことが知られているデバイスは古い(2008年以前) Apple Mac Intel Atom System-on-Chip システム(2013年11月2日現在)[https://web.archive.org/web/20201224150025/https://software.intel.com/content/www/us/en/develop/blogs/why-cheap-systems-run-32-bit-uefi-on-x64-systems.html]そして Intel EFI 1.10 ファームウェア上で動作することが知られている一部古い Intel のサーバーボードだけです。
   
x86_64 バージョンの Linux や Windows とは異なり、x86_64 の EFI ファームウェアは 32 ビットの EFI アプリを実行することができません。従って UEFI アプリケーションはファームウェアのアーキテクチャにあわせて正しくコンパイルされている必要がありま
+
x64 UEFI ファームウェアは 32ビットの EFI アプリケーションの起動サポートしません(x86_64 Linux とそのようなサポートを含む Windows のバージョン とは違って)。それゆえ、EFI アプリケーションは特定のファームウェアプロセッサビット数/アーキテクチャにコンパイルされなければなりません
   
  +
{{Note|IA32 UEFI のシステムでは、異なるモードでの起動をサポートするブートローダを使用する必要があります。例えば、[[systemd-boot]] などです。}}
=== UEFI のブートプロセス ===
 
   
  +
{{Warning|{{Pkg|grub}} 2:2.06.r566.g857af0e17-1 から、GRUB の {{ic|i386-efi}} ターゲットは壊れており、IA32 UEFI でブートするために使用することはできません。{{Bug|79098}} を参照してください。}}
# システムのスイッチが入る - POST (Power On Self Test) プロセス
 
# UEFI ファームウェアがロードされます。ファームウェアは起動に必要なハードウェアを初期化します
 
# 次にファームウェアはブートマネージャのデータを読み込みどの UEFI アプリケーションをどこから (つまりどのディスク・パーティションから) 起動するか決定します
 
# ファームウェアのブートマネージャのブートエントリに定義されているように UEFI アプリケーションをファームウェアが起動します
 
# 起動した UEFI アプリケーションは設定によって他のアプリケーション (UEFI シェルや rEFInd の場合) やカーネルと initramfs (GRUB などのブートローダの場合) を起動します
 
   
  +
=== UEFI ファームウェアのビット数を調べる ===
{{Note|UEFI 環境によってはブート時に UEFI アプリケーションを起動する唯一の方法が (UEFI ブートメニューでカスタムエントリがない場合) 指定位置にアプリケーションを配置することです: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (64ビットの x86 環境)}}
 
   
  +
ファームウェアのビット数は起動されたオペレーティングシステムから確認できます。
=== UEFI のマルチブート ===
 
   
  +
==== Linux で ====
OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるために[[Boot Loaders (日本語)|ブートローダ]]のロード機構に頼る必要はなくなります。
 
 
==== Microsoft Windows のブート ====
 
 
Windows Vista (SP1+) や 7、8 の x86_64 版は UEFI ファームウェアを使った起動をネイティブでサポートしています。Windows は使われているファームウェアによってパーティションタイプを強制します。Windows が UEFI モードで起動されているときは、GPT ディスクにしかインストールできません。Windows が Legacy BIOS モードで起動されているときは、MBR ディスクにしかインストールできません。これは Windows のインストールによる制限です。したがって Windows は UEFI-GPT ブートか BIOS-MBR ブートのどちらかしかサポートしておらず、UEFI-MBR や BIOS-GPT はサポートしていません。
 
 
Windows のような制限は Linux カーネルには存在しませんが、使用するブートローダによっては制限が存在します。ただし同じディスクから Windows と Linux を起動したい時はブートローダ自体を使っているファームウェアとディスクパーティションに設定する必要があるので Windows の制限を考慮しなくてはなりません。同じディスクで Windows と Linux のデュアルブートをする場合、Windows によって使われている UEFI-GPT か BIOS-MBR のどちらかの方法に従うことを推奨します。
 
 
32ビットの Windows は BIOS-MBR ブートだけをサポートしています。従って、32ビットの Windows と Linux を同じディスクから起動するときは、使えるディスクは MBR だけです。詳しくは http://support.microsoft.com/kb/2581408 を見て下さい。
 
 
=== UEFI ファームウェアのビット数を調べる ===
 
   
  +
Linux カーネル 4.0 以上が走るディストリビューションでは、UEFI ファームウェアのビット数は sysfs インターフェイスを通して確認できます。以下を実行してください:
==== Mac でない場合 ====
 
   
  +
$ cat /sys/firmware/efi/fw_platform_size
{{ic|/sys/firmware/efi}} ディレクトリが存在するかどうか確認してください。存在するときはカーネルは EFI モードで起動されています。この場合 UEFI のビット数はカーネルのビット数と同じです (i686 か x86_64)。
 
   
  +
このコマンドは、64ビット (x64) UEFI の場合は {{ic|64}}、32ビット(IA32) UEFI の場合は {{ic|32}} を返します。このファイルが存在しない場合は [[インストールガイド#起動モードの確認|UEFI モードで起動]]していないということです。
{{Note|Intel Atom System-on-Chip システムには 32-bit UEFI が載っています (2013年11月2日現在)。詳細は[[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|このページ]]を見て下さい。}}
 
   
==== Apple Mac ====
+
==== macOS ====
   
2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年以降の Mac のファームウェアはほとんど x86_64-efi です。Mac OS X Snow Leopard を動かすことのできる全ての Mac は x86_64 EFI 1.x ファームウェアを使っています。
+
2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年以降の Mac のファームウェアはほとんど x64 EFI です。Mac OS X Snow Leopard を動かすことのできる全ての Mac は x64 EFI 1.x ファームウェアを使っています。
   
 
Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください:
 
Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください:
   
ioreg -l -p IODeviceTree | grep firmware-abi
+
$ 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 の仕様に完全には準拠していないからです。
+
コマンドの返事が {{ic|EFI32}} なら、IA32 (32ビット) EFI 1.x ファームウェアです。{{ic|EFI64}} と返ってくるなら、x64 EFI ファームウェアです。ほとんどの Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI 2.x の仕様に完全には準拠していないからです。
   
=== Secure Boot ===
+
==== Microsoft Windows で ====
   
  +
64ビット Windows は 32ビット UEFI からの起動をサポートしていません。なので、UEFI モードで 32ビット Windows を起動している場合は 32ビット UEFI を使用しているということになります。
Linux における Secure Boot の概要については http://www.rodsbooks.com/efi-bootloaders/secureboot.html を見て下さい。このセクションでは Arch Linux で Secure Boot を設定する方法に焦点を置いています。さしあたり Secure Boot が有効になったまま archiso を起動する手順だけを説明しています。
 
EFI アプリケーション ''PreLoader.efi'' と ''HashTool.efi'' が archiso に追加されたことで Secure Boot を有効にして archiso を起動することが可能になりました。{{ic|Failed to Start loader... I will now execute HashTool}} というメッセージが表示されます。HashTool を使って ''loader.efi'' と ''vmlinzu.efi'' のハッシュを登録するには、以下の手順に従って下さい。
 
* {{ic|OK}} を選択してください
 
* HashTool のメインメニューから {{ic|Enroll Hash}} を選択し、{{ic|\loader.efi}} を選んで {{ic|Yes}} で確定します。また、{{ic|Enroll Hash}} と {{ic|archiso}} を選択して archiso のディレクトリに入り、{{ic|vmlinuz-efi}} を選んで {{ic|Yes}} で確定してください。それから {{ic|Exit}} を選択してブートデバイスの選択メニューに戻って下さい。
 
* ブートデバイスの選択メニューから {{ic|Arch Linux archiso x86_64 UEFI CD}} を選択して下さい
 
archiso が起動し、シェルプロンプトが表示され、自動的に root でログインがされます。archiso が Secure Boot で起動しているかどうか確認するには、次のコマンドを使って下さい:
 
   
  +
ビット数を調べるには {{ic|msinfo32.exe}} を実行してください。''システムの要約''を開き、"システムの種類"と"BIOS モード"の値を見てください。
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data
 
   
  +
64ビット UEFI 上で動作している 64ビット Windows では {{ic|システムの種類: x64-ベース PC}}、{{ic|BIOS モード: UEFI}} となります。32ビット UEFI 上で動作する 32ビット Windows では {{ic|システムの種類: x86-ベース PC}}、{{ic|BIOS モード: UEFI}} となります。もし、"BIOS モード" が {{ic|UEFI}} でない場合、Windows は UEFI モードで起動していないということです。
このコマンドで 1 が返ってきたら Secure Boot で起動しています。1234 という所はマシンによって異なっています。タブ補完を使ったり efi 変数を表示することで調べることができます。
 
   
 
== UEFI の Linux カーネル設定オプション ==
 
== UEFI の Linux カーネル設定オプション ==
   
UEFI システムのために必要な Linux カーネル設定オプションは:
+
UEFI システムのために必要な Linux カーネル設定オプション[https://docs.kernel.org/arch/x86/x86_64/uefi.html]は:
   
 
CONFIG_RELOCATABLE=y
 
CONFIG_RELOCATABLE=y
 
CONFIG_EFI=y
 
CONFIG_EFI=y
 
CONFIG_EFI_STUB=y
 
CONFIG_EFI_STUB=y
  +
CONFIG_X86_SYSFB=y
CONFIG_FB_EFI=y
 
  +
CONFIG_FB_SIMPLE=y
 
CONFIG_FRAMEBUFFER_CONSOLE=y
 
CONFIG_FRAMEBUFFER_CONSOLE=y
   
UEFI Runtime Variables Support ('''efivarfs''' フルシテム - {{ic|/sys/firmware/efi/efivars}})。このオプションは {{ic|/usr/bin/efibootmgr}}ツール使って UEFI ランタイム変数を操作する必要なので重要です。次の設定オプションはカーネル 3.10 以上で追加れてます
+
UEFI Runtime Variables Support (古い '''efivars sysfs''' インターイス - {{ic|/sys/firmware/efi/vars}})。このオプションは efivars と sysfs-efivars がともに有効場合潜在的な問題回避するため無効してください。
 
CONFIG_EFIVAR_FS=y
 
 
UEFI Runtime Variables Support (古い '''efivars sysfs''' インターフェイス - {{ic|/sys/firmware/efi/vars}})。このオプションは無効にしてください。
 
   
 
CONFIG_EFI_VARS=n
 
CONFIG_EFI_VARS=n
   
GUID Partition Table [[GUID Partition Table (日本語)|GPT]] 設定オプション - UEFI サポートのために必須
+
[[GUID Partition Table]] (GPT) 設定オプション - UEFI サポートのために必須
   
 
CONFIG_EFI_PARTITION=y
 
CONFIG_EFI_PARTITION=y
   
  +
EFI mixed-mode サポート - IA32 UEFI で x86_64 カーネルを起動するのに必要:
{{Note|Linux を UEFI で起動するには上記のオプション全てが必要です。公式リポジトリの Archlinux カーネルでは有効になっています。}}
 
   
  +
CONFIG_EFI_MIXED=y
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt より。
 
  +
  +
{{Tip|すべての[[カーネル#公式サポートカーネル|公式サポートカーネル]]で上記のオプションはすべて適切に設定されています。}}
   
 
== UEFI 変数 ==
 
== UEFI 変数 ==
   
 
UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:
 
UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:
$ efivar -l
 
   
  +
$ efivar --list
=== Linux カーネルでの UEFI 変数のサポート ===
 
   
Linux カーネルは2つインターフェイスを使って EFI 変数のタをユーザ空間に渡します:
+
=== Linux カーネルUEFI 変数のサポト ===
   
# 新しい '''efivarfs''' インターフェイス ({{ic|efivarfs}} カーネルモジュールによって {{ic|/sys/firmware/efi/efivars}} にマウントされます) は sysfs-efivars インターフェイスの限界を越えるために作られました。変数のサイズ制限を取り払って、UEFI Secure Boot 変数をサポートしておりカーネルの上流から使用を推奨されています。カーネル 3.8 から導入され、カーネル 3.10 では {{ic|efivars}} カーネルモジュールから {{ic|efivarfs}} モジュールは分割されてい
+
Linux カーネルは '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) インターフェイスを通して UEFI 変数のデータをユーザスペースに公開します({{ic|CONFIG_EFIVAR_FS}})。このインターフェイスは {{ic|efivarfs}} カーネルモジュールを使って {{ic|/sys/firmware/efi/efivars}} にマウントされます。変数ごと最大サイズ制限は無く、UEFI Secure Boot 変数をサポートします。これはカーネル 3.8 導入されました
# 古い sysfs-efivars インターフェイス ({{ic|efivars}} カーネルモジュールによって {{ic|/sys/firmware/efi/vars}} に生成されます) には変数のサイズ制限などがあり、上流のカーネルではサポートされていますが Arch の公式カーネルでは完全に無効になっています。
 
 
==== efivarfs と sysfs-efivars の不一致 ====
 
 
sysfs-efivars と efivarfs は同時に実行することが可能ですが、データを同時に修正した時、sysfs-efivars と efivarfs のデータに不一致が生じるおそれがあります (詳しくは https://lkml.org/lkml/2013/4/16/473 を見て下さい)。core/{{pkg|linux}} 3.11 と core/{{Pkg|linux-lts}} 3.10 から sysfs-efivars は無効になりました (これは Arch のカーネルでの変更です、上流では sysfs-efivars のコードは削除されていません)。Arch では、efivarfs だけがサポートされています。[[Official Repositories (日本語)|公式リポジトリ]]にある UEFI 変数に関連したツールは全て efivarfs をサポートしています (2013年10月1日現在)。
 
 
{{Note|sysfs-efivars を無効化した副作用として、Arch の公式カーネルでは {{ic|efi_pstore}} モジュールも無効になっています。}}
 
 
両方のインターフェイスが有効になっている場合、片方を無効化する必要があり、ユーザー空間のツールを使って EFI VAR データにアクセスする前にインターフェイスを一度無効化してから再度有効にすることでデータを更新してください。
 
 
sysfs-efivars を無効化して efivarfs を更新するには:
 
# modprobe -r efivars
 
# umount /sys/firmware/efi/efivars
 
# modprobe -r efivarfs
 
# modprobe efivarfs
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
 
 
efivarfs を無効化して sysfs-efivars を更新するには:
 
# umount /sys/firmware/efi/efivars
 
# modprobe -r efivarfs
 
# modprobe -r efivars
 
# modprobe efivars
 
   
 
=== UEFI 変数のサポートを正しく動作させるための必要条件 ===
 
=== UEFI 変数のサポートを正しく動作させるための必要条件 ===
   
  +
# カーネルが [[EFISTUB]](任意で [[ブートマネージャー]])を通して、または[[ブートローダー]]によって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
 
# EFI Runtime Services サポートがカーネルに存在する必要があります ({{ic|1=CONFIG_EFI=y}})。{{ic|zgrep CONFIG_EFI /proc/config.gz}} で確認できます。
 
# EFI Runtime Services サポートがカーネルに存在する必要があります ({{ic|1=CONFIG_EFI=y}})。{{ic|zgrep CONFIG_EFI /proc/config.gz}} で確認できます。
  +
# カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり {{ic|noefi}} [[カーネルコマンドライン]]は使わないで下さい。
# カーネルのプロセッサのビット数・アーキテクチャが EFI のビット数・アーキテクチャと一致していなくてはなりません
 
  +
# {{ic|efivarfs}} ファイルシステムが {{ic|/sys/firmware/efi/efivars}} にマウントされている必要があります。マウントされていない時は下の [[#efivarfs のマウント]] セクションに従って下さい。
# カーネルは EFI モードで起動して下さい (via EFISTUB or any EFI bootloader, not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM)
 
  +
# {{ic|efivar}} はエラーを出さずに EFI 変数をリストアップ ({{ic|-l}}/{{ic|--list}} オプション) するはずです。
# カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり {{ic|noefi}} カーネルパラメータは使わないで下さい
 
# {{ic|efivarfs}} ファイルシステムが {{ic|/sys/firmware/efi/efivars}} にマウントされている必要があります。マウントされていない時は下の [[#efivarfs のマウント]] セクションに従って下さい
 
# {{ic|efivar}} はエラーを出さずに EFI 変数をリストアップ ({{ic|-l}} オプション) するはずです。出力の例は [[#UEFI 変数のサンプルリスト]] を見て下さい
 
   
 
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
 
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
   
  +
# UEFI 変数のリストアップ({{ic|efivar -l}})の際に {{ic|efivar: error listing variables: Function not implemented}} と言うメッセージが出て、かつ、システムが[[リアルタイムカーネル]]で起動する場合、[[カーネルパラメータ]]に {{ic|1=efi=runtime}} を追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。
# ユーザスペースのツールが efi 変数のデータを修正できない場合、{{ic|/sys/firmware/efi/efivars/dump-*}} ファイルが存在しているかチェックしてください。存在しているときは、ファイルを削除してから再起動してもう一度試して下さい。
 
  +
# さらなるドラブルシューティング手順は [[#ユーザスペースのツールが UEFI 変数のデータを変更できない]] を見てください。
# 上の手順で問題が修正されない場合、{{ic|efi_no_storage_paranoia}} カーネルパラメータを使って起動してカーネルの efi 変数ストレージ領域チェックを無効にしてください。これによって efi 変数の書き込み・修正が止められている可能性があります。
 
 
{{Note|{{ic|efi_no_storage_paranoia}} は必要な時だけに使い、通常のブートオプションに使用してはいけません。このカーネルコマンドライン・パラメータは NVRAM を満杯にしてマシンを文鎮化するようなことを避ける安全装置を外してしまいます。}}
 
   
 
==== efivarfs のマウント ====
 
==== efivarfs のマウント ====
   
起動 [[systemd (日本語)|systemd]] によって自動 {{ic|efivarfs}} マウントされなかった時は手動で efivarfsマウントして {{ic|efibootmgr}} などのユーザースペースツールを使うために UEFI Variable サポート有効にする必要があります:
+
{{ic|efivarfs}} が起動に[[systemd]] によって自動的に {{ic|/sys/firmware/efi/efivars}} マウントされない場合UEFI 変数''efibootmgr''ような[[#ユーザースペースツール|ユーザースペースツール]]に公開するために {{ic|efivarfs}}手動でマウントする必要があります:
   
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
   
{{Note|上のコマンドは '''chroot''' の前と後、両方で実行する必要があります。}}
+
{{Note|上のコマンドは [[chroot]] の前と後、両方で実行する必要があります。}}
 
下のように {{ic|/etc/fstab}} で起動時 {{ic|efivarfs}} を自動でマウントするように記述すると良いかもしれません:
 
   
  +
カーネルドキュメントの [https://www.kernel.org/doc/html/latest/filesystems/efivarfs.html efivarfs.html] を参照してください。
{{hc|/etc/fstab|<nowiki>
 
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0
 
</nowiki>}}
 
   
 
=== ユーザースペースツール ===
 
=== ユーザースペースツール ===
179行目: 133行目:
 
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
 
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
   
* {{App|efivar|UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)|https://github.com/vathpela/efivar|{{Pkg|efivar}} または {{AUR|efivar-git}}}}
+
* {{App|efivar|UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)|https://github.com/rhboot/efivar|{{Pkg|efivar}}}}
* {{App|efibootmgr|UEFI Firmware Boot Manager の設定を操作するツール。上流の (http://linux.dell.com/git/efibootmgr.git) efibootmgr コードは efivarfs をサポートしていません。Fedora の Peter Jones (vathpela) による efibootmgr のフォークは efivarfs と sysfs-efivars の両方をサポートしています。|https://github.com/vathpela/efibootmgr/tree/master|{{Pkg|efibootmgr}} または {{AUR|efibootmgr-git}}}}
+
* {{App|efibootmgr|UEFI Firmware Boot Manager の設定を操作するツール|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}
* {{App|uefivars|EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。2.0 は efivarfs だけをサポートしていて 1.0 は sysfs-efivars だけをサポートしています。|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}
+
* {{App|uefivars|EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}
* {{App|efitools|UEFI Secure Boot の証明書・キー・署名済みのバイナリを作成・設定するためのツール (efivarfs を必要とします)|http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/|{{AUR|efitools-git}}}}
+
* {{App|efitools|UEFI ュアブトプラットフォーム作するための UEFI ツール|https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}}}
* {{App|Ubuntu's Firmware Test Suite|Ubuntu のファームウェアテストスイート|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts}} (と {{AUR|fwts-efi-runtime-dkms}}) もしくは {{AUR|fwts-git}}}}
+
* {{App|Ubuntu's Firmware Test Suite|Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}
   
 
==== efibootmgr ====
 
==== efibootmgr ====
   
  +
{{Pkg|efibootmgr}} パッケージを[[インストール]]する必要があります。
{{Warning|Apple Mac で {{ic|efibootmgr}} を使うとファームウェアが塞がれマザーボード ROM のリセットが必要になる可能性があります。これに関して Ubuntu/Launch バグトラッカーでバグの報告があります。Mac の場合は bless コマンドだけを使って下さい。Fedora の開発者による実験的な Linux 用 "bless" ユーティリティがあります - {{AUR|mactel-boot}}。}}
 
   
 
{{Note|
 
{{Note|
* あなたの環境で {{ic|efibootmgr}} が完全に動かない場合、再起動して UEFI Shell v2 に入り {{ic|bcfg}} コマンドを使ってブートローダのブートエントリを作成してください。
+
* あなたの環境で ''efibootmgr'' が完全に動かない場合、再起動して [[#UEFI シェル]] に入り {{ic|bcfg}} コマンドを使ってブートローダのブートエントリを作成してください。
 
* {{ic|efibootmgr}} を使えない場合、UEFI BIOS によっては BIOS から直接 uefi のブートオプションを管理できることがあります。例えば、ASUS の BIOS には "Add New Boot Option" からローカルの EFI System Partition を選択して直接 EFI スタブの位置を入力できます (例えば {{ic|\EFI\refind\refind_x64.efi}})。
 
* {{ic|efibootmgr}} を使えない場合、UEFI BIOS によっては BIOS から直接 uefi のブートオプションを管理できることがあります。例えば、ASUS の BIOS には "Add New Boot Option" からローカルの EFI System Partition を選択して直接 EFI スタブの位置を入力できます (例えば {{ic|\EFI\refind\refind_x64.efi}})。
* 下のコマンドではサンプルとして {{Pkg|refind-efi}} ブートローダを使っています。
+
* 下のコマンドではサンプルとして [[rEFInd]] ブートローダを使っています。
* 上流の efibootmgr http://linux.dell.com/git/efibootmgr.git は efivarfs をサポートしていません。ただし公式の efibootmgr パッケージでは vathpela の efibootmgr が起用されており efivarfs をサポートしています。また、公式の Arch カーネルでは sysfs-efivars は完全に無効になっていて efivarfs だけをサポートしています。このセクションはあなたが efivarfs と vathpela の efibootmgr のみ使っていると仮定して書かれています。
 
 
}}
 
}}
   
  +
''efibootmgr'' を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:
起動するブートローダファイルが {{ic|/boot/efi/EFI/refind/refind_x64.efi}} だと仮定します。{{ic|/boot/efi/EFI/refind/refind_x64.efi}} は {{ic|/boot/efi}} と {{ic|/EFI/refind/refind_x64.efi}} とに分割できますが、{{ic|/boot/efi}} は EFI システムパーティションのマウントポイントで、ここでは {{ic|/dev/sdXY}} と仮定します (この {{ic|X}} と {{ic|Y}} は本当の値の代替値です - 例:- {{ic|/dev/sda1}} , X=a Y=1)。
 
   
(マウントポイントが {{ic|/boot/efi}} だとして) 実際の EFI システムパーティションの ({{ic|/dev/sdXY}} という形式の) デバイスパスを調べるには、次を実行してください:
+
# [[EFI システムパーティション]] (ESP) を含むディスク (例: {{ic|/dev/sda}} {{ic|/dev/nvme0n1}})
  +
# そのディスク上にある ESP のパーティション番号。{{ic|/dev/sda''Y''}} や {{ic|/dev/nvme0n1p''Y''}} の {{ic|''Y''}} の部分のことです。
  +
# EFI アプリケーションへのパス (ESP のルートからの相対パス)
   
  +
例えば、{{ic|/efi}} が ESP のマウントポイントである場合に {{ic|/efi/EFI/refind/refind_x64.efi}} 用のブートオプションを追加したい場合、以下を実行してください:
# findmnt /boot/efi
 
TARGET SOURCE FSTYPE OPTIONS
 
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC
 
   
  +
{{hc|$ findmnt /efi|2=
uefi 変数がカーネルでサポートされていて正しく動作していることを確認してください:
 
  +
TARGET SOURCE FSTYPE OPTIONS
  +
/efi /dev/sda1 vfat rw,flush,tz=UTC
  +
}}
   
  +
この例では、{{man|8|findmnt}} コマンドは、ESP がディスク {{ic|/dev/sda}} 上にあり、そのパーティション番号が 1 であることを示しています。EFI アプリケーションへの、ESP をルートとした相対パスは {{ic|/EFI/refind/refind_x64.efi}} となっています。故に、ブートエントリを以下のように作成することになります:
# efivar -l
 
   
  +
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode
efivar がエラーを出さずに uefi 変数を表示した時は、次に進んで下さい。エラーが出た場合、[[#UEFI 変数のサポートを正しく動作させるための必要条件]] が全て満たされているか確認してください。
 
   
  +
さらなる情報は {{man|8|efibootmgr}} または [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README efibootmgr README] を見てください。
それから efibootmgr を使って以下のようにブートエントリを作成します:
 
   
  +
{{Note|UEFI 仕様では、逆スラッシュ {{ic|\}} がパスセパレータとして使用されますが、''efibootmgr'' は自動的に UNIX スタイルの {{ic|/}} パスセパレータを変換することができます。}}
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
 
   
  +
=== UEFI 変数へのアクセスを無効化 ===
{{Note|1=UEFI はパスの区切り記号としてバックスラッシュ {{ic|\}} を使います (Windows のパスと似ています)。ただし公式の {{Pkg|efibootmgr}} パッケージはパスの区切りにスラッシュ {{ic|/}} を使う unix 形式のパスを {{ic|-l}} オプションでサポートしています。Efibootmgr はローダーのパスを変換する前に {{ic|/}} を {{ic|\}} に内部で変換します。この機能を efibootmgr に組み込む git コミットは http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 です。}}
 
   
  +
UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。実際、悪意のあるアクターがマシンの完全な制御を奪うことのできる [https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/index.html LogoFAIL] という危険な UEFI エクスプロイトが存在します。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[https://github.com/systemd/systemd/issues/2402#issuecomment-176806817]
上のコマンドにある {{ic|/boot/efi/EFI/refind/refind_x64.efi}} は {{ic|/boot/efi}} と {{ic|/EFI/refind/refind_x64.efi}} になりドライブ {{ic|/dev/sdX}} -> パーティション {{ic|Y}} -> ファイル {{ic|/EFI/refind/refind_x64.efi}} と翻訳されます。
 
 
'label' は UEFI ブートメニューで表示されるメニューエントリの名前です。この名前はユーザーが選ぶことができシステムのブートには影響がありません。詳しくは [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] を見て下さい。
 
 
FAT32 ファイルシステムは UTF-8 エンコードを使わないのでデフォルトで大文字・小文字を区別しません。上の場合ではファームウェアは小文字の 'efi' の代わりに大文字の 'EFI' を使っていますが、{{ic|\EFI\gummiboot\gummibootx64.efi}} と {{ic|\efi\gummiboot\gummibootx64.efi}} に違いはありません (ファイルシステムのエンコードが UTF-8 の場合は話が変わります)。
 
 
== EFI System Partition ==
 
 
EFI System Partition (ESP や EFISYS とも呼ばれます) は FAT32 でフォーマットされた物理パーティション (ディスクのメインのパーティションディスクで、LVM やソフトウェア RAID などとは異なります) でここから UEFI ファームウェアは UEFI ブートローダやアプリケーションを起動します。OS とは独立したパーティションであり、UEFI ブートには必須のパーティションになります。gdisk では '''EF00''' や '''ef00''' のタイプコード、GNU Parted では '''boot''' フラグが付けられます (GPT ディスクの場合のみ)。ESP の容量は 512 MiB にすることが推奨されていますが他のサイズでも問題ありません (Microsft による FAT32 の仕様によって指定された最小の FAT32 FS パーティション容量の制限よりは多くなります)。詳しくは[[Wikipedia:EFI_System_partition|ここ]]を見て下さい。
 
 
{{Note|
 
* UEFI ファームウェアによっては UEFI-MBR ブートができないため UEFI ブートでは出来るだけ GPT を使うことが推奨されます。
 
* GNU Parted では、{{ic|boot}} フラグ ({{ic|legacy_boot}} フラグとは区別されます) は MBR と GPT のディスクで異なる効果があります。MBR ディスクでは、パーティションが有効であるとマークされます。GPT ディスクでは、パーティションのタイプコードを {{ic|EFI System Partition}} のタイプに変更します。Parted には MBR ディスクでパーティションを ESP とするフラグがありません (fdisk を使えば可能です)。
 
* Microsoft のドキュメントには ESP の容量について説明があります: Advanced Format 4K Native (4-KB-per-sector) のドライブでは、FAT32 ファイルフォーマットの制限によって、最小容量は 260 MB となります。FAT32 のドライブの最小パーティションサイズはセクターサイズ (4KB) x 65527 &#61; 256 MB と計算されます。Advanced Format 512e ドライブはセクターサイズが 512 バイトだとエミュレートされているのでこの制限を受けません。512 バイト x 65527 &#61; 32 MB、これはパーティションの最小容量 100 MB よりも少ない値です。参照: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules
 
* [[EFISTUB (日本語)|EFISTUB]] の場合、カーネルと initramfs のファイルは EFI System Partition に保存する必要があります。また、EFISTUB ブートでは {{ic|/boot}} パーティションを別に作らないで ESP を {{ic|/boot}} パーティションとして使うことでシンプルにすることも可能です。}}
 
 
=== GPT でパーティションされたディスク ===
 
 
* gdisk ({{Pkg|gptfdisk}} パッケージにあります) を使ってパーティションタイプ {{ic|ef00}} か {{ic|EF00}} のパーティションを作成してください。そして {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}} を実行して FAT32 でパーティションをフォーマットしてください
 
もしくは
 
* GNU Parted で FAT32 パーティションを作成し、パーティションに {{ic|boot}} フラグ ({{ic|legacy_boot}} フラグではありません) を設定してください
 
   
  +
ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。
{{Note|次のメッセージが表示される場合 <code>WARNING: Not enough clusters for a 32 bit FAT!</code> クラスタ容量を <code>mkfs.fat -s2 -F32 ...</code> か <code>-s1</code> で減らしてください。そうしないとパーティションが UEFI によって読み込めなくなってしまいます。}}
 
   
  +
可能な方法は:
=== MBR でパーティションされたディスク ===
 
   
  +
* {{ic|efivars}} を [[fstab]] を用いて読み取り専用モードでマウントする。例えば: {{bc|efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0}}
fdisk ({{Pkg|util-linux}} パッケージにあります) を使ってパーティションタイプ {{ic|0xEF}} のパーティションを作成してください。そして {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}} を実行して FAT32 でパーティションをフォーマットしてください
 
  +
* {{ic|noefi}} [[カーネルパラメータ]]を使用して、OS から UEFI へのアクセスを完全に無効化する。
   
  +
{{Note|UEFI [[#ユーザスペースツール|ユーザスペースツール]] は UEFI 変数へのアクセスが無効化された状態では使用できないので、必要な設定をすべて前もって行っておいてください。また、UEFI 関連のコマンド(例: {{ic|systemctl reboot --firmware-setup}}) も機能しなくなります。}}
=== RAID 上に ESP を配置 ===
 
ESP を RAID1 アレイに置くことも可能ですが、データが破損する危険性があり、また、ESP を作成する際に様々な注意をする必要があります。詳しくは https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710 や https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741 を見て下さい。
 
   
 
== UEFI シェル ==
 
== UEFI シェル ==
251行目: 187行目:
 
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
 
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
   
=== UEFI シェルを入手する ===
+
=== UEFI シェルを入手する ===
   
Intel の Tianocore UDK/EDK2 Sourceforge.net プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます
+
Tianocore EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:
   
  +
* Shell v2:
* [[Arch User Repository (日本語)|AUR]] '''{{AUR|uefi-shell-svn}}''' パッケージ (推奨) - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 SVN ソースから直接コンパイル
 
  +
** Arch インストールメディアの {{ic|/shellx64.efi}}。ISO がビルドされたときの {{ic|/usr/share/edk2-shell/x64/Shell_Full.efi}} のコピーです。
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)
 
  +
** {{Pkg|edk2-shell}} パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)
 
  +
** {{AUR|uefi-shell-git}} パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)
 
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (not updated anymore upstream)
 
   
  +
* Shell v1:
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] や [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail] を見て下さい。
 
  +
** TianoCore 由来の [https://github.com/tianocore/edk2/tree/UDK2018/EdkShellBinPkg プリコンパイル済み UEFI Shell v1 バイナリ] (2014/1/10 から上流は一度もアップデートされていません)。
  +
  +
* 派生版:
  +
** [https://drive.google.com/uc?export=download&id=1OBXYj6MEs7VAZbYnjD9FxOYcZYIQoq36 プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg]{{Dead link|2023|07|30|status=403}} - Clover EFI ブートローダ由来。
  +
** [https://github.com/acidanthera/OpenCorePkg/releases 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ] - OpenCore ブートローダ由来。リリースアーカイブでは: {{ic|EFI/OC/Tools/OpenShell.efi}}。
  +
  +
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは [https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg ShellPkg] や [https://edk2-devel.narkive.com/zCN4CEnb/inclusion-of-uefi-shell-in-linux-distro-iso Inclusion of UEFI shell in Linux distro iso] を見て下さい。
   
 
=== UEFI シェルの起動 ===
 
=== UEFI シェルの起動 ===
   
Asus や AMI Aptio のマザーボード (Sandy Bridge 以) ベースの x86_64 UEFI ファームウェアに {{ic|"Launch EFI Shell from filesystem device"}}いう名前のオプションが提供されていることがあります。そういったマザーボードでは、x86_64 UEFI シェルダウンロードして EFI SYSTEM PARTITION に {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} としてコピーしてください (ほとんどの場合 {{ic|/boot/efi/shellx64.efi}})
+
数少ない Asus や他の AMI Aptio x64 UEFI ファームウェアベースのマザーボード (Sandy Bridge 以) 、''Launch EFI Shell from filesystem device''呼ばれるオプションが提供されています。これらのマザーボードでは、x64 UEFI Shell [[EFI システムパーティション]] のルートに {{ic|shellx64.efi}} という名前で コピーしてください。
  +
  +
{{Tip|
  +
* Arch Linux インストールメディアにはボリュームのルートに {{ic|shellx64.efi}} があります。
  +
* [[rEFInd]] と [[systemd-boot]] は、{{ic|shellx64.efi}} が [[EFI システムパーティション]]のルートにある場合、自動的に UEFI シェルのブートメニューエントリを追加します。
  +
}}
   
 
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており {{ic|F6}}, {{ic|F11}}, {{ic|F12}} キーのどれかで起動できます。
 
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており {{ic|F6}}, {{ic|F11}}, {{ic|F12}} キーのどれかで起動できます。
   
{{Note|上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、{{ic|(USB)/efi/boot/bootx64.efi}} としてコピーされた {{ic|Shell.efi}} FAT32 USB ペンドライブを作成してください。この USB はファームウェアブートメニューを表示するはずです。このオプションを起動することで UEFI シェルが起動されます。}}
+
{{Note|上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、{{ic|''/USB_drive_mointpoint''/EFI/BOOT/BOOTx64.EFI}} としてコピーされた EFI バイナリのある [[FAT32]] USB ペンドライブを作成してください。この USB はファームウェアブートメニューを表示するはずです。このオプションを起動することで UEFI シェルが起動されます。}}
   
 
=== 重要な UEFI シェルコマンド ===
 
=== 重要な UEFI シェルコマンド ===
   
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる {{ic|-b}} オプションをサポートしています。{{ic|map}} は認識したファイルシステム ({{ic|fs0}}, ...) やストレージデバイス ({{ic|blk0}}, ...) をリストアップします。利用できるコマンドを表示するには {{ic|help -b}} を実行してください。
+
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる {{ic|-b}} オプションをサポートしています。利用できるコマンドを表示するには {{ic|help -b}} を実行してください。
   
詳しい情報は http://software.intel.com/en-us/articles/efi-shells-and-scripting/
+
詳しい情報は [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ Intel Scripting Guide 2008]{{Dead link|2023|07|30|status=404}} と [https://software.intel.com/en-us/articles/uefi-shell Intel "Course" 2011]{{Dead link|2023|07|30|status=404}} を見てください。
   
 
==== bcfg ====
 
==== bcfg ====
   
BCFG コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては "UEFI Shell Specification 2.0" pdf ドキュメントの 83 ページ (Section 5.3) で詳しく説明されています。
+
{{ic|bcfg}} コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては [https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf UEFI Shell Specification 2.2] ドキュメントの 96 ページ (Section 5.3) で詳しく説明されています。
   
 
{{Note|
 
{{Note|
 
* {{ic|efibootmgr}} が上手くブートエントリを作成できないときだけ {{ic|bcfg}} を使うことが推奨されています。
 
* {{ic|efibootmgr}} が上手くブートエントリを作成できないときだけ {{ic|bcfg}} を使うことが推奨されています。
* UEFI Shell v1 の公式バイナリは {{ic|bcfg}} コマンドをサポートしていません。UEFI pre-2.3 ファームウェアで動作する [http://dl.dropbox.com/u/17629062/Shell2.zip 修正 UEFI Shell v2 バイナリ] ダウンロードできます
+
* UEFI Shell v1 の公式バイナリは {{ic|bcfg}} コマンドをサポートしていません。[[#UEFI シェルを入手する]] を見て、UEFI pre-2.3 ファームウェアで動作する修正された UEFI Shell v2 バイナリを入手してください
 
}}
 
}}
   
現在のブートエントリのリストを出力するには -
+
現在のブートエントリのリストを出力するには:
   
 
Shell> bcfg boot dump -v
 
Shell> bcfg boot dump -v
292行目: 239行目:
 
4番目の(番号は0から始まります)オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには:
 
4番目の(番号は0から始まります)オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには:
   
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"
+
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
   
{{ic|fs0:}} は EFI System Partition に、{{ic|\EFI\refind\refind_x64.efi}} は起動するファイルにそれぞれ適切にマッピングしてください。
+
{{ic|FS0:}} は EFI System Partition に、{{ic|FS0:\EFI\refind\refind_x64.efi}} は起動するファイルにそれぞれ適切にマッピングしてください。
  +
  +
ブートローダ無しでシステムを直接ブートするエントリを追加するには、カーネルを [[EFISTUB#bcfg|EFISTUB]] として使用してブートオプションを設定してください:
  +
  +
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"
  +
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"
  +
  +
{{ic|N}} は優先度、{{ic|V}} は EFI システムパーティションのボリューム番号、{{ic|/dev/sdX#}} はルートパーティションです。
   
 
4番目のブートオプションを削除するには:
 
4番目のブートオプションを削除するには:
312行目: 266行目:
 
Shell> bcfg -? -v -b
 
Shell> bcfg -? -v -b
   
==== edit ====
+
==== map ====
   
  +
{{ic|map}} はデバイスマッピング (つまり、利用可能なファイルシステム ({{ic|FS0}}) とストレージデバイス ({{ic|blk0}}) の名前) の一覧を表示します。
EDIT コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
 
   
  +
{{ic|cd}} や {{ic|ls}} などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります:
例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic|fs0:}})
 
   
 
Shell> fs0:
 
Shell> fs0:
FS0:\> cd \EFI\arch\refind
+
fs0:\> cd EFI/
FS0:\EFI\arch\refind\> edit refind.conf
 
   
  +
==== edit ====
ヘルプを出すには {{ic|Ctrl-E}} を押して下さい。
 
   
  +
{{ic|edit}} コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
== UEFI Linux ハードウェアの互換性 ==
 
   
  +
例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic|FS0:}})
[[HCL/Firmwares/UEFI]] を参照してください。
 
  +
  +
Shell> edit FS0:\EFI\refind\refind.conf
  +
  +
ヘルプを出すには {{ic|Ctrl+e}} を押して下さい。
  +
  +
== UEFI ドライバ ==
  +
  +
UEFI ドライバとは、なんらかの機能をサポートするためのソフトウェアのことです。例えば、NTFS でフォーマットされたパーティションは通常 UEFI シェルからアクセスできません。{{Pkg|efifs}} パッケージには、EFI シェル内から多くのファイルシステムを読み込めるようにするドライバが含まれています。使用例を挙げましょう。そのようなドライバを UEFI シェルからアクセス可能なパーティションにコピーして、UEFI シェルから以下のようなコマンドを実行します:
  +
  +
Shell> load ntfs_x64.efi
  +
Shell> map -r
  +
  +
map コマンドを実行したあと、ユーザは NTFS でフォーマットされたパーティションに UEFI シェル内からアクセスできるようになっているはずです。
  +
  +
{{Tip|
  +
* [[systemd-boot]] は {{ic|''esp''/EFI/systemd/drivers/}} から UEFI ドライバを自動的に読み込みます。
  +
* [[rEFInd]] は、ESP 上の rEFInd インストール先ディレクトリのサブディレクトリ {{ic|drivers}} と {{ic|drivers_x64}} (例: {{ic|''esp''/EFI/refind/drivers_x64/}}) から UEFI ドライブを自動的に読み込みます。他のディレクトリをスキャンするように設定することも可能です。
  +
}}
   
 
== UEFI ブータブルメディア ==
 
== UEFI ブータブルメディア ==
332行目: 303行目:
 
=== ISO から UEFI ブータブル USB を作成する ===
 
=== ISO から UEFI ブータブル USB を作成する ===
   
[[USB Installation Media (日本語)#BIOS・UEFI ブータブル USB|USB インストールメディア#BIOS・UEFI ブータブル USB]] を参照してください。
+
[[USB インストールメディア#ISO をそのまま使う (BIOS UEFI)]] を参照してください。
   
=== オプティカルメディアから UEFI ブートサポートを削除する ===
+
=== 光学メディアから UEFI ブートサポートを削除する ===
   
  +
{{Note|
{{Note|このセクションでは USB フラッシュドライブではなく '''CD/DVD''' (オプティカルメディア) から UEFI ブートサポートを削除する方法を説明しています。}}
 
  +
* このセクションでは USB フラッシュドライブではなく '''CD/DVD''' (EL Torito からブートする光学メディア) から UEFI ブートサポートを削除する方法を説明しています。
  +
* USB スティック上の UEFI 機構を隠すには、ISO をフラッシュドライブにコピーしたあとでパーティションエディタを使ってください。{{ic|EF}} タイプのパーティションを削除してください。GPT に変換するか尋ねられたときは'''いいえ'''と答えてください。
  +
}}
   
ほとんどの32ビット EFI Mac といくつかの64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。オプティカルメディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があ
+
ほとんどの32ビット EFI Mac と一部の64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。光学メディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があるかもしれせん
   
* 公式インストールメディマウントし前のセクションで示されているように {{ic|archisolabel}}取得してください
+
UEFI 特有のディレクトリ除いISO展開してください:
   
  +
$ mkdir extracted_iso
# mount -o loop ''input.iso'' /mnt/iso
 
  +
$ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-''version''-x86_64.iso -C extracted_iso
   
* {{pkg|libisoburn}} に含まれている {{ic|xorriso}} を使って UEFI Optical Media ブートサポートを除いた ISO 再生成してください (archisolabel"ARCH_201411" など適当に置き換え下さい)
+
そして、{{Pkg|libisoburn}} {{man|1|xorriso}} を使って ISO を再ビルドしてください。この時、UEFI 光学メディアのブートサポートを除いてください。正しいボリュームラベル設定してください(例えば {{ic|ARCH_202103}})。ボリュームラベル、オリジナルの ISO対し {{man|1|file}} を使うことで得られます
   
 
{{bc|1=
 
{{bc|1=
$ xorriso -as mkisofs -iso-level 3 \
+
$ xorriso -as mkisofs \
-full-iso9660-filenames\
+
-iso-level 3 \
-volid "''archisolabel''" \
+
-full-iso9660-filenames \
-appid "Arch Linux CD" \
+
-joliet \
  +
-joliet-long \
-publisher "Arch Linux <https://www.archlinux.org>" \
 
  +
-rational-rock \
  +
-volid "ARCH_''YYYYMM''" \
  +
-appid "Arch Linux Live/Rescue CD" \
  +
-publisher "Arch Linux <https://archlinux.org>" \
 
-preparer "prepared by $USER" \
 
-preparer "prepared by $USER" \
-eltorito-boot isolinux/isolinux.bin \
+
-eltorito-boot syslinux/isolinux.bin \
-eltorito-catalog isolinux/boot.cat \
+
-eltorito-catalog syslinux/boot.cat \
 
-no-emul-boot -boot-load-size 4 -boot-info-table \
 
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \
+
-isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \
-output ''output.iso'' /mnt/iso/
+
-output archlinux-''version''-x86_64-noUEFI.iso extracted_iso/
 
}}
 
}}
   
* {{ic|''output.iso''}} をオプティカルメディアに焼いて通常通りインストールに進んで下さい。
+
{{ic|archlinux-''version''-x86_64-noUEFI.iso}} を光学メディアに焼いて通常インストールを続けてください。
   
 
== ネイティブサポートのない環境で UEFI をテストする ==
 
== ネイティブサポートのない環境で UEFI をテストする ==
366行目: 345行目:
 
=== 仮想マシン用の OVMF ===
 
=== 仮想マシン用の OVMF ===
   
[https://tianocore.github.io/ovmf/ OVMF] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
+
[https://github.com/tianocore/tianocore.github.io/wiki/OVMF OVMF] は仮想マシンで UEFI サポートを有効にする TianoCore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
  +
  +
{{Pkg|edk2-ovmf}} をインストールできます。
  +
  +
仮想マシンの非揮発性変数のローカルコピーを作成することが[https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt 推奨]されています:
  +
  +
$ cp /usr/share/edk2/x64/OVMF_VARS.4m.fd my_OVMF_VARS.4m.fd
  +
  +
OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください:
  +
  +
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd \
  +
-drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd
   
  +
例えば:
AUR {{AUR|ovmf-svn}} から OVMF (Secure Boot サポート付き) をビルドして次のように実行することができます:
 
   
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -pflash /usr/share/ovmf/x86_64/bios.bin
+
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd -drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd …
   
=== BIOS システム用の DUET ===
+
=== BIOS システム用の DUET ===
   
DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする tianocore プロジェクトです。この方法については http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ で広く議論されています。ビルド済み DUET イメージは https://gitorious.org/tianocore_uefi_duet_builds にあるリポジトリからダウンロードできます。DUET を設定する手順 https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt にあり
+
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 リポジトリ]{{Dead link|2023|04|07|status=404 Page Not Found}}のどれかからダウンロードできます。DUET をセットアップする特定の方法について、特定の[https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt 指示]{{Dead link|2023|04|07|status=404 Page Not Found}}を読んでください。しかし、2018年11月 DUET のコードが TianoCore git リポジトリから削除されした
   
また、修正 DUET イメージを提供する http://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の fix が含まれており gitorious リポジトリと比べて頻繁に更新されています。
+
また、修正 DUET イメージを提供する [[Clover]] を試すことも可能です。特定環境の修正が含まれており gitlab リポジトリと比べて頻繁に更新されています。
   
 
== トラブルシューティング ==
 
== トラブルシューティング ==
   
  +
=== Windows で固まった際に Arch Linux に戻る ===
=== UEFI モードで Windows 7 が起動しない ===
 
   
  +
Windows で固まった際に Arch Linux に戻るには、Windows PowerShell コマンド {{ic|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" を選んでください。
Windows を GPT パーティションの別のハードディスクにインストールしていてコンピュータに MBR でパーティションされたハードディスクを接続している場合、UEFI BIOS が (MBR パーティションを起動するための) CSM サポートを起動しているせいで Windows が起動できなくなっている可能性があります。解決するには MBR ハードディスクを GPT パーティションに結合するか、MBR ハードディスクが接続されている SATA ポートを無効化する、もしくはハードディスクから SATA コネクタを抜いて下さい。
 
   
  +
=== ファンクションキー無しでファームウェアセットアップに入る ===
この問題が起こるマザーボード:
 
   
  +
[[:en:Lenovo XiaoXin 15are 2020]] のような一部のノート PC では、{{ic|F2}} や {{ic|F12}} のようなキーを使用しても何も起こりません。OEM にノート PC を返却しメインボード情報の修復を行えばおそらく修正可能ですが、時々これが不可能である、または望ましくない場合があります。しかし、ファームウェアセットアップに入る他の方法が存在します:
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS バージョン F19e)
 
   
  +
* [[systemd#電源管理|systemctl]] を使用: {{bc|$ systemctl reboot --firmware-setup}} これによりコンピュータが再起動され、ファームウェアセットアップに入ります。
- UEFI を起動するための UEFI BIOS オプションだけでは UEFI BIOS による CSM の起動を阻止できません
 
  +
* [[GRUB]] を使用: コマンドラインに入るために {{ic|c}} を押し、GRUB コマンドラインで {{ic|fwsetup}} を使用してファームウェアセットアップに入る。
  +
* Windows で: ''Advanced Startup'' に入る。[[#Windows で固まった際に Arch Linux に戻る]] を見てください。
  +
  +
=== ユーザスペースのツールが UEFI 変数のデータを変更できない ===
  +
  +
如何なるユーザスペースツールを持ってしても UEFI 変数のデータを変更できない場合、{{ic|/sys/firmware/efi/efivars/dump-*}} ファイルが存在するかどうかを確認してください。存在する場合、それらを削除し、再起動して再び試してみてください。
  +
  +
この手順でもこの問題を解決できない場合、{{ic|efi_no_storage_paranoia}} [[カーネルパラメータ]]を使用して起動してみてください(このカーネルパラメータは、UEFI 変数の書き込み/変更を妨げてしまうカーネル UEFI 変数ストレージスペースチェックを無効化します)。
  +
  +
{{Warning|{{ic|efi_no_storage_paranoia}} は必要なときにだけ使用するべきで、普段のブートオプションとして残しておくべきではありません。このカーネルコマンドラインは、NVRAM が満杯になった際にマシンが起動できなることを防止するセーフガードを無効化する効果があります。詳細は {{Bug|34641}} を見てください。}}
  +
  +
=== efibootmgr でブートエントリを新規作成できない ===
  +
  +
カーネルと ''efibootmgr'' のバージョンの組み合わせによっては、ブートエントリの新規作成ができなるなるかもしれません。これは NVRAM の空き領域の不足によるものであることがあります。[[#ユーザスペースのツールが UEFI 変数のデータを変更できない]] の解決策を試すことができます。
  +
  +
また、''efibootmgr'' をバージョン 0.11.0 まで[[ダウングレード]]してみることもできます。このバージョンは Linux バージョン 4.0.6 で機能します。詳細はバグのディスカッション {{Bug|34641}}、特に [https://bugs.archlinux.org/task/34641#comment111365 closing comment] を見てください。
   
 
=== Windows によってブート順序が変わってしまう ===
 
=== Windows によってブート順序が変わってしまう ===
  +
マザーボードによっては起動する度に Windows 8 によって NVRAM の起動順序が変わってしまうことがあります (ASRock Z77 Extreme4 で確認)。この問題は Windows Boot Manager に Windows を起動する代わりに他のローダーをロードしてもらうようにすれば解決できます。Windows の管理者モードのコンソールで次のコマンドを実行してください:
 
  +
[[Windows と Arch のデュアルブート]]をしていて、マザーボードがあなたの選んだ EFI アプリケーションではなく Windows を即座に起動する場合、いくつかのあり得る原因と回避策があります。
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi
 
  +
  +
* [[Windows と Arch のデュアルブート#高速スタートアップとハイバネート|高速スタートアップ]]が Windows の電源オプションで無効化されていることを確認してください。
  +
* [[セキュアブート]]がファームウェアで無効化されていることを確認してください(署名済みのブートローダを使用していない場合)。
  +
* UEFI のブート順序で Windows Boot Manager が1番めに設定されていないことを確認してください(例: [[#efibootmgr|efibootmgr]] を使用)。一部のマザーボードは、Windows によって efibootmgr を使って設定したものを検出するとデフォルトで上書きします。これは Packard Bell ノート PC で確認されています。
  +
* マザーボードがデフォルトブートパス ({{ic|\EFI\BOOT\BOOTx64.EFI}}) を起動する場合、このファイルは Windows ブートローダで上書きされる場合があります。[[#efibootmgr|efibootmgr]] などを使用して、正しい
  +
ブートパスを設定してみてください。
  +
* 前の手順でうまく行かなかった場合、Windows ブートローダに異なる EFI アプリケーションを実行するように指示することができます。Windows 管理者コマンドプロンプトから {{ic|bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}。
  +
* または、{{ic|efibootmgr -A -b ''bootnumber''}} を root として実行することで Windows Boot Manager を無効化する。{{ic|''bootnumber''}} の部分は実際の Windows Boot Manager のブート番号に置き換えてください。{{ic|efibootmgr}} をオプション足で実行することでブート番号を確認できます。
  +
* または、Windows を起動するたびにブート順序が正しく設定されているかを確認するスタートアップスクリプトを Windows で設定することができます。
  +
*# 管理者権限でコマンドプロンプトを開き、{{ic|bcdedit /enum firmware}} を実行して、お望みのブートエントリを見つけてください。
  +
*# カッコも含めて識別子をコピーしてください。例: {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}
  +
*# 次のコマンドを含むバッチファイルを作成してください: {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "''{コピーしたブート識別子}''"}}
  +
*# ''gpedit.msc'' を開き、''Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)'' にある ''Startup'' をクリックしてください。
  +
*# ''Scripts'' タブに行き、''Add'' ボタンをクリックし、そのバッチファイルを選択してください。
  +
:: 注: [https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/how-to-install-gpeditmsc-in-window-10/f5e9c4fa-8d46-444c-acd7-5cabaea9fc71 Windows 10 Home は公式には gpedit.msc を含んでいません。しかし、それを手動でインストールする、サポートされない回避策があります。]
  +
* または、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 メディアが黒画面で固まる ===
 
=== USB メディアが黒画面で固まる ===
   
* この問題は [[Kernel Mode Setting (日本語)|KMS]] の問題によって起こることがあります。USB を起動するときは [[Kernel_Mode_Setting (日本語)#モードセッティングを無効にする|KMS を無効化]]してみて下さい。
+
この問題は [[Kernel Mode Setting|KMS]] の問題によって起こることがあります。USB を起動するときは [[カーネルモード設定#モード設定を無効にする|KMS を無効化]]してみて下さい。
   
  +
=== ファームウェアのメニューに UEFI ブートローダーが表示されない ===
* 問題が KMS によるものではない場合、おそらく [[EFISTUB (日本語)|EFISTUB]] ブートのバグによる問題です (詳しくは [https://bugs.archlinux.org/task/33745] や [https://bbs.archlinux.org/viewtopic.php?id=156670] を見て下さい)。公式 ISO ([[Archiso (日本語)|Archiso]]) と [[Archboot]] iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは [[Gummiboot (日本語)|Gummiboot]] ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして [[GRUB (日本語)|GRUB]] を使って下さい。
 
   
  +
一部のファームウェアはカスタムのブートエントリをサポートしていません。そのようなファームウェアはハードコードされたブートエントリからしか起動しません。
==== GRUB の使用 ====
 
   
  +
典型的な回避策は、NVRAM のブートエントリに頼るのではなく、[[EFI システムパーティション]]内の共通フォールバックパスの一つに[[ブートローダー]]をインストールすることです。
* [[USB Installation Media (日本語)#BIOS・UEFI ブータブル USB|USB インストールメディア#BIOS・UEFI ブータブル USB]] に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。
 
   
  +
以下のセクションではそのフォールバックパスについて説明しています。
* {{ic|<USB>/EFI/boot/loader.efi}} を {{ic|<USB>/EFI/boot/gummiboot.efi}} にバックアップしてください。
 
   
  +
==== リムーバブルドライブのデフォルトブートパス ====
* [[GRUB (日本語)#GRUB_Standalone|GRUB スタンドアロンイメージを作成]]して {{ic|<USB>/EFI/boot/loader.efi}} にコピーしてください。
 
   
  +
UEFI 仕様では、リムーバブルメディアから起動するための EFI バイナリのデフォルトファイルパスが定義されています。関連するものとしては:
* 以下の内容で {{ic|<USB>/EFI/boot/grub.cfg}} を作成してください ({{ic|ARCH_YYYYMM}} は USB ディスクのラベルに置き換えて下さい、例: {{ic|ARCH_201404}}):
 
   
  +
* {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} - x64 UEFI 用
{{hc|grub.cfg for Official ISO|<nowiki>
 
  +
* {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} - IA32 UEFI 用
insmod part_gpt
 
insmod part_msdos
 
insmod fat
 
   
  +
仕様では、これらはリムーバブルドライブのみ用であると定義されている一方、ほとんどのファームウェアはこれらの起動をすべてのドライブでサポートしています。
insmod efi_gop
 
insmod efi_uga
 
insmod video_bochs
 
insmod video_cirrus
 
   
  +
ブートローダーをデフォルト/フォールバックブートパスにインストール/統合する方法については適切な[[ブートローダー]]の記事を見てください。
insmod font
 
   
  +
==== Microsoft Windows ブートローダの場所 ====
if loadfont "${prefix}/fonts/unicode.pf2" ; then
 
insmod gfxterm
 
set gfxmode="1024x768x32;auto"
 
terminal_input console
 
terminal_output gfxterm
 
fi
 
   
  +
Itenl Z77 チップセット搭載の一部のボードのような特定の UEFI マザーボードでは、UEFI シェルから {{ic|efibootmgr}}/{{ic|bcfg}} を使用してエントリを追加することができません。NVRAM に追加したあとにエントリがブートメニューに表示されないためです。
menuentry "Arch Linux archiso x86_64" {
 
set gfxpayload=keep
 
search --no-floppy --set=root --label ARCH_YYYYMM
 
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap
 
initrd /arch/boot/x86_64/archiso.img
 
}
 
   
  +
この問題はマザーボードが Microsoft Windows しか読み込めないため発生します。これを解決するには、Windows が使用する場所に ''.efi'' ファイルを配置する必要があります。
menuentry "UEFI Shell x86_64 v2" {
 
search --no-floppy --set=root --label ARCH_YYYYMM
 
chainloader /EFI/shellx64_v2.efi
 
}
 
 
menuentry "UEFI Shell x86_64 v1" {
 
search --no-floppy --set=root --label ARCH_YYYYMM
 
chainloader /EFI/shellx64_v1.efi
 
}
 
</nowiki>}}
 
   
  +
Arch Linux インストールメディア({{ic|FSO:}}) からハードドライブ({{ic|FS1:}})上の [[ESP]] パーティション内の Microsoft ディレクトリへ {{ic|BOOTx64.EFI}} ファイルをコピーしてください。EFI シェルを起動し、以下を実行してください:
{{hc|grub.cfg for Archboot ISO|<nowiki>
 
insmod part_gpt
 
insmod part_msdos
 
insmod fat
 
   
  +
Shell> mkdir FS1:\EFI\Microsoft
insmod efi_gop
 
  +
Shell> mkdir FS1:\EFI\Microsoft\Boot
insmod efi_uga
 
  +
Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi
insmod video_bochs
 
insmod video_cirrus
 
   
  +
再起動後、NVRAM に追加したエントリがブートメニュに表示されるはずです。
insmod font
 
   
  +
=== efibootmgr で作成したブートエントリが UEFI に表示されない ===
if loadfont "${prefix}/fonts/unicode.pf2" ; then
 
insmod gfxterm
 
set gfxmode="1024x768x32;auto"
 
terminal_input console
 
terminal_output gfxterm
 
fi
 
   
  +
''efibootmgr'' は EDD 3.0 の検出に失敗する可能性があり、その結果、NVRAM に利用不可能なブートエントリを作成してしまいます。詳細は [https://github.com/rhboot/efibootmgr/issues/86 efibootmgr issue 86] を見てください。
menuentry "Arch Linux x86_64 Archboot" {
 
set gfxpayload=keep
 
search --no-floppy --set=root --file /boot/vmlinuz_x86_64
 
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap
 
initrd /boot/initramfs_x86_64.img
 
}
 
   
  +
これを回避するには、ブートエントリを手動で作成する際に、{{ic|-e 3}} オプションを ''efibootmgr'' コマンドに追加してください。例:
menuentry "UEFI Shell x86_64 v2" {
 
  +
search --no-floppy --set=root --file /boot/vmlinuz_x86_64
 
  +
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode '''-e 3'''
chainloader /EFI/tools/shellx64_v2.efi
 
  +
}
 
  +
{{ic|grub-install}} や {{ic|refind-install}} のようなブートローダインストーラを修復するには、{{ic|/usr/local/bin/efibootmgr}} ラッパースクリプトを作成し、それを[[実行可能属性|実行可能]]にしてください:
 
  +
menuentry "UEFI Shell x86_64 v1" {
 
  +
{{hc|/usr/local/bin/efibootmgr|
search --no-floppy --set=root --file /boot/vmlinuz_x86_64
 
  +
#!/bin/sh
chainloader /EFI/tools/shellx64_v1.efi
 
  +
}
 
  +
exec /usr/bin/efibootmgr -e 3 "$@"
</nowiki>}}
 
  +
}}
  +
  +
=== UEFI ブートエントリが、参照するドライブを取り外すと消える ===
  +
  +
一部のファームウェアは、参照されているドライブが起動中に存在しない場合、そのブートエントリを削除します。これは、ドライブを頻繁に取り付け/取り外ししたり、リムーバブルドライブから起動する際に問題となりえます。
  +
  +
解決策は、[[ブートローダー]]を[[#リムーバブルドライブのデフォルトブートパス|デフォルト/フォールバックブートパス]]にインストールすることです。
  +
  +
=== ブートエントリがランダムに削除される ===
  +
  +
一部のマザーボードは、NVRAM の空き領域が足りない場合、ブートエントリの作成時にエラーを表示せずに、ブートエントリを削除してしまうことがあります。これを防ぐには、エントリの作成プロセスを最小限にして、追加されるブートエントリの数を減らし、さらに、UEFI 設定から [[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] を無効化して、自動ドライブブートエントリの数も減らしてください。[https://bbs.archlinux.org/viewtopic.php?pid=1608838#p1608838 BBS#1608838] を参照してください。
  +
  +
ブートエントリが削除されてしまう他の原因として、UEFI 仕様では「NVRAM メンテナンス」をブート中に実行することが OEM に許可されていることも挙げられます。そのようなメーカーのデバイスは、事前定義されハードコードされているデバイス上のパスで EFI アプリケーションを探索するだけです。何も見つけられなかった場合、デバイス上には OS が存在しないと結論づけ、NVRAM 上に破損しているまたは古いデータが存在すると推測し、そのデバイスと関連する NVRAM からすべてのブートエントリを消してしまいます。Windows をインストールする予定がなく、ファームウェアから Linux カーネルを直接ロードしたい場合、解決策として空のファイル {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} を作成するというものがあります:
  +
  +
# mkdir -p ''esp''/EFI/BOOT
  +
# touch ''esp''/EFI/BOOT/BOOTx64.EFI
  +
  +
そして、削除されたブートエントリを作り直してください。これで、再起動すれば、マザーボードは「偽のOS」を検出し、NVRAM から他のブートエントリを削除しなくなるはずです。この偽の OS ローダは実際の EFI アプリケーションに自由に変更することもできます。もちろん、標準のフォールバック名を使い続ける限りです。
   
 
== 参照 ==
 
== 参照 ==
   
 
* [[Wikipedia:ja:UEFI]]
 
* [[Wikipedia:ja:UEFI]]
* [http://www.uefi.org/home/ UEFI Forum] - 公式の [http://www.uefi.org/specs/ UEFI の仕様書] - GUID Partition Table は UEFI の仕様に含まれています
+
* [https://www.uefi.org/home/ UEFI Forum] - 公式の [https://uefi.org/specifications UEFI の仕様書] - GUID Partition Table は UEFI の仕様に含まれています
 
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - AdamW によるブログ記事]
 
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - AdamW によるブログ記事]
  +
* [https://docs.kernel.org/arch/x86/x86_64/uefi.html Linux カーネルの x86_64 プラットフォーム向け UEFI ドキュメント]
* [[Wikipedia:EFI System partition]]
 
  +
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel の EFI に関するページ]
* [http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI System Partition and the Default Boot Behavior]
 
  +
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]{{Dead link|2023|07|30|status=404}}
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux カーネル x86_64 UEFI ドキュメント]
 
  +
* [https://web.archive.org/web/20191230095118/https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
* [http://www.intel.com/technology/efi/ Intel の EFI に関するページ]
 
  +
* [https://web.archive.org/web/20190319175019/https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]
 
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
+
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: クイックインストールガイド]
  +
* [https://lore.kernel.org/lkml/20110608192950.GA29235@srcf.ucam.org/ 一部の新しいマシンでの UEFI ブート問題 (LKML)]
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]
 
  +
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: クイックインストールガイド]
 
* [https://lkml.org/lkml/2011/6/8/322 新しいマシンでの UEFI ート問題 (LKML)]
+
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1]
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]
+
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI チュートリアル : part 2]
  +
* [https://www.tianocore.org/ Intel の Tianocore プロジェクト] 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1]
 
  +
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI チュートリアル : part 2]
 
  +
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft の Windows と GPT の FAQ]
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel の Tianocore プロジェクト] 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
 
  +
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Windows_x64_BIOS_to_UEFI 再インストールせずに Windows x64 を BIOS-MBR モードから UEFI-GPT モードに移行]
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]
 
  +
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成]
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft の Windows と GPT の FAQ]
 
  +
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI 再インストールせずに Windows x64 を BIOS-MBR モードから UEFI-GPT モードに移行]
 
  +
*[https://web.archive.org/web/20190404074007/https://software.intel.com/en-us/articles/efi-shells-and-scripting/ - Intel ドキュメント]
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成]
 
  +
* [https://web.archive.org/web/20190117223426/https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel ドキュメント]
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
 
  +
* [https://web.archive.org/web/20130929114218/http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報]
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel ドキュメント]
 
  +
* [https://lwn.net/Articles/632528/ The bootstrap process on EFI systems]
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel ドキュメント]
 
  +
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報]
 
  +
{{TranslationStatus|Unified Extensible Firmware Interface|2024-03-21|803978}}
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]
 

2024年3月31日 (日) 11:39時点における版

関連記事

Unified Extensible Firmware Interface (UEFI、EFI の後継) はオペレーティングシステムとファームウェア間のインターフェイスです。オペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。

UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては Arch ブートプロセス を見てください。UEFI ブートローダをセットアップするには ブートローダー を見てください。

ノート: 初期のベンダー UEFI 実装は BIOS のものよりも多くのバグを含んでいる場合があります。そのようなシステムで解決不可能な問題に直面した場合は、レガシー BIOS を使用して起動することを検討してください。

目次

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 を含む x86_64 システムの大部分は x64 (64 ビット) UEFI ファームウェアを使用します。IA32 (32ビット) の UEFI を使うことが知られているデバイスは古い(2008年以前) Apple Mac や Intel Atom System-on-Chip システム(2013年11月2日現在)[1]、そして Intel EFI 1.10 ファームウェア上で動作することが知られている一部の古い Intel のサーバーボードだけです。

x64 UEFI ファームウェアは 32ビットの EFI アプリケーションの起動をサポートしません(x86_64 Linux とそのようなサポートを含む Windows のバージョン とは違って)。それゆえ、EFI アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。

ノート: IA32 UEFI のシステムでは、異なるモードでの起動をサポートするブートローダを使用する必要があります。例えば、systemd-boot などです。
警告: grub 2:2.06.r566.g857af0e17-1 から、GRUB の i386-efi ターゲットは壊れており、IA32 UEFI でブートするために使用することはできません。FS#79098 を参照してください。

UEFI ファームウェアのビット数を調べる

ファームウェアのビット数は起動されたオペレーティングシステムから確認できます。

Linux で

Linux カーネル 4.0 以上が走るディストリビューションでは、UEFI ファームウェアのビット数は sysfs インターフェイスを通して確認できます。以下を実行してください:

$ cat /sys/firmware/efi/fw_platform_size

このコマンドは、64ビット (x64) UEFI の場合は 64、32ビット(IA32) UEFI の場合は 32 を返します。このファイルが存在しない場合は UEFI モードで起動していないということです。

macOS で

2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年以降の Mac のファームウェアはほとんど x64 EFI です。Mac OS X Snow Leopard を動かすことのできる全ての Mac は x64 EFI 1.x ファームウェアを使っています。

Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください:

$ ioreg -l -p IODeviceTree | grep firmware-abi

コマンドの返事が EFI32 なら、IA32 (32ビット) EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x64 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-ベース PCBIOS モード: UEFI となります。32ビット UEFI 上で動作する 32ビット Windows では システムの種類: x86-ベース PCBIOS モード: 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 (古い 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 変数のサポートを正しく動作させるための必要条件

  1. カーネルが EFISTUB(任意で ブートマネージャー)を通して、またはブートローダーによって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
  2. EFI Runtime Services サポートがカーネルに存在する必要があります (CONFIG_EFI=y)。zgrep CONFIG_EFI /proc/config.gz で確認できます。
  3. カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり noefi カーネルコマンドラインは使わないで下さい。
  4. efivarfs ファイルシステムが /sys/firmware/efi/efivars にマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい。
  5. efivar はエラーを出さずに EFI 変数をリストアップ (-l/--list オプション) するはずです。

上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:

  1. UEFI 変数のリストアップ(efivar -l)の際に efivar: error listing variables: Function not implemented と言うメッセージが出て、かつ、システムがリアルタイムカーネルで起動する場合、カーネルパラメータefi=runtime を追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。
  2. さらなるドラブルシューティング手順は #ユーザスペースのツールが UEFI 変数のデータを変更できない を見てください。

efivarfs のマウント

efivarfs が起動中にsystemd によって自動的に /sys/firmware/efi/efivars にマウントされない場合、UEFI 変数を efibootmgr のようなユーザースペースツールに公開するために efivarfs を手動でマウントする必要があります:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
ノート: 上のコマンドは chroot の前と後、両方で実行する必要があります。

カーネルドキュメントの efivarfs.html を参照してください。

ユーザースペースツール

UEFI 変数を表示・変更することができるツールがいくつかあります、即ち

  • efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
https://github.com/rhboot/efivar || efivar
  • efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール
https://github.com/rhboot/efibootmgr || efibootmgr
  • uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  • efitools — UEFI セキュアブートプラットフォームを操作するための UEFI ツール
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools
  • Ubuntu's Firmware Test Suite — Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR

efibootmgr

efibootmgr パッケージをインストールする必要があります。

ノート:
  • あなたの環境で efibootmgr が完全に動かない場合、再起動して #UEFI シェル に入り bcfg コマンドを使ってブートローダのブートエントリを作成してください。
  • efibootmgr を使えない場合、UEFI BIOS によっては BIOS から直接 uefi のブートオプションを管理できることがあります。例えば、ASUS の BIOS には "Add New Boot Option" からローカルの EFI System Partition を選択して直接 EFI スタブの位置を入力できます (例えば \EFI\refind\refind_x64.efi)。
  • 下のコマンドではサンプルとして rEFInd ブートローダを使っています。

efibootmgr を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:

  1. EFI システムパーティション (ESP) を含むディスク (例: /dev/sda /dev/nvme0n1)。
  2. そのディスク上にある ESP のパーティション番号。/dev/sdaY/dev/nvme0n1pYY の部分のことです。
  3. EFI アプリケーションへのパス (ESP のルートからの相対パス)

例えば、/efi が ESP のマウントポイントである場合に /efi/EFI/refind/refind_x64.efi 用のブートオプションを追加したい場合、以下を実行してください:

$ findmnt /efi
TARGET SOURCE    FSTYPE OPTIONS
/efi   /dev/sda1 vfat   rw,flush,tz=UTC

この例では、findmnt(8) コマンドは、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' --unicode

さらなる情報は efibootmgr(8) または efibootmgr README を見てください。

ノート: UEFI 仕様では、逆スラッシュ \ がパスセパレータとして使用されますが、efibootmgr は自動的に UNIX スタイルの / パスセパレータを変換することができます。

UEFI 変数へのアクセスを無効化

UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。実際、悪意のあるアクターがマシンの完全な制御を奪うことのできる LogoFAIL という危険な UEFI エクスプロイトが存在します。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[3]

ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。

可能な方法は:

  • efivarsfstab を用いて読み取り専用モードでマウントする。例えば:
    efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
  • noefi カーネルパラメータを使用して、OS から UEFI へのアクセスを完全に無効化する。
ノート: UEFI ユーザスペースツール は UEFI 変数へのアクセスが無効化された状態では使用できないので、必要な設定をすべて前もって行っておいてください。また、UEFI 関連のコマンド(例: systemctl reboot --firmware-setup) も機能しなくなります。

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 パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
    • uefi-shell-gitAUR パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル

Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkgInclusion of UEFI shell in Linux distro iso を見て下さい。

UEFI シェルの起動

数少ない Asus や他の AMI Aptio x64 UEFI ファームウェアベースのマザーボード (Sandy Bridge 以降) では、Launch EFI Shell from filesystem device と呼ばれるオプションが提供されています。これらのマザーボードでは、x64 UEFI Shell を EFI システムパーティション のルートに shellx64.efi という名前で コピーしてください。

ヒント:
  • Arch Linux インストールメディアにはボリュームのルートに shellx64.efi があります。
  • rEFIndsystemd-boot は、shellx64.efiEFI システムパーティションのルートにある場合、自動的に UEFI シェルのブートメニューエントリを追加します。

Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており F6, F11, F12 キーのどれかで起動できます。

ノート: 上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、/USB_drive_mointpoint/EFI/BOOT/BOOTx64.EFI としてコピーされた EFI バイナリのある FAT32 USB ペンドライブを作成してください。この USB はファームウェアブートメニューを表示するはずです。このオプションを起動することで UEFI シェルが起動されます。

重要な UEFI シェルコマンド

UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。利用できるコマンドを表示するには help -b を実行してください。

詳しい情報は Intel Scripting Guide 2008[リンク切れ 2023-07-30]Intel "Course" 2011[リンク切れ 2023-07-30] を見てください。

bcfg

bcfg コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては UEFI Shell Specification 2.2 ドキュメントの 96 ページ (Section 5.3) で詳しく説明されています。

ノート:
  • efibootmgr が上手くブートエントリを作成できないときだけ bcfg を使うことが推奨されています。
  • UEFI Shell v1 の公式バイナリは bcfg コマンドをサポートしていません。#UEFI シェルを入手する を見て、UEFI pre-2.3 ファームウェアで動作する、修正された UEFI Shell v2 バイナリを入手してください。

現在のブートエントリのリストを出力するには:

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) の名前) の一覧を表示します。

cdls などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります:

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 ドライバとは、なんらかの機能をサポートするためのソフトウェアのことです。例えば、NTFS でフォーマットされたパーティションは通常 UEFI シェルからアクセスできません。efifs パッケージには、EFI シェル内から多くのファイルシステムを読み込めるようにするドライバが含まれています。使用例を挙げましょう。そのようなドライバを UEFI シェルからアクセス可能なパーティションにコピーして、UEFI シェルから以下のようなコマンドを実行します:

Shell> load ntfs_x64.efi
Shell> map -r

map コマンドを実行したあと、ユーザは NTFS でフォーマットされたパーティションに UEFI シェル内からアクセスできるようになっているはずです。

ヒント:
  • systemd-bootesp/EFI/systemd/drivers/ から UEFI ドライバを自動的に読み込みます。
  • rEFInd は、ESP 上の rEFInd インストール先ディレクトリのサブディレクトリ driversdrivers_x64 (例: esp/EFI/refind/drivers_x64/) から UEFI ドライブを自動的に読み込みます。他のディレクトリをスキャンするように設定することも可能です。

UEFI ブータブルメディア

ISO から UEFI ブータブル USB を作成する

USB インストールメディア#ISO をそのまま使う (BIOS と UEFI) を参照してください。

光学メディアから UEFI ブートサポートを削除する

ノート:
  • このセクションでは USB フラッシュドライブではなく CD/DVD (EL Torito からブートする光学メディア) から UEFI ブートサポートを削除する方法を説明しています。
  • USB スティック上の UEFI 機構を隠すには、ISO をフラッシュドライブにコピーしたあとでパーティションエディタを使ってください。EF タイプのパーティションを削除してください。GPT に変換するか尋ねられたときはいいえと答えてください。

ほとんどの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

そして、libisoburnxorriso(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/x64/OVMF_VARS.4m.fd my_OVMF_VARS.4m.fd

OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください:

-drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd \
-drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd

例えば:

$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd -drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd …

BIOS システム専用の DUET

DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする TianoCore プロジェクトです。この方法については広く議論されています。ビルド済み DUET イメージは、いくつかのリポジトリ[リンク切れ 2023-04-07]のどれかからダウンロードできます。DUET をセットアップする特定の方法については、特定の指示[リンク切れ 2023-04-07]を読んでください。しかし、2018年11月に DUET のコードが TianoCore git リポジトリから削除されました。

また、修正 DUET イメージを提供する Clover を試すことも可能です。特定環境の修正が含まれており gitlab リポジトリと比べて頻繁に更新されています。

トラブルシューティング

Windows で固まった際に Arch Linux に戻る

Windows で固まった際に Arch Linux に戻るには、Windows PowerShell コマンド shutdown /r /o、または Settings > Update & Security > Recovery > Advanced startupRestart now を選んで Windows の Advanced startup に進んでください。Advanced startup メニューに行き着いた際に、Use a device を選んでください。これには実際の UEFI ブートオプションが含まれています(USB や CD に限らず、ハードドライブ内の OS も起動できます)。そして、"Arch Linux" を選んでください。

ファンクションキー無しでファームウェアセットアップに入る

en:Lenovo XiaoXin 15are 2020 のような一部のノート PC では、F2F12 のようなキーを使用しても何も起こりません。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 変数ストレージスペースチェックを無効化します)。

警告: efi_no_storage_paranoia は必要なときにだけ使用するべきで、普段のブートオプションとして残しておくべきではありません。このカーネルコマンドラインは、NVRAM が満杯になった際にマシンが起動できなることを防止するセーフガードを無効化する効果があります。詳細は FS#34641 を見てください。

efibootmgr でブートエントリを新規作成できない

カーネルと efibootmgr のバージョンの組み合わせによっては、ブートエントリの新規作成ができなるなるかもしれません。これは NVRAM の空き領域の不足によるものであることがあります。#ユーザスペースのツールが UEFI 変数のデータを変更できない の解決策を試すことができます。

また、efibootmgr をバージョン 0.11.0 までダウングレードしてみることもできます。このバージョンは Linux バージョン 4.0.6 で機能します。詳細はバグのディスカッション FS#34641、特に closing comment を見てください。

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 で設定することができます。
    1. 管理者権限でコマンドプロンプトを開き、bcdedit /enum firmware を実行して、お望みのブートエントリを見つけてください。
    2. カッコも含めて識別子をコピーしてください。例: {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
    3. 次のコマンドを含むバッチファイルを作成してください: bcdedit /set "{fwbootmgr}" DEFAULT "{コピーしたブート識別子}"
    4. gpedit.msc を開き、Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) にある Startup をクリックしてください。
    5. Scripts タブに行き、Add ボタンをクリックし、そのバッチファイルを選択してください。
注: Windows 10 Home は公式には gpedit.msc を含んでいません。しかし、それを手動でインストールする、サポートされない回避策があります。
  • または、Windows でスタートアップするクリプトを実行するためにタスクスケジューラを使用することができます:
    1. 上記の1から3の手順に従って、バッチファイルを作成してください。
    2. taskschd.msc を実行し、Action メニュから Create Task... を選んでください。
    3. General タブで:
      適当な任意の NameDescription を入力してください。
      選択したユーザアカウントが "Administrator" (管理者)であることを確認してください。"Standard User" であってはなりません。
      "Run whether user is logged in or not" を選択してください。
      "Run with highest privileges" を選択してください。
    4. Triggers タブで、メニューから "At startup" を選択して、その後 OK を押してください。
    5. Actions タブで、New... をクリックし、Browse... をクリックし、手順1 で作成したバッチファイルを選択してください。
    6. Conditions tab タブで、Power オプションのチェックを解除してください。そうすれば、バッテリ駆動時にスクリプトが実行されます(ラップトップの場合)。
    • OK をクリックして、パスワードのプロンプトが表示された場合は手順4で選択したユーザアカウントのパスワードを入力してください。

USB メディアが黒画面で固まる

この問題は KMS の問題によって起こることがあります。USB を起動するときは KMS を無効化してみて下さい。

ファームウェアのメニューに UEFI ブートローダーが表示されない

一部のファームウェアはカスタムのブートエントリをサポートしていません。そのようなファームウェアはハードコードされたブートエントリからしか起動しません。

典型的な回避策は、NVRAM のブートエントリに頼るのではなく、EFI システムパーティション内の共通フォールバックパスの一つにブートローダーをインストールすることです。

以下のセクションではそのフォールバックパスについて説明しています。

リムーバブルドライブのデフォルトブートパス

UEFI 仕様では、リムーバブルメディアから起動するための EFI バイナリのデフォルトファイルパスが定義されています。関連するものとしては:

  • esp/EFI/BOOT/BOOTx64.EFI - x64 UEFI 用
  • esp/EFI/BOOT/BOOTIA32.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 に追加したエントリがブートメニュに表示されるはずです。

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' --unicode -e 3

grub-installrefind-install のようなブートローダインストーラを修復するには、/usr/local/bin/efibootmgr ラッパースクリプトを作成し、それを実行可能にしてください:

/usr/local/bin/efibootmgr
#!/bin/sh

exec /usr/bin/efibootmgr -e 3 "$@"

UEFI ブートエントリが、参照するドライブを取り外すと消える

一部のファームウェアは、参照されているドライブが起動中に存在しない場合、そのブートエントリを削除します。これは、ドライブを頻繁に取り付け/取り外ししたり、リムーバブルドライブから起動する際に問題となりえます。

解決策は、ブートローダーデフォルト/フォールバックブートパスにインストールすることです。

ブートエントリがランダムに削除される

一部のマザーボードは、NVRAM の空き領域が足りない場合、ブートエントリの作成時にエラーを表示せずに、ブートエントリを削除してしまうことがあります。これを防ぐには、エントリの作成プロセスを最小限にして、追加されるブートエントリの数を減らし、さらに、UEFI 設定から Compatibility Support Module (CSM) を無効化して、自動ドライブブートエントリの数も減らしてください。BBS#1608838 を参照してください。

ブートエントリが削除されてしまう他の原因として、UEFI 仕様では「NVRAM メンテナンス」をブート中に実行することが OEM に許可されていることも挙げられます。そのようなメーカーのデバイスは、事前定義されハードコードされているデバイス上のパスで EFI アプリケーションを探索するだけです。何も見つけられなかった場合、デバイス上には OS が存在しないと結論づけ、NVRAM 上に破損しているまたは古いデータが存在すると推測し、そのデバイスと関連する NVRAM からすべてのブートエントリを消してしまいます。Windows をインストールする予定がなく、ファームウェアから Linux カーネルを直接ロードしたい場合、解決策として空のファイル esp/EFI/BOOT/BOOTx64.EFI を作成するというものがあります:

# mkdir -p esp/EFI/BOOT 
# touch esp/EFI/BOOT/BOOTx64.EFI

そして、削除されたブートエントリを作り直してください。これで、再起動すれば、マザーボードは「偽のOS」を検出し、NVRAM から他のブートエントリを削除しなくなるはずです。この偽の OS ローダは実際の EFI アプリケーションに自由に変更することもできます。もちろん、標準のフォールバック名を使い続ける限りです。

参照

翻訳ステータス: このページは en:Unified Extensible Firmware Interface の翻訳バージョンです。最後の翻訳日は 2024-03-21 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。