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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Kusakata がページ「Unified Extensible Firmware Interface (日本語)」を「Unified Extensible Firmware Interface」に移動しました)
(文字列「http://www.intel.com/」を「https://www.intel.com/」に置換)
(2人の利用者による、間の18版が非表示)
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 articles end}}
 
{{Related articles end}}
   
'''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日にリリス)
+
'''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 がリリースされました。ページでUEFI ブートローダの設定は説明ません。そのような情報は[[ブトロダー]]を見て下さい
   
  +
== 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 ファームウェアになります。}}
+
* EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。
  +
* 2015年4月15日現在、UEFI Specification 2.5 が最新のバージョンです。
  +
* Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。また、以下の手順は明白に書かれている部分を除き、一般的な UEFI を対象としており、場合によっては手順のいくつかは [[MacBook|Mac]] では動かなかったり違っていたりする可能性があります。
   
 
== BIOS ==
 
== BIOS ==
   
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 ブートプロセス]]を参照してください。
+
BIOS (Basic Input-Output System) はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラム(ファームウェア)です。ほとんどの場合マザーボード上のフラッシュメモリに保存されており、システムのストレージとは独立しています。BIOS は BIOS のディスク順で一番最初のディスクから最初の 440 バイト ([[Master Boot Record]]) を起動します。440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、通常は [[GRUB]], [[Syslinux]], [[LILO]] などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。詳しくは [[Arch ブートプロセス]]を参照してください。
   
 
== UEFI ==
 
== UEFI ==
45行目: 49行目:
 
=== UEFI のマルチブート ===
 
=== UEFI のマルチブート ===
   
OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるために[[Boot Loaders (日本語)|ブートローダ]]のロード機構に頼る必要はなくなります。
+
OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるために[[ブートローダ]]のロード機構に頼る必要はなくなります。
   
 
==== Microsoft Windows のブート ====
 
==== Microsoft Windows のブート ====
53行目: 57行目:
 
Windows のような制限は Linux カーネルには存在しませんが、使用するブートローダによっては制限が存在します。ただし同じディスクから Windows と Linux を起動したい時はブートローダ自体を使っているファームウェアとディスクパーティションに設定する必要があるので Windows の制限を考慮しなくてはなりません。同じディスクで Windows と Linux のデュアルブートをする場合、Windows によって使われている UEFI-GPT か BIOS-MBR のどちらかの方法に従うことを推奨します。
 
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 を見て下さい。
+
32ビットの Windows は BIOS-MBR ブートだけをサポートしています。従って、32ビットの Windows と Linux を同じディスクから起動するときは、使えるディスクは MBR だけです。詳しくは https://support.microsoft.com/kb/2581408 を見て下さい。
   
 
=== UEFI ファームウェアのビット数を調べる ===
 
=== UEFI ファームウェアのビット数を調べる ===
61行目: 65行目:
 
{{ic|/sys/firmware/efi}} ディレクトリが存在するかどうか確認してください。存在するときはカーネルは EFI モードで起動されています。この場合 UEFI のビット数はカーネルのビット数と同じです (i686 か x86_64)。
 
{{ic|/sys/firmware/efi}} ディレクトリが存在するかどうか確認してください。存在するときはカーネルは EFI モードで起動されています。この場合 UEFI のビット数はカーネルのビット数と同じです (i686 か x86_64)。
   
{{Note|Intel Atom System-on-Chip システムには 32-bit UEFI が載っています (2013年11月2日現在)。詳細は[[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|こページ]]を見て下さい。}}
+
{{Note|Intel Atom System-on-Chip システムには 32-bit UEFI が載っています (2013年11月2日現在)。詳細は [[#GRUB 使用]] を見て下さい。}}
   
 
==== Apple Mac ====
 
==== Apple Mac ====
69行目: 73行目:
 
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 の仕様に完全には準拠していないからです。
 
コマンドの返事が EFI32 なら、IA32 (32ビット) EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x86_64 EFI ファームウェアです。ほとんどの Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI 2.x の仕様に完全には準拠していないからです。
75行目: 79行目:
 
=== Secure Boot ===
 
=== Secure Boot ===
   
  +
[[セキュアブート]]を参照してください。
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 で起動しているかどうか確認するには、次のコマンドを使って下さい:
 
 
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data
 
 
このコマンドで 1 が返ってきたら Secure Boot で起動しています。1234 という所はマシンによって異なっています。タブ補完を使ったり efi 変数を表示することで調べることができます。
 
   
 
== UEFI の Linux カーネル設定オプション ==
 
== UEFI の Linux カーネル設定オプション ==
104行目: 99行目:
 
CONFIG_EFI_VARS=n
 
CONFIG_EFI_VARS=n
   
GUID Partition Table [[GUID Partition Table (日本語)|GPT]] 設定オプション - UEFI サポートのために必須
+
GUID Partition Table [[GUID Partition Table|GPT]] 設定オプション - UEFI サポートのために必須
   
 
CONFIG_EFI_PARTITION=y
 
CONFIG_EFI_PARTITION=y
126行目: 121行目:
 
==== efivarfs と sysfs-efivars の不一致 ====
 
==== 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日現在)。
+
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 だけがサポートされています。[[公式リポジトリ]]にある UEFI 変数に関連したツールは全て efivarfs をサポートしています (2013年10月1日現在)。
   
 
{{Note|sysfs-efivars を無効化した副作用として、Arch の公式カーネルでは {{ic|efi_pstore}} モジュールも無効になっています。}}
 
{{Note|sysfs-efivars を無効化した副作用として、Arch の公式カーネルでは {{ic|efi_pstore}} モジュールも無効になっています。}}
163行目: 158行目:
 
==== efivarfs のマウント ====
 
==== efivarfs のマウント ====
   
  +
{{Warning|1=デフォルトで ''efivars'' は書き込み可能でマウントされますが [https://github.com/systemd/systemd/issues/2402]、これによってシステムに致命的なダメージを与えてしまう可能性があります [https://bbs.archlinux.org/viewtopic.php?id=207549]。そのため、以下で説明しているように ''efivars'' は読み取り専用 ({{ic|-o ro}}) でマウントすることを考慮してください。ただし、読み取り専用でマウントした場合、''efibootmgr'' やブートローダーなどのツールがブート設定を変更できなくなってしまう上に、{{ic|systemctl reboot --firmware-setup}} などのコマンドが機能しなくなります。}}
起動時に [[systemd (日本語)|systemd]] によって自動で {{ic|efivarfs}} がマウントされなかった時は、手動で efivarfs をマウントして {{ic|efibootmgr}} などのユーザースペースツールを使うために UEFI Variable サポートを有効にする必要があります:
 
  +
  +
起動時に [[systemd]] によって自動で {{ic|efivarfs}} がマウントされなかった時は、手動で efivarfs をマウントして {{ic|efibootmgr}} などの[[#ユーザースペースツール|ユーザースペースツール]]を使うために UEFI Variable サポートを有効にする必要があります:
   
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
169行目: 166行目:
 
{{Note|上のコマンドは '''chroot''' の前と後、両方で実行する必要があります。}}
 
{{Note|上のコマンドは '''chroot''' の前と後、両方で実行する必要があります。}}
   
下のように {{ic|/etc/fstab}} で起動時 {{ic|efivarfs}} を自動でマウントするよう記述すると良いかもしれません:
+
起動時 {{ic|efivarfs}} を読み取り専用でマウントするには、{{ic|/etc/fstab}} に以下を追加:
   
{{hc|/etc/fstab|<nowiki>
+
{{hc|/etc/fstab|2=
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0
+
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0
  +
}}
</nowiki>}}
 
  +
  +
書き込み可能で再マウントするには、次を実行:
  +
  +
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime
   
 
=== ユーザースペースツール ===
 
=== ユーザースペースツール ===
180行目: 181行目:
   
 
* {{App|efivar|UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)|https://github.com/vathpela/efivar|{{Pkg|efivar}} または {{AUR|efivar-git}}}}
 
* {{App|efivar|UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)|https://github.com/vathpela/efivar|{{Pkg|efivar}} または {{AUR|efivar-git}}}}
* {{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 の設定を操作するツール。上流の (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}}{{Broken package link|パッケージが存在しません}}}}
 
* {{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 のコードを使っています)。2.0 は efivarfs だけをサポートしていて 1.0 は sysfs-efivars だけをサポートしています。|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 Secure Boot の証明書・キー・署名済みのバイナリを作成・設定するためのツール (efivarfs を必要とします)|http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/|{{Pkg|efitools}} または {{AUR|efitools-git}}{{Broken package link|パッケージが存在しません}}}}
* {{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|Ubuntu のファームウェアテストスイート。|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (と {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) もしくは {{AUR|fwts-git}}}}
   
 
==== efibootmgr ====
 
==== efibootmgr ====
224行目: 225行目:
 
== EFI System Partition ==
 
== EFI System Partition ==
   
  +
[[EFI システムパーティション]]を参照してください。
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}} フラグではありません) を設定してください
 
 
{{Note|次のメッセージが表示される場合 <code>WARNING: Not enough clusters for a 32 bit FAT!</code> クラスタ容量を <code>mkfs.fat -s2 -F32 ...</code> か <code>-s1</code> で減らしてください。そうしないとパーティションが UEFI によって読み込めなくなってしまいます。}}
 
 
=== MBR でパーティションされたディスク ===
 
 
fdisk ({{Pkg|util-linux}} パッケージにあります) を使ってパーティションタイプ {{ic|0xEF}} のパーティションを作成してください。そして {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}} を実行して FAT32 でパーティションをフォーマットしてください
 
 
=== 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 シェル ==
253行目: 233行目:
 
=== UEFI シェルを入手する ===
 
=== UEFI シェルを入手する ===
   
Intel の Tianocore UDK/EDK2 Sourceforge.net プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます
+
Intel の Tianocore UDK/EDK2 Sourceforge.net プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:
   
* [[Arch User Repository (日本語)|AUR]] '''{{AUR|uefi-shell-svn}}''' パッケージ (推奨) - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 SVN ソースから直接コンパイル
+
* [[Arch User Repository|AUR]] '''{{AUR|uefi-shell-git}}''' パッケージ (推奨) - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 SVN ソースから直接コンパイル
  +
* Arch のインストールメディアイメージには EFI ディレクトリに Shell v1 と Shell v2 のコピーが存在します
* [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)
 
* [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)
+
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 バイナリ] (may not be up-to-date)
* [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://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 バイナリ] (not updated anymore upstream)
* [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 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] を見て下さい。
+
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは [https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] や [https://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail] を見て下さい。
   
 
=== UEFI シェルの起動 ===
 
=== UEFI シェルの起動 ===
273行目: 252行目:
 
=== 重要な 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/
   
 
==== bcfg ====
 
==== bcfg ====
   
BCFG コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては "UEFI Shell Specification 2.0" pdf ドキュメントの 83 ページ (Section 5.3) で詳しく説明されています。
+
{{ic|bcfg}} コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては "UEFI Shell Specification 2.0" pdf ドキュメントの 83 ページ (Section 5.3) で詳しく説明されています。
   
 
{{Note|
 
{{Note|
286行目: 265行目:
 
}}
 
}}
   
現在のブートエントリのリストを出力するには -
+
現在のブートエントリのリストを出力するには:
   
 
Shell> bcfg boot dump -v
 
Shell> bcfg boot dump -v
311行目: 290行目:
   
 
Shell> bcfg -? -v -b
 
Shell> bcfg -? -v -b
  +
  +
==== map ====
  +
  +
{{ic|map}} はデバイスマッピング (利用可能なファイルシステム ({{ic|fs0}}) とストレージデバイス ({{ic|blk0}}) の名前) の一覧を表示します。
  +
  +
{{ic|cd}} や {{ic|ls}} などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります:
  +
  +
Shell> fs0:
  +
fs0:\> cd EFI/
   
 
==== edit ====
 
==== edit ====
   
EDIT コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
+
{{ic|edit}} コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
   
 
例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic|fs0:}})
 
例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic|fs0:}})
323行目: 311行目:
   
 
ヘルプを出すには {{ic|Ctrl-E}} を押して下さい。
 
ヘルプを出すには {{ic|Ctrl-E}} を押して下さい。
 
== UEFI Linux ハードウェアの互換性 ==
 
 
[[HCL/Firmwares/UEFI]] を参照してください。
 
   
 
== UEFI ブータブルメディア ==
 
== UEFI ブータブルメディア ==
332行目: 316行目:
 
=== ISO から UEFI ブータブル USB を作成する ===
 
=== ISO から UEFI ブータブル USB を作成する ===
   
[[USB Installation Media (日本語)#BIOS・UEFI ブータブル USB|USB インストールメディア#BIOS・UEFI ブータブル USB]] を参照してください。
+
[[USB インストールメディア#BIOS・UEFI ブータブル USB]] を参照してください。
   
 
=== オプティカルメディアから UEFI ブートサポートを削除する ===
 
=== オプティカルメディアから UEFI ブートサポートを削除する ===
368行目: 352行目:
 
[https://tianocore.github.io/ovmf/ OVMF] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
 
[https://tianocore.github.io/ovmf/ OVMF] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
   
AUR {{AUR|ovmf-svn}} から OVMF (Secure Boot サポト付き) をビして次のように実行することができます:
+
[[公式リポジトリ]]から {{pkg|ovmf}} をインストールして次のように実行することができます:
   
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -pflash /usr/share/ovmf/x86_64/bios.bin
+
$ 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 ===
 
=== BIOS システム用の DUET ===
376行目: 360行目:
 
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 プロジェクトです。この方法については 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 リポジトリと比べて頻繁に更新されています。
+
また、修正 DUET イメージを提供する https://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の fix が含まれており gitorious リポジトリと比べて頻繁に更新されています。
   
 
== トラブルシューティング ==
 
== トラブルシューティング ==
386行目: 370行目:
 
この問題が起こるマザーボード:
 
この問題が起こるマザーボード:
   
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS バージョン F19e)
+
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS バージョン F19e)
  +
** UEFI を起動するための UEFI BIOS オプションだけでは UEFI BIOS による CSM の起動を阻止できません
 
- UEFI を起動するための UEFI BIOS オプションだけでは UEFI BIOS による CSM の起動を阻止できません
 
   
 
=== Windows によってブート順序が変わってしまう ===
 
=== Windows によってブート順序が変わってしまう ===
396行目: 379行目:
 
=== USB メディアが黒画面で固まる ===
 
=== USB メディアが黒画面で固まる ===
   
* この問題は [[Kernel Mode Setting (日本語)|KMS]] の問題によって起こることがあります。USB を起動するときは [[Kernel_Mode_Setting (日本語)#モードセッティングを無効にする|KMS を無効化]]してみて下さい。
+
* この問題は [[Kernel Mode Setting|KMS]] の問題によって起こることがあります。USB を起動するときは [[Kernel_Mode_Setting#モードセッティングを無効にする|KMS を無効化]]してみて下さい。
   
* 問題が 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]] を使って下さい。
+
* 問題が KMS によるものではない場合、おそらく [[EFISTUB]] ブートのバグによる問題です (詳しくは {{Bug|33745}} や [https://bbs.archlinux.org/viewtopic.php?id=156670] を見て下さい)。公式 ISO ([[Archiso]]) と [[Archboot]] iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは [[Gummiboot]] ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして [[GRUB]] を使って下さい。
   
 
==== GRUB の使用 ====
 
==== GRUB の使用 ====
   
* [[USB Installation Media (日本語)#BIOS・UEFI ブータブル USB|USB インストールメディア#BIOS・UEFI ブータブル USB]] に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。
+
* [[USB インストールメディア#BIOS・UEFI ブータブル USB]] に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。
   
 
* {{ic|<USB>/EFI/boot/loader.efi}} を {{ic|<USB>/EFI/boot/gummiboot.efi}} にバックアップしてください。
 
* {{ic|<USB>/EFI/boot/loader.efi}} を {{ic|<USB>/EFI/boot/gummiboot.efi}} にバックアップしてください。
   
* [[GRUB (日本語)#GRUB_Standalone|GRUB スタンドアロンイメージを作成]]して {{ic|<USB>/EFI/boot/loader.efi}} にコピーしてください。
+
* [[GRUB#GRUB_Standalone|GRUB スタンドアロンイメージを作成]]して {{ic|<USB>/EFI/boot/loader.efi}} にコピーしてください。
   
* 以下の内容で {{ic|<USB>/EFI/boot/grub.cfg}} を作成してください ({{ic|ARCH_YYYYMM}} は USB ディスクのラベルに置き換えて下さい、例: {{ic|ARCH_201404}}):
+
* 以下の内容で {{ic|<USB>/EFI/boot/grub.cfg}} を作成してください ({{ic|ARCH_YYYYMM}} は USB ディスクのラベルに置き換えて下さい、例: {{ic|ARCH_201507}}):
   
 
{{hc|grub.cfg for Official ISO|<nowiki>
 
{{hc|grub.cfg for Official ISO|<nowiki>
483行目: 466行目:
 
}
 
}
 
</nowiki>}}
 
</nowiki>}}
  +
  +
=== ファームウェアのメニューに UEFI ブートローダーが表示されない ===
  +
  +
Intel Z77 チップセットなどが搭載された UEFI マザーボードでは、EFI シェルから {{ic|efibootmgr}} や {{ic|bcfg}} を使ってエントリを追加しても、ブートメニューのリストに表示されないため使うことができません。
  +
  +
この問題はマザーボードが Microsoft Windows しかロードしないようになっているのが原因です。解決するには Windows が使っている場所に {{ic|.efi}} ファイルを配置するしかありません。
  +
  +
Arch Linux のインストールメディア ({{ic|FSO:}}) から {{ic|bootx64.efi}} ファイルをコピーしてハードドライブ ({{ic|FS1:}}) 上の ESP パーティションの Microsoft ディレクトリに配置してください。EFI シェルを起動して以下を実行します:
  +
  +
FS1:
  +
cd EFI
  +
mkdir Microsoft
  +
cd Microsoft
  +
mkdir Boot
  +
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
  +
  +
再起動後、NVRAM に追加されたエントリがブートメニューに表示されるはずです。
   
 
== 参照 ==
 
== 参照 ==
   
 
* [[Wikipedia:ja:UEFI]]
 
* [[Wikipedia:ja:UEFI]]
* [http://www.uefi.org/home/ UEFI Forum] - 公式の [http://www.uefi.org/specs/ UEFI の仕様書] - GUID Partition Table は UEFI の仕様に含まれています
+
* [http://www.uefi.org/home/ UEFI Forum] - 公式の [http://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 によるブログ記事]
* [[Wikipedia:EFI System partition]]
 
* [http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI System Partition and the Default Boot Behavior]
 
 
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux カーネル x86_64 UEFI ドキュメント]
 
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux カーネル x86_64 UEFI ドキュメント]
* [http://www.intel.com/technology/efi/ Intel の EFI に関するページ]
+
* [https://www.intel.com/technology/efi/ Intel の EFI に関するページ]
 
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]
 
* [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]
 
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
501行目: 499行目:
 
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1]
 
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1]
 
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI チュートリアル : part 2]
 
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI チュートリアル : part 2]
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel の Tianocore プロジェクト] 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
+
* [https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel の Tianocore プロジェクト] 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
 
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]
 
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]
 
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft の Windows と GPT の FAQ]
 
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft の Windows と GPT の FAQ]
507行目: 505行目:
 
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成]
 
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成]
 
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
 
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel ドキュメント]
+
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel ドキュメント]
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel ドキュメント]
+
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel ドキュメント]
 
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報]
 
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報]
 
* [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]
 
* [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]

2018年2月7日 (水) 00:17時点における版

関連記事

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

UEFI のバージョン

  • EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。
  • 2015年4月15日現在、UEFI Specification 2.5 が最新のバージョンです。
  • Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。また、以下の手順は明白に書かれている部分を除き、一般的な UEFI を対象としており、場合によっては手順のいくつかは Mac では動かなかったり違っていたりする可能性があります。

BIOS

BIOS (Basic Input-Output System) はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラム(ファームウェア)です。ほとんどの場合マザーボード上のフラッシュメモリに保存されており、システムのストレージとは独立しています。BIOS は BIOS のディスク順で一番最初のディスクから最初の 440 バイト (Master Boot Record) を起動します。440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、通常は GRUB, Syslinux, LILO などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。詳しくは Arch ブートプロセスを参照してください。

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 のブートプロセス

  1. システムのスイッチが入る - POST (Power On Self Test) プロセス
  2. UEFI ファームウェアがロードされます。ファームウェアは起動に必要なハードウェアを初期化します
  3. 次にファームウェアはブートマネージャのデータを読み込みどの UEFI アプリケーションをどこから (つまりどのディスク・パーティションから) 起動するか決定します
  4. ファームウェアのブートマネージャのブートエントリに定義されているように UEFI アプリケーションをファームウェアが起動します
  5. 起動した UEFI アプリケーションは設定によって他のアプリケーション (UEFI シェルや rEFInd の場合) やカーネルと initramfs (GRUB などのブートローダの場合) を起動します
ノート: UEFI 環境によってはブート時に UEFI アプリケーションを起動する唯一の方法が (UEFI ブートメニューでカスタムエントリがない場合) 指定位置にアプリケーションを配置することです: <EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi (64ビットの x86 環境)

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 だけです。詳しくは https://support.microsoft.com/kb/2581408 を見て下さい。

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

Mac でない場合

/sys/firmware/efi ディレクトリが存在するかどうか確認してください。存在するときはカーネルは EFI モードで起動されています。この場合 UEFI のビット数はカーネルのビット数と同じです (i686 か x86_64)。

ノート: Intel Atom System-on-Chip システムには 32-bit UEFI が載っています (2013年11月2日現在)。詳細は #GRUB の使用 を見て下さい。

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 の仕様に完全には準拠していないからです。

Secure Boot

セキュアブートを参照してください。

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
ノート: Linux を UEFI で起動するには上記のオプション全てが必要です。公式リポジトリの Archlinux カーネルでは有効になっています。

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt より。

UEFI 変数

UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:

$ efivar -l

Linux カーネルでの UEFI 変数のサポート

Linux カーネルは2つのインターフェイスを使って EFI 変数のデータをユーザ空間に渡します:

  1. 新しい efivarfs インターフェイス (efivarfs カーネルモジュールによって /sys/firmware/efi/efivars にマウントされます) は sysfs-efivars インターフェイスの限界を越えるために作られました。変数のサイズ制限を取り払って、UEFI Secure Boot 変数をサポートしておりカーネルの上流から使用を推奨されています。カーネル 3.8 から導入され、カーネル 3.10 では efivars カーネルモジュールから efivarfs モジュールは分割されています。
  2. 古い sysfs-efivars インターフェイス (efivars カーネルモジュールによって /sys/firmware/efi/vars に生成されます) には変数のサイズ制限などがあり、上流のカーネルではサポートされていますが Arch の公式カーネルでは完全に無効になっています。

efivarfs と sysfs-efivars の不一致

sysfs-efivars と efivarfs は同時に実行することが可能ですが、データを同時に修正した時、sysfs-efivars と efivarfs のデータに不一致が生じるおそれがあります (詳しくは https://lkml.org/lkml/2013/4/16/473 を見て下さい)。core/linux 3.11 と core/linux-lts 3.10 から sysfs-efivars は無効になりました (これは Arch のカーネルでの変更です、上流では sysfs-efivars のコードは削除されていません)。Arch では、efivarfs だけがサポートされています。公式リポジトリにある UEFI 変数に関連したツールは全て efivarfs をサポートしています (2013年10月1日現在)。

ノート: sysfs-efivars を無効化した副作用として、Arch の公式カーネルでは 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 変数のサポートを正しく動作させるための必要条件

  1. EFI Runtime Services サポートがカーネルに存在する必要があります (CONFIG_EFI=y)。zgrep CONFIG_EFI /proc/config.gz で確認できます。
  2. カーネルのプロセッサのビット数・アーキテクチャが EFI のビット数・アーキテクチャと一致していなくてはなりません
  3. カーネルは EFI モードで起動して下さい (via EFISTUB or any EFI bootloader, not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM)
  4. カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり noefi カーネルパラメータは使わないで下さい
  5. efivarfs ファイルシステムが /sys/firmware/efi/efivars にマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい
  6. efivar はエラーを出さずに EFI 変数をリストアップ (-l オプション) するはずです。出力の例は #UEFI 変数のサンプルリスト を見て下さい

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

  1. ユーザスペースのツールが efi 変数のデータを修正できない場合、/sys/firmware/efi/efivars/dump-* ファイルが存在しているかチェックしてください。存在しているときは、ファイルを削除してから再起動してもう一度試して下さい。
  2. 上の手順で問題が修正されない場合、efi_no_storage_paranoia カーネルパラメータを使って起動してカーネルの efi 変数ストレージ領域チェックを無効にしてください。これによって efi 変数の書き込み・修正が止められている可能性があります。
ノート: efi_no_storage_paranoia は必要な時だけに使い、通常のブートオプションに使用してはいけません。このカーネルコマンドライン・パラメータは NVRAM を満杯にしてマシンを文鎮化するようなことを避ける安全装置を外してしまいます。

efivarfs のマウント

警告: デフォルトで efivars は書き込み可能でマウントされますが [1]、これによってシステムに致命的なダメージを与えてしまう可能性があります [2]。そのため、以下で説明しているように efivars は読み取り専用 (-o ro) でマウントすることを考慮してください。ただし、読み取り専用でマウントした場合、efibootmgr やブートローダーなどのツールがブート設定を変更できなくなってしまう上に、systemctl reboot --firmware-setup などのコマンドが機能しなくなります。

起動時に systemd によって自動で efivarfs がマウントされなかった時は、手動で efivarfs をマウントして efibootmgr などのユーザースペースツールを使うために UEFI Variable サポートを有効にする必要があります:

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

起動時に efivarfs を読み取り専用でマウントするには、/etc/fstab に以下を追加:

/etc/fstab
efivarfs    /sys/firmware/efi/efivars    efivarfs    ro,nosuid,nodev,noexec,noatime 0 0

書き込み可能で再マウントするには、次を実行:

# mount -o remount /sys/firmware/efi/efivars -o rw,nosuid,nodev,noexec,noatime

ユーザースペースツール

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

  • efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
https://github.com/vathpela/efivar || efivar または efivar-gitAUR
  • 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 || efibootmgr または efibootmgr-gitAUR[リンク切れ: パッケージが存在しません]
  • uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。2.0 は efivarfs だけをサポートしていて 1.0 は sysfs-efivars だけをサポートしています。
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  • efitools — UEFI Secure Boot の証明書・キー・署名済みのバイナリを作成・設定するためのツール (efivarfs を必要とします)。
http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/ || efitools または efitools-gitAUR[リンク切れ: パッケージが存在しません]
  • Ubuntu's Firmware Test Suite — Ubuntu のファームウェアテストスイート。
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwtsAUR[リンク切れ: アーカイブ: aur-mirror] (と fwts-efi-runtime-dkmsAUR[リンク切れ: アーカイブ: aur-mirror]) もしくは fwts-gitAUR

efibootmgr

警告: Apple Mac で efibootmgr を使うとファームウェアが塞がれマザーボード ROM のリセットが必要になる可能性があります。これに関して Ubuntu/Launch バグトラッカーでバグの報告があります。Mac の場合は bless コマンドだけを使って下さい。Fedora の開発者による実験的な Linux 用 "bless" ユーティリティがあります - mactel-bootAUR
ノート:
  • あなたの環境で efibootmgr が完全に動かない場合、再起動して UEFI Shell v2 に入り bcfg コマンドを使ってブートローダのブートエントリを作成してください。
  • efibootmgr を使えない場合、UEFI BIOS によっては BIOS から直接 uefi のブートオプションを管理できることがあります。例えば、ASUS の BIOS には "Add New Boot Option" からローカルの EFI System Partition を選択して直接 EFI スタブの位置を入力できます (例えば \EFI\refind\refind_x64.efi)。
  • 下のコマンドではサンプルとして refind-efi ブートローダを使っています。
  • 上流の efibootmgr http://linux.dell.com/git/efibootmgr.git は efivarfs をサポートしていません。ただし公式の efibootmgr パッケージでは vathpela の efibootmgr が起用されており efivarfs をサポートしています。また、公式の Arch カーネルでは sysfs-efivars は完全に無効になっていて efivarfs だけをサポートしています。このセクションはあなたが efivarfs と vathpela の 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 と仮定します (この XY は本当の値の代替値です - 例:- /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"
ノート: UEFI はパスの区切り記号としてバックスラッシュ \ を使います (Windows のパスと似ています)。ただし公式の efibootmgr パッケージはパスの区切りにスラッシュ / を使う unix 形式のパスを -l オプションでサポートしています。Efibootmgr はローダーのパスを変換する前に /\ に内部で変換します。この機能を efibootmgr に組み込む git コミットは http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 です。

上のコマンドにある /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 の場合は話が変わります)。

EFI System Partition

EFI システムパーティションを参照してください。

UEFI シェル

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

UEFI シェルを入手する

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

  • AUR uefi-shell-gitAUR パッケージ (推奨) - x86_64 環境の x86_64 シェルと i686 環境の IA32 シェルを提供します - 最新の Tianocore EDK2 SVN ソースから直接コンパイル
  • Arch のインストールメディアイメージには EFI ディレクトリに Shell v1 と Shell v2 のコピーが存在します
  • Precompiled UEFI Shell v2 バイナリ (may not be up-to-date)
  • Precompiled UEFI Shell v1 バイナリ (not updated anymore upstream)

Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkgthis 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) の名前) の一覧を表示します。

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

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 をオプティカルメディアに焼いて通常通りインストールに進んで下さい。

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

仮想マシン用の OVMF

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

公式リポジトリから 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://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 イメージを提供する https://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の fix が含まれており gitorious リポジトリと比べて頻繁に更新されています。

トラブルシューティング

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>/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 マザーボードでは、EFI シェルから efibootmgrbcfg を使ってエントリを追加しても、ブートメニューのリストに表示されないため使うことができません。

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

Arch Linux のインストールメディア (FSO:) から bootx64.efi ファイルをコピーしてハードドライブ (FS1:) 上の ESP パーティションの Microsoft ディレクトリに配置してください。EFI シェルを起動して以下を実行します:

FS1:
cd EFI
mkdir Microsoft
cd Microsoft
mkdir Boot
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi

再起動後、NVRAM に追加されたエントリがブートメニューに表示されるはずです。

参照