Unified Extensible Firmware Interface
Unified Extensible Firmware Interface (もしくは省略して UEFI や EFI)はオペレーティングシステムとファームウェア間のインターフェイスのモデルですオペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。
UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては Arch ブートプロセス を見てください。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 アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。
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 変数のサポートを正しく動作させるための必要条件
- カーネルが EFISTUB(任意で ブートマネージャー)を通して、またはブートローダーによって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
- EFI Runtime Services サポートがカーネルに存在する必要があります (
CONFIG_EFI=y
)。zgrep CONFIG_EFI /proc/config.gz
で確認できます。 - カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり
noefi
カーネルパラメータは使わないで下さい。 efivarfs
ファイルシステムが/sys/firmware/efi/efivars
にマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい。efivar
はエラーを出さずに EFI 変数をリストアップ (-l
/--list
オプション) するはずです。
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
- UEFI 変数のリストアップ(
efivar -l
)の際にefivar: error listing variables: Function not implemented
と言うメッセージが出て、かつ、システムがリアルタイムカーネルで起動する場合、カーネルパラメータにefi=runtime
を追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。 - さらなるドラブルシューティング手順は #ユーザスペースのツールが UEFI 変数のデータを変更できない を見てください。
efivarfs のマウント
efivarfs
が起動中にsystemd によって自動的に /sys/firmware/efi/efivars
にマウントされない場合、UEFI 変数を efibootmgr のようなユーザースペースツールに公開するために efivarfs
を手動でマウントする必要があります:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
}
カーネルドキュメントの efivarfs.html を参照してください。
ユーザースペースツール
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
- efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
- efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール
- uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。
- efitools — UEFI セキュアブートプラットフォームを操作するための UEFI ツール
- Ubuntu's Firmware Test Suite — Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート
efibootmgr
efibootmgr パッケージをインストールする必要があります。
efibootmgr を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:
- EFI システムパーティション (ESP) を含むディスク (例:
/dev/sda
/dev/nvme0n1
)。 - そのディスク上にある ESP のパーティション番号。
/dev/sdaY
や/dev/nvme0n1pY
のY
の部分のことです。 - EFI アプリケーションへのパス (ESP のルートからの相対パス)
例えば、/efi
が ESP のマウントポイントである場合に /efi/EFI/refind/refind_x64.efi
用のブートオプションを追加したい場合、以下を実行してください:
$ findmnt /efi
TARGET SOURCE FSTYPE OPTIONS /efi /dev/sda1 vfat rw,flush,tz=UTC
この例では、ESP がディスク /dev/sda
上にあり、そのパーティション番号が 1 であることを示しています。EFI アプリケーションへの、ESP をルートとした相対パスは /EFI/refind/refind_x64.efi
となっています。故に、ブートエントリを以下のように作成することになります:
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
さらなる情報は efibootmgr(8) または efibootmgr README を見てください。
UEFI 変数へのアクセスを無効化
UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[2]
ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。
可能な方法は:
efivars
を fstab を用いて読み取り専用モードでマウントする。例えば:efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
noefi
カーネルパラメータを使用して、OS から UEFI へのアクセスを完全に無効化する。
UEFI シェル
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
UEFI シェルを入手する
Tianocore EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:
- Shell v2:
- Arch インストールメディアの
/shellx64.efi
。ISO がビルドされたときの/usr/share/edk2-shell/x64/Shell_Full.efi
のコピーです。 - edk2-shell パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
- uefi-shell-gitAUR パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル
- Arch インストールメディアの
- Shell v1:
- TianoCore 由来の プリコンパイル済み UEFI Shell v1 バイナリ (2014/1/10 から上流は一度もアップデートされていません)。
- 派生版:
- プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg - Clover EFI ブートローダ由来。
- 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ - OpenCore ブートローダ由来。リリースアーカイブでは:
EFI/OC/Tools/OpenShell.efi
。
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkg や Inclusion of UEFI shell in Linux distro iso を見て下さい。
UEFI シェルの起動
Asus や AMI Aptio のマザーボード (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 シェルコマンド
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) で詳しく説明されています。
現在のブートエントリのリストを出力するには:
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 ドライバ
UEFI ブータブルメディア
ISO から UEFI ブータブル USB を作成する
USB インストールメディア#BIOS・UEFI ブータブル USB を参照してください。
オプティカルメディアから 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 スタブに依存せずにカーネルを動かすようなブートローダーを利用しなければなりません。
ネイティブサポートのない環境で 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 によるものではない場合、おそらく 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 コマンドの情報