Unified Extensible Firmware Interface

関連記事

• Arch ブートプロセス
• Master Boot Record
• EFI システムパーティション
• GUID Partition Table
• セキュアブート

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 を含む 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-git^AUR

• 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-git^AUR

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 へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[2]

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

可能な方法は:

• efivars を fstab を用いて読み取り専用モードでマウントする。例えば:

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

• Shell v1:
  • TianoCore 由来の プリコンパイル済み UEFI Shell v1 バイナリ (2014/1/10 から上流は一度もアップデートされていません)。

• 派生版:
  • プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg - Clover EFI ブートローダ由来。
  • 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ - OpenCore ブートローダ由来。リリースアーカイブでは: EFI/OC/Tools/OpenShell.efi。

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

UEFI シェルの起動

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

ヒント:

• Arch Linux インストールメディアにはボリュームのルートに shellx64.efi があります。
• rEFInd と systemd-boot は、shellx64.efi が EFI システムパーティションのルートにある場合、自動的に 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 を実行してください。

詳しい情報は 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 や [3] を見て下さい)。公式 ISO (Archiso) と Archboot iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは Gummiboot ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして GRUB を使って下さい。

GRUB の使用

• USB インストールメディア#BIOS・UEFI ブータブル USB に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。

• <USB>/EFI/boot/loader.efi を <USB>/EFI/boot/gummiboot.efi にバックアップしてください。

• GRUB スタンドアロンイメージを作成して <USB>/EFI/boot/loader.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 に追加されたエントリがブートメニューに表示されるはずです。

参照

• Wikipedia:ja:UEFI
• UEFI Forum - 公式の UEFI の仕様書 - GUID Partition Table は UEFI の仕様に含まれています
• UEFI boot: how does that actually work, then? - AdamW によるブログ記事
• Linux カーネル x86_64 UEFI ドキュメント
• Intel の EFI に関するページ
• Intel Architecture Firmware Resource Center
• Matt Fleming - The Linux EFI Boot Stub
• Matt Fleming - Accessing UEFI Variables from Linux
• Rod Smith - Linux on UEFI: クイックインストールガイド
• 新しいマシンでの UEFI ブート問題 (LKML)
• LPC 2012 Plumbing UEFI into Linux
• LPC 2012 UEFI チュートリアル : part 1
• LPC 2012 UEFI チュートリアル : part 2
• Intel の Tianocore プロジェクト 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
• FGA: The EFI boot process
• Microsoft の Windows と GPT の FAQ
• 再インストールせずに Windows x64 を BIOS-MBR モードから UEFI-GPT モードに移行
• Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成
• Rod Smith - A BIOS to UEFI Transformation
• EFI Shells and Scripting - Intel ドキュメント
• UEFI Shell - Intel ドキュメント
• UEFI Shell - bcfg コマンドの情報