Unified Extensible Firmware Interface (日本語)
| 概要 |
|---|
| Unified Extensible Firmware Interface の概要。 |
| 概括 |
| Arch Linux を起動するためには、GRUB(2), Syslinux, LILO, GRUB Legacy などの Linux 対応のブートローダを、Master Boot Record もしくは GUID Partition Table にインストールする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルやイニシャルラムディスクをロードする仕事を行います。 |
| 関連項目 |
| GUID Partition Table (日本語) |
| Master Boot Record (日本語) |
| Arch Boot Process (日本語) |
Unified Extensible Firmware Interface (もしくは省略して UEFI) は新しいタイプのファームウェアで、もともとは Intel によって Itanium を使ったシステム用に設計されました (その時の名前は EFI)。UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なる新しい OS 起動方法を取り入れています。Intel によって EFI がバージョン 1.x としてリリースされたのに始まり、それから UEFI Forum という業界団体によって開発が引き継がれ、Unified EFI という名前でバージョン 2.0 がリリースされました。2013年7月24日現在、UEFI の仕様は 2.4 が一番新しいバージョンです (2013年6月11日にリリース)。
UEFI を理解する前に、UEFI の前 (BIOS) のシステムブートがどうなっているのか理解するのが重要です。次のセクションで説明しています。
Contents |
BIOS
BIOS (Basic Input-Output System) はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラム（ファームウェア）です。ほとんどの場合マザーボード上のフラッシュメモリに保存されており、システムのストレージとは独自つしています。
BIOS のブートプロセス
- システムのスイッチが入る - POST (Power On Self Test) プロセス
- POST の後 BIOS はブートに必要なシステムハードウェアを初期化します (ディスク、キーボード、コントローラなど)
- BIOS は BIOS のディスク順で一番最初のディスクから最初の 440 バイト (MBR ブートコード領域) を起動します
- BIOS から MBR ブートコードにコントロールが映り、次の段階のコードが起動されます (ほとんどの場合ブートローダ)
- 起動された (2段階目の) コード (ブートローダ) はサポートと設定ファイルを読み込みます
- 設定ファイルのデータに従って、ブートローダはカーネルと initramfs をシステムメモリ (RAM) にロードしカーネルを起動します
BIOS のマルチブート
440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、BIOS を使ってマルチブートするにはマルチブート対応のブートローダが必要になります（ここで、マルチブートとは複数のオペレーティングシステムを起動することであり、GRUB 開発者によって明示された Multiboot フォーマット内のカーネルを起動することではありません）。そのため普通は GRUB, Syslinux, LILO などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。
UEFI
UEFI は分かりやすいファイルシステムとパーティションテーブル、その両方の読み込みをサポートしています。従って BIOS 環境であったような 440 バイトのコード制限 (MBR ブートコード) は存在しません。
一般的に使われている 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+ ファイルシステムへのアクセスができます。
MBR にブートコードがあろうとなかろうと UEFI はそれを実行しません。かわりに、UEFI は "EFI SYSTEM PARTITION" という名前のパーティションテーブル内の特別なパーティションを使います、そしてその中にファームウェアによって起動するために必要なファイルが保存されています。各ベンダーは <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 ファームウェアを使っているものがあります。
x86_64 バージョンの Linux や Windows とは異なり、x86_64 の EFI ファームウェアは 32 ビットの EFI アプリを実行することができません。従って UEFI アプリケーションはファームウェアのアーキテクチャにあわせて正しくコンパイルされている必要があります。
UEFI のブートプロセス
- システムのスイッチが入る - POST (Power On Self Test) プロセス
- UEFI ファームウェアがロードされます。ファームウェアは起動に必要なハードウェアを初期化します
- 次にファームウェアはブートマネージャのデータを読み込みどの UEFI アプリケーションをどこから (つまりどのディスク・パーティションから) 起動するか決定します
- ファームウェアのブートマネージャのブートエントリに定義されているように UEFI アプリケーションをファームウェアが起動します
- 起動した UEFI アプリケーションは設定によって他のアプリケーション (UEFI シェルや rEFInd の場合) やカーネルと initramfs (GRUB などのブートローダの場合) を起動します
UEFI のマルチブート
OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるためにブートローダのロード機構に頼る必要はなくなります。
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 ファームウェアのビット数を調べる
Mac でない場合
/sys/firmware/efi ディレクトリが存在するかどうか確認してください。存在するときはカーネルは EFI モードで起動されています。この場合 UEFI のビット数はカーネルのビット数と同じです (i686 か x86_64)。
Apple Mac
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 の仕様に完全には準拠していないからです。
UEFI の Linux カーネル設定オプション
UEFI システムのために必要な Linux カーネル設定オプションは:
CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=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)。このオプションは無効にしてください。
CONFIG_EFI_VARS=n
GUID Partition Table GPT 設定オプション - UEFI サポートのために必須
CONFIG_EFI_PARTITION=y
UEFI 変数
UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。
UEFI 変数のサンプルリスト
Lenovo の Thinkpad E430 3254-DAQ での UEFI 変数の一覧です (UEFI 2.3.1, x86_64 ファームウェア, Secure Boot サポート):
UEFI Variables List
$ efivar -l 0b7646a4-6b44-4332-8588-c8998117f2ef-BmEssentialVariableNames 0ec1a7f5-4904-40a0-8eab-4bcc4666da45-PbaStatusVar 1054354b-b543-4dfe-558b-a7ad6351c9d8-DptfProtocolSetupVar 1827cfc7-4e61-4273-b796-d35f4b0c88fc-LenovoHiddenSetting 1bad711c-d451-4241-b1f3-8537812e0c70-MeBiosExtensionSetup 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBC 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBL 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOL 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0000 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0001 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0002 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0003 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0004 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0005 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0006 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0007 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0008 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0009 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000A 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000B 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000C 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000D 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000E 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000F 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0010 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0011 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0012 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0013 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0014 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0015 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0016 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0017 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0018 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoConfig 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoSystemConfig 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0000 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0001 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0002 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0003 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0004 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0005 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0006 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LWO 34f73d4d-963e-4c65-b3b3-515e720175d6-SaProtocolSetupVar 3e72b3ad-2b91-424a-ad73-c3270e91ed88-PwdStatusVar 4650c401-93f1-4aeb-b87d-c8204c047dec-SctHotkey 47355e9f-0857-45e1-8a6f-a4f5eda89a77-LocalSecurityVars 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDeviceIdentifier 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDevicePartUUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntriesAuto 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntrySelected 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareInfo 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareType 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderImageIdentifier 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderInfo 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeExecUSec 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeInitUSec 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeMenuUSec 4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformation 4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformationBackup 4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d-Setup 5e724c0c-5c03-4543-bcb6-c1e23de24136-TpmSaveState 608dc793-15de-4a7f-a0c5-6c29beaf5d23-MemRestoreVariable 6403753b-abde-4da2-aa11-6983ef2a7a69-TpmAcpiData 65827a61-99e2-4f07-a7aa-0b1f98edad39-PlatformOpRomSetup 67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoFlashScratch1 67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoScratchData 67c3208e-4fcb-498f-9729-0760bb4109a7-MailBoxQ 753ab903-444c-41f8-a235-569e8341147e-TcgSetup 7d4adce1-930d-40c7-9cd2-6d2148413dc7-CpuProtocolSetupVar 7da81437-866b-4143-8e08-a25c6ef0fa5b-SaPpiSetupVar 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0005 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0006 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0007 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0008 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000A 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000B 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000C 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000D 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000E 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000F 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0010 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0011 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0012 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0013 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0014 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0015 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0016 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0017 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0018 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrderDefault 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-DIAGSPLSHSCRN 8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-HDDPWD 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0000 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0001 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0002 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0003 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0004 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0005 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0006 8be4df61-93ca-11d2-aa0d-00e098032b8c-LastBootCurrent 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes 8be4df61-93ca-11d2-aa0d-00e098032b8c-ProtectedBootOptions 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupHotKey 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode 8be4df61-93ca-11d2-aa0d-00e098032b8c-SimpleBootFlag 8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout 955b9041-133a-4bcf-90d1-97e1693c0e30-IEIT 955b9041-133a-4bcf-90d1-97e1693c0e30-SecureBootOption 9da5909e-ef5e-4851-8715-bf9e22b7a600-BGRTLogoIndex 9dab39a4-3f8a-47ac-80c3-400729332c81-FirmwarePerformanceDataTable a2c1808f-0d4f-4cc9-a619-d1e641d39d49-LenovoSecurityConfig af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e-AcpiGlobalVariable c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOG000 c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOGNUMBER c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSMEMSIZE c4975200-64f1-4fb6-9773-f6a9f89d985e-SaPegData d719b2cb-3d3a-4596-a3bc-dad00e67656f-db d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx e5bbf7be-2417-499b-97db-39f4896391bc-BuildDate e5bbf7be-2417-499b-97db-39f4896391bc-BuildTime e6c2f70a-b604-4877-85ba-deec89e117eb-PchInit e6c2f70a-b604-4877-85ba-deec89e117eb-PchS3Peim eb704011-1402-11d3-8e77-00a0c969723b-MTC f9f0b131-f346-4f16-80dd-f941072b3a7d-iFfsData
Linux カーネルでの UEFI 変数のサポート
Linux カーネルは2つのインターフェイスを使って EFI 変数のデータをユーザ空間に渡します:
- efivarfs (
efivarfsカーネルモジュール/sys/firmware/efi/efivars) は sysfs-efivars インターフェイスの限界を越えるために作られました - 古い sysfs-efivars インターフェイス (
efivarsカーネルモジュール/sys/firmware/efi/vars) は linux 3.11 から無効にされています
Efivarfs はカーネル 3.8 から導入されカーネル 3.10 でほとんどのバグが取り除かれました。
sysfs-efivars と efivarfs の両方を実行するとカーネル内の EFI 変数のデータに不一致が生じるので推奨されていません。EFI 変数を登録したカーネルと相互作用するツールのために efivarfs が推奨です。公式リポジトリにある UEFI 変数に関連したツールは全て efivarfs をサポートしています (2013年9月18日現在)。
efivarfs と sysfs-efivars の不一致
sysfs-efivars と efivarfs は同時に実行することが可能ですが、データを同時に修正した時、sysfs-efivars と efivarfs のデータに不一致が生じるおそれがあります。詳しくは https://lkml.org/lkml/2013/4/16/473 を見て下さい。従って通常はインターフェイスはひとつだけ有効にしてもうひとつの方は無効にすることを推奨します。
UEFI 変数のサポートを正しく動作させるための必要条件
- EFI Runtime Services サポートがカーネルに存在する必要があります (
CONFIG_EFI=y) - カーネルのプロセッサのビット数・アーキテクチャが EFI のビット数・アーキテクチャと一致していなくてはなりません
- カーネルは EFI モードで起動して下さい (via EFISTUB or any EFI bootloader, not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM)
- カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり
noefiカーネルパラメータは使わないで下さい -
efivarfsファイルシステムが/sys/firmware/efi/efivarsにマウントされている必要があります。マウントされていない時は手動でマウントしてください -
efivarはエラーを出さずに EFI 変数をリストアップ (-lオプション) するはずです。出力の例は #UEFI 変数のサンプルリスト を見て下さい
(ブート時に systemd によって自動でマウントされなかった時) efivarfs をマウントするには次を実行してください:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
- ユーザスペースのツールが efi 変数のデータを修正できない場合、
/sys/firmware/efi/efivars/dump-*ファイルが存在しているかチェックしてください。存在しているときは、ファイルを削除してから再起動してもう一度試して下さい。 - 上の手順で問題が修正されない場合、
efi_no_storage_paranoiaカーネルパラメータを使って起動してカーネルの efi 変数ストレージ領域チェックを無効にしてください。これによって efi 変数の書き込み・修正が止められている可能性があります。
ユーザースペースツール
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
- efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
- efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール。上流の (http://linux.dell.com/git/efibootmgr.git) efibootmgr コードは efivarfs をサポートしていません。Fedora の Peter Jones (vathpela) による efibootmgr のフォークは efivarfs と sysfs-efivars の両方をサポートしています。
- uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。2.0 は efivarfs だけをサポートしていて 1.0 は sysfs-efivars だけをサポートしています。
- efitools — UEFI Secure Boot の証明書・キー・署名済みのバイナリを作成・設定するためのツール (efivarfs を必要とします)
- http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/ || efitools-git
- Ubuntu's Firmware Test Suite — Ubuntu のファームウェアテストスイート。
efibootmgr
起動するブートローダファイルが /boot/efi/EFI/refind/refind_x64.efi だと仮定します。/boot/efi/EFI/refind/refind_x64.efi は /boot/efi と /EFI/refind/refind_x64.efi とに分割できますが、/boot/efi は EFI システムパーティションのマウントポイントで、ここでは /dev/sdXY と仮定します (この X と Y は本当の値の代替値です - 例:- /dev/sda1 , X=a Y=1)。
(マウントポイントが /boot/efi だとして) 実際の EFI システムパーティションの (/dev/sdXY という形式の) デバイスパスを調べるには、次を実行してください:
# findmnt /boot/efi TARGET SOURCE FSTYPE OPTIONS /boot/efi /dev/sdXY vfat rw,flush,tz=UTC
uefi 変数がカーネルでサポートされていて正しく動作していることを確認してください:
# efivar -l
efivar がエラーを出さずに uefi 変数を表示した時は、次に進んで下さい。エラーが出た場合、#UEFI 変数のサポートを正しく動作させるための必要条件 が全て満たされているか確認してください。
それから efibootmgr を使って以下のようにブートエントリを作成します:
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
上のコマンドにある /boot/efi/EFI/refind/refind_x64.efi は /boot/efi と /EFI/refind/refind_x64.efi になりドライブ /dev/sdX -> パーティション Y -> ファイル /EFI/refind/refind_x64.efi と翻訳されます。
'label' は UEFI ブートメニューで表示されるメニューエントリの名前です。この名前はユーザーが選ぶことができシステムのブートには影響がありません。詳しくは efibootmgr GIT README を見て下さい。
FAT32 ファイルシステムは UTF-8 エンコードを使わないのでデフォルトで大文字・小文字を区別しません。上の場合ではファームウェアは小文字の 'efi' の代わりに大文字の 'EFI' を使っていますが、\EFI\gummiboot\gummibootx64.efi と \efi\gummiboot\gummibootx64.efi に違いはありません (ファイルシステムのエンコードが UTF-8 の場合は話が変わります)。
UEFI ブートローダ
UEFI Bootloaders (日本語) を参照してください。
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 パーティション容量の制限よりは多くなります)。詳しくはここを見て下さい。
GPT でパーティションされたディスク
- gdisk (gptfdisk パッケージにあります) を使ってパーティションタイプ
ef00かEF00のパーティションを作成してください。そしてmkfs.vfat -F32 /dev/<THAT_PARTITION>を実行して FAT32 でパーティションをフォーマットしてください
もしくは
- GNU Parted で FAT32 パーティションを作成し、パーティションに
bootフラグ (legacy_bootフラグではありません) を設定してください
MBR でパーティションされたディスク
fdisk (util-linux パッケージにあります) を使ってパーティションタイプ 0xEF のパーティションを作成してください。そして mkfs.vfat -F32 /dev/<THAT_PARTITION> を実行して FAT32 でパーティションをフォーマットしてください
UEFI シェル
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
UEFI シェルを入手する
Intel の Tianocore UDK/EDK2 Sourceforge.net プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます。
- AUR uefi-shell-svn パッケージ (推奨) - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 SVN ソースから直接コンパイル
- Precompiled x86_64 UEFI Shell v2 binary (may not be up-to-date)
- Precompiled x86_64 UEFI Shell v1 binary (not updated anymore upstream)
- Precompiled IA32 UEFI Shell v2 binary (may not be up-to-date)
- Precompiled IA32 UEFI Shell v1 binary (not updated anymore upstream)
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 シェルコマンド
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。map は認識したファイルシステム (fs0, ...) やストレージデバイス (blk0, ...) をリストアップします。利用できるコマンドを表示するには help -b を実行してください。
詳しい情報は http://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
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 Linux ハードウェアの互換性
HCL/Firmwares/UEFI を参照してください。
UEFI ブータブルメディア
ISO から UEFI ブータブル USB を作成する
Linux
- 最初に MBR か GPT (推奨) のパーティションテーブルと USB に最低一つのパーティションを作成してください (これで既にパーティション済みの USB を使えるようになります)。
- Arch Linux download page から入手した ISO イメージをマウントしてください。
# mkdir -p /mnt/{usb,iso}
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso
- そして (必要ならアンマウントしてから) USB 上のパーティションに Archiso の設定で使われているラベルで FAT32 ファイルシステムを作成します。ラベルは
/mnt/iso/loader/entries/archiso-x86_64.confから取得してください; これは initramfs のarchisoフックでインストールメディアの udev パスを確認するために使われています。mkfs.vfatは dosfstools パッケージに入っています。
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n
- 新しく作った FAT32 USB パーティションをマウントし、USB メディアにインストールメディアの中身をコピーします。
# mount /dev/sdXY /mnt/usb
# cp -a /mnt/iso/* /mnt/usb
# sync
# umount /mnt/{usb,iso}
Windows
- USB ドライブを FAT32 でフォーマットします。
- 7-Zip を使って ISO を USB ドライブに (ZIP アーカイブを解凍するのと同じように) 展開してください。
- USB ドライブのボリュームラベルを
<USB>\loader\entries\archiso-x86_64.conf内に書かれている LABEL と一致するように変更してください。
ISO から UEFI ブートサポートを削除する
ほとんどの32ビット EFI Mac といくつかの64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。オプティカルメディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があります。
公式インストールメディアをマウントして前のセクションで示されているように archisolabel を取得してください。
libisoburn に含まれている xorriso を使って ISO を再生成してください:
$ xorriso -as mkisofs -iso-level 3 \
-full-iso9660-filenames\
-volid "ARCH_201212" \
-appid "Arch Linux CD" \
-publisher "Arch Linux <https://www.archlinux.org>" \
-preparer "prepared like a BAWSE" \
-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 "~/archiso.iso" "/mnt/iso/"
~/archiso.iso をオプティカルメディアに焼いて通常通りインストールに進んで下さい。
ネイティブサポートのない環境で UEFI をテストする
仮想マシン用の OVMF
OVMF [1] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
AUR ovmf-svn から OVMF (Secure Boot サポート付き) をビルドして次のように実行することができます:
qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin
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 イメージを提供する http://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の fix が含まれており gitorious リポジトリと比べて頻繁に更新されています。
トラブルシューティング
UEFI モードで Windows 7 が起動しない
If you have installed Windows to a different harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows won't boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.
Mainboards with this kind of problem:
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)
- UEFI BIOS option for booting UEFI Only doesn't pretend the UEFI BIOS from starting CSM
参照
- Wikipedia's page on UEFI
- Wikipedia's page on EFI SYSTEM Partition
- Linux Kernel x86_64 UEFI Documentation
- UEFI Forum - contains the official UEFI Specifications - GUID Partition Table is part of UEFI Specification
- Intel's Tianocore Project for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
- Intel's page on EFI
- FGA: The EFI boot process
- Microsoft's Windows and GPT FAQ - Contains info on Windows UEFI booting also
- Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall
- Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive
- Rod Smith - A BIOS to UEFI Transformation
- UEFI Boot problems on some newer machines (LKML)
- EFI Shells and Scripting - Intel Documentation
- UEFI Shell - Intel Documentation
- UEFI Shell - bcfg command info
- UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot
- LPC 2012 Plumbing UEFI into Linux
- LPC 2012 UEFI Tutorial : part 1
- LPC 2012 UEFI Tutorial : part 2