Unified Extensible Firmware Interface

提供: ArchWiki
2022年6月14日 (火) 05:17時点におけるAshMyzk (トーク | 投稿記録)による版 (→‎ユーザースペースツール: 同期)
ナビゲーションに移動 検索に移動

関連記事

Unified Extensible Firmware Interface (もしくは省略して UEFI) は新しいタイプのファームウェアで、もともとは Intel によって Itanium を使ったシステム用に設計されました (その時の名前は EFI)。UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なる新しい OS 起動方法を取り入れています。Intel によって EFI がバージョン 1.x としてリリースされたのに始まり、それから UEFI Forum という業界団体によって開発が引き継がれ、Unified EFI という名前でバージョン 2.0 がリリースされました。このページでは UEFI ブートローダの設定は説明しません。そのような情報はブートローダーを見て下さい。

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 アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。

ノート: IA32 UEFI のシステムでは、異なるモードでの起動をサポートするブートローダを使用する必要があります。例えば、i386-efi を対象にしてインストールされた GRUB などです。

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 カーネル設定オプションは: 

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 変数のサポートを正しく動作させるための必要条件

  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/nvme0n1pY の Y の部分のことです。
  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

この例では、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 では逆スラッシュ \ がパスセパレータとして使用されますが、efibootmgr は自動的に UNIX スタイルの / パスセパレータに変換してくれます。

UEFI シェル

UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。

UEFI シェルを入手する

Intel の Tianocore UDK/EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:

Shell v2:

  • Arch インストールメディアの /shellx64.efi
  • edk2-shell パッケージ - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースからコンパイル
  • uefi-shell-gitAUR パッケージ - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースからコンパイル

Shell v1:

派生版:


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

UEFI シェルの起動

Asus や AMI Aptio のマザーボード (Sandy Bridge 以上) ベースの x86_64 UEFI ファームウェアには "Launch EFI Shell from filesystem device" という名前のオプションが提供されていることがあります。そういったマザーボードでは、x86_64 UEFI シェルをダウンロードして EFI SYSTEM PARTITION に <EFI_SYSTEM_PARTITION>/shellx64.efi としてコピーしてください (ほとんどの場合 /boot/efi/shellx64.efi)。

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

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

重要な UEFI シェルコマンド

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

詳しい情報は https://software.intel.com/en-us/articles/efi-shells-and-scripting/

bcfg

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

ノート:
  • efibootmgr が上手くブートエントリを作成できないときだけ bcfg を使うことが推奨されています。
  • UEFI Shell v1 の公式バイナリは bcfg コマンドをサポートしていません。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"

fs0: は EFI System Partition に、\EFI\refind\refind_x64.efi は起動するファイルにそれぞれ適切にマッピングしてください。

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> fs0:
FS0:\> cd \EFI\arch\refind
FS0:\EFI\arch\refind\> edit refind.conf

ヘルプを出すには Ctrl-E を押して下さい。

UEFI ブータブルメディア

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

USB インストールメディア#BIOS・UEFI ブータブル USB を参照してください。

オプティカルメディアから UEFI ブートサポートを削除する

ノート: このセクションでは USB フラッシュドライブではなく CD/DVD (オプティカルメディア) から UEFI ブートサポートを削除する方法を説明しています。

ほとんどの32ビット EFI Mac といくつかの64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。オプティカルメディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があります。

  • 公式インストールメディアをマウントして前のセクションで示されているように archisolabel を取得してください。
# mount -o loop input.iso /mnt/iso
  • libisoburn に含まれている xorriso を使って UEFI Optical Media ブートサポートを除いた ISO を再生成してください (archisolabel は "ARCH_201411" などに適当に置き換えて下さい)。
$ xorriso -as mkisofs -iso-level 3 \
    -full-iso9660-filenames\
    -volid "archisolabel" \
    -appid "Arch Linux CD" \
    -publisher "Arch Linux <https://www.archlinux.org>" \
    -preparer "prepared by $USER" \
    -eltorito-boot isolinux/isolinux.bin \
    -eltorito-catalog isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \
    -output output.iso /mnt/iso/
  • output.iso をオプティカルメディアに焼いて通常通りインストールに進んで下さい。

32ビット UEFI で 64ビットカーネルを起動する

公式 ISO は、32ビット (IA32) UEFI システムからの起動をサポートしていません (FS#53182)。カーネル内で、UEFI モード から起動するために EFISTUB を利用しているためです。64ビットカーネルを32ビット UEFIから起動するには、EFI Boot スタブに依存せずにカーネルを動かすようなブートローダーを利用しなければなりません。

ヒント: Archboot ISO は32ビット UEFI システムからの起動をサポートしています。

ネイティブサポートのない環境で UEFI をテストする

仮想マシン用の OVMF

OVMF は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。

公式リポジトリから ovmf[リンク切れ: 置換パッケージ: edk2-ovmf] をインストールして次のように実行することができます: 

$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly

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://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt にあります。

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

トラブルシューティング

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 8 によって NVRAM の起動順序が変わってしまうことがあります (ASRock Z77 Extreme4 で確認)。この問題は Windows Boot Manager に Windows を起動する代わりに他のローダーをロードしてもらうようにすれば解決できます。Windows の管理者モードのコンソールで次のコマンドを実行してください: 

bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi

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

  • この問題は KMS の問題によって起こることがあります。USB を起動するときは KMS を無効化してみて下さい。
  • 問題が KMS によるものではない場合、おそらく EFISTUB ブートのバグによる問題です (詳しくは FS#33745 や [2] を見て下さい)。公式 ISO (Archiso) と Archboot iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは Gummiboot ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして GRUB を使って下さい。

GRUB の使用

  • <USB>/EFI/boot/loader.efi を <USB>/EFI/boot/gummiboot.efi にバックアップしてください。
  • 以下の内容で <USB>/EFI/boot/grub.cfg を作成してください (ARCH_YYYYMM は USB ディスクのラベルに置き換えて下さい、例: ARCH_201507):
grub.cfg for Official ISO
insmod part_gpt
insmod part_msdos
insmod fat

insmod efi_gop
insmod efi_uga
insmod video_bochs
insmod video_cirrus

insmod font

if loadfont "${prefix}/fonts/unicode.pf2" ; then
    insmod gfxterm
    set gfxmode="1024x768x32;auto"
    terminal_input console
    terminal_output gfxterm
fi

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
}

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
}

grub.cfg for Archboot ISO
insmod part_gpt
insmod part_msdos
insmod fat

insmod efi_gop
insmod efi_uga
insmod video_bochs
insmod video_cirrus

insmod font

if loadfont "${prefix}/fonts/unicode.pf2" ; then
    insmod gfxterm
    set gfxmode="1024x768x32;auto"
    terminal_input console
    terminal_output gfxterm
fi

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
}

menuentry "UEFI Shell x86_64 v2" {
    search --no-floppy --set=root --file /boot/vmlinuz_x86_64
    chainloader /EFI/tools/shellx64_v2.efi
}
    
menuentry "UEFI Shell x86_64 v1" {
    search --no-floppy --set=root --file /boot/vmlinuz_x86_64
    chainloader /EFI/tools/shellx64_v1.efi
}

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

Intel Z77 チップセットなどが搭載された一部の UEFI マザーボードでは、UEFI シェルから efibootmgr や bcfg を使ってエントリを追加しても、ブートメニューのリストに表示されないため使うことができません。

この問題はマザーボードが Microsoft Windows しかロードしないようになっているのが原因です。解決するには Windows が使っている場所に ".efi" ファイルを配置するしかありません。

Arch Linux のインストールメディア (FSO:) から bootx64.efi ファイルをコピーしてハードドライブ (FS1:) 上の ESP パーティションの Microsoft ディレクトリに配置してください。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 に追加されたエントリがブートメニューに表示されるはずです。

参照

「https://wiki.archlinux.jp/index.php?title=Unified_Extensible_Firmware_Interface&oldid=25906」から取得