Difference between revisions of "Unified Extensible Firmware Interface (日本語)"

From ArchWiki
Jump to: navigation, search
m (Package renamed.)
m
Line 118: Line 118:
 
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}
 
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}
  
UEFI ランタイムサービスへのアクセスは "efivars" カーネルモジュールによって提供されています。このモジュールは {{ic|<nowiki>CONFIG_EFI_VAR=m</nowiki>}} カーネルコンフィグオプションで有効にします。一度モジュールがロードされると {{ic|/sys/firmware/efi/vars}} 下に変数が現れます。システムが UEFI ブートモードで起動したかどうか確認するひとつの方法は、"efivars" カーネルモジュールをロードして {{ic|/sys/firmware/efi/vars}} ディレクトリが以下のような内容で存在しているか確認することです:
+
UEFI ランタイムサービスへのアクセスは "efivars" カーネルモジュールによって提供されています。このモジュールは {{ic|<nowiki>CONFIG_EFI_VAR=y</nowiki>}} カーネルコンフィグオプションで有効にします。モジュールがロードされると {{ic|/sys/firmware/efi/vars}} 下 (カーネル3.8以降では {{ic|/sys/firmware/efi/efivars}}) に変数が現れます。システムが UEFI ブートモードで起動したかどうか確認するひとつの方法は、"efivars" カーネルモジュールをロードして {{ic|/sys/firmware/efi/vars}} (カーネル3.8以降では {{ic|/sys/firmware/efi/efivars}}) ディレクトリが以下のような内容で存在しているか確認することです:
  
 
  サンプル出力 (x86_64 カーネルの x86_64-UEFI 2.3.1):
 
  サンプル出力 (x86_64 カーネルの x86_64-UEFI 2.3.1):
Line 164: Line 164:
 
UEFI ブートローダがインストールされシステムが BIOS モードで起動した場合、最初にユーザーは手動でファームウェアからブートローダを起動する必要があります (UEFI シェルを使います)。それから {{ic|efibootmgr}} を実行して UEFI ブートローダエントリを UEFI ブートマネージャのデフォルトエントリにする必要があります。
 
UEFI ブートローダがインストールされシステムが BIOS モードで起動した場合、最初にユーザーは手動でファームウェアからブートローダを起動する必要があります (UEFI シェルを使います)。それから {{ic|efibootmgr}} を実行して UEFI ブートローダエントリを UEFI ブートマネージャのデフォルトエントリにする必要があります。
  
efibootmgr を使うには、まず 'efivars' カーネルモジュールをロードします:
+
efibootmgr を使うには、(モジュールとしてコンパイルされている場合) まず 'efivars' カーネルモジュールをロードします:
  
 
  # modprobe efivars
 
  # modprobe efivars
Line 170: Line 170:
 
もしこのコマンドで '''no such device found''' エラーが表示されるなら、それはシステムが UEFI モードで起動してないか、なんらかの理由でカーネルが UEFI ランタイム変数にアクセスできないことを意味しています (noefi?)。
 
もしこのコマンドで '''no such device found''' エラーが表示されるなら、それはシステムが UEFI モードで起動してないか、なんらかの理由でカーネルが UEFI ランタイム変数にアクセスできないことを意味しています (noefi?)。
  
''/sys/firmware/efi/vars/'' ディレクトリにファイルがあるかどうか確認してください。このディレクトリとその中身は "efivars" カーネルモジュールによって作成されます、そして UEFI モードで起動し、"noefi" カーネルパラメータが使われていないときだけ存在しているはずです。
+
''/sys/firmware/efi/vars/'' (カーネル3.8以上では ''/sys/firmware/efi/efivars/'') ディレクトリにファイルがあるかどうか確認してください。このディレクトリとその中身は "efivars" カーネルモジュールによって作成されます、そして UEFI モードで起動し、"noefi" カーネルパラメータが使われていないときだけ存在しているはずです。
  
 
''/sys/firmware/efi/vars/'' ディレクトリが空だったり存在しない場合、{{ic|efibootmgr}} コマンドは動作しません。UEFI モードで ISO/CD/DVD/USB の起動ができない場合は [[#ISO から UEFI ブータブル USB を作成する]] を試して下さい。
 
''/sys/firmware/efi/vars/'' ディレクトリが空だったり存在しない場合、{{ic|efibootmgr}} コマンドは動作しません。UEFI モードで ISO/CD/DVD/USB の起動ができない場合は [[#ISO から UEFI ブータブル USB を作成する]] を試して下さい。
  
 
{{Note|以下のコマンドでは例として {{Pkg|gummiboot}} ブートローダを使っています。}}
 
{{Note|以下のコマンドでは例として {{Pkg|gummiboot}} ブートローダを使っています。}}
 +
{{out of date|現在 [[Gummiboot]] は自身のインストーラを持っています。よって以下の手順は [[gummiboot]] をインストールするのに使ってはいけません。例を変える必要があります。}}
  
 
起動するブートローダファイルが {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} だと仮定します。{{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} は {{ic|/boot/efi}} と {{ic|/EFI/gummiboot/gummibootx64.efi}} とに分割できますが、{{ic|/boot/efi}} は UEFI システムパーティションのマウントポイントで、ここでは {{ic|/dev/sdXY}} と仮定します (この X と Y は本当の値の代替値です - 例:- {{ic|/dev/sda1}} , X=a Y=1)。
 
起動するブートローダファイルが {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} だと仮定します。{{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} は {{ic|/boot/efi}} と {{ic|/EFI/gummiboot/gummibootx64.efi}} とに分割できますが、{{ic|/boot/efi}} は UEFI システムパーティションのマウントポイントで、ここでは {{ic|/dev/sdXY}} と仮定します (この X と Y は本当の値の代替値です - 例:- {{ic|/dev/sda1}} , X=a Y=1)。
Line 202: Line 203:
 
== Linux で UEFI システムパーティションを作る ==
 
== Linux で UEFI システムパーティションを作る ==
  
{{Note|UEFISYS パーティションのサイズは FAT32 ファイルシステムでサポートされている範囲で自由に決めることができます。Microsoft のドキュメントによれば、FAT32 の最小パーティション・ボリュームサイズは 512 MiB です。従って UEFISYS パーティションには少なくとも 512 MiB を割り当てることが推奨されます。パーティションのサイズは多いほうが良く、特に複数の UEFI ブートローダを使う場合や UEFI を使って複数の OS をブートする場合、関連ファイルを全て保存できる十分な容量を確保してください。Linux EFISUTB ブートを使おうと思っているならば、まず UEFISYS パーティションにカーネルと Initramfs ファイルが入る十分な容量があるか確認してください。}}
+
{{Note|UEFI System Partition と EFI System Partition (ESP) は同じものです。}}
 +
{{Note|UEFISYS パーティションのサイズは FAT32 ファイルシステムでサポートされている範囲で自由に決めることができます。Microsoft のドキュメントによれば、FAT32 の最小パーティション・ボリュームサイズは 512 MiB です。しかしながら多くの Linux ディストロや Microsoft Windows では FAT32 でフォーマットされた ESP は 100 MiB からサポートしているので、パーティションは小さくするほうが良いかもしれません。ただし互換性を保つには ESP は 512 MiB 以上の容量を取るのが推奨されます。ext2/3/4, reiserfs, NTFS, UDF などの FAT 以外のファイルシステムはサポートされていません。}}
 +
{{Note|ESP は LVM などのソフトウェア RAID や RAID ライクなシステムの外に置く必要があります。ESP は UEFI ファームウェアによってアクセスされるので、LVM などのシステムを読み込むことができません。}}
 +
{{Note|Linux EFISUTB ブートを使おうと思っているならば、まず UEFISYS パーティションにカーネルと Initramfs ファイルが入る十分な容量があるか確認してください。}}
  
 
=== GPT でパーティションされたディスク ===
 
=== GPT でパーティションされたディスク ===

Revision as of 08:03, 20 March 2013

概括 help replacing me
Unified Extensible Firmware Interface の概要。
概要
Template:Boot process overview (日本語)
関連項目
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 がリリースされました。2012年5月23日現在、UEFI の仕様は 2.3.1 が一番新しいバージョンです。

Note: EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。また、以下の手順は明白に書かれている部分を除き、一般的なものであり、Mac 特有のものではありません。手順のいくつかは Mac では動かなかったり違っていたりする可能性があります。Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは UEFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。

BIOS を使って OS を起動する

BIOS、Basic Input-Output System、はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラムです。ハードウェアの初期化と POST 処理が全て完了すると、BIOS はデバイスブートリストの最初のデバイスの最初のブートコードを実行します。

リストが CD/DVD ドライブから始まっている場合、CD/DVD の El-Torito エントリを実行します。これが、ブータブル CD/DVD が動作する仕組みです。リストが HDD から始まっている場合、BIOS は一番最初の 440 バイトの MBR ブートコードを実行します。ブートコードはより巨大でより複雑なブートローダを起動させ、さらにそのブートローダが OS をロードします。

基本的に、BIOS はパーティションテーブルやファイルシステムの読み方を知りません。BIOS がすることは、ハードウェアの初期化と 440 バイトのブートコードのロード・実行だけです。

BIOS でのマルチブート

440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、BIOS を使ってマルチブートするにはマルチブート対応のブートローダが必要になります(ここで、マルチブートとは複数のオペレーティングシステムを起動することであり、GRUB 開発者によって明示された Multiboot フォーマット内のカーネルを起動することではありません)。そのため普通は GRUB, Syslinux, LILO などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。

UEFI を使って OS を起動する

UEFI ファームウェアは上で述べているような (BIOS によって唯一サポートされている) 方法での起動はサポートしていません。UEFI は分かりやすいファイルシステムとパーティションテーブル、その両方の読み込みをサポートしています。

一般的に使われている 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 でフォーマットされています。

UEFI では、全てのプログラム (OS ローダ、(メモリテストアプリなどの)ユーティリティ、リカバリーツール) は EFI ファームウェアアーキテクチャに対応する UEFI アプリケーションでなくてはなりません。最近の Apple Mac を含む、市場に出ているほとんどの UEFI ファームウェアは x86_64 EFI ファームウェアを使っています。古い mac だけが i386 ファームウェアを使っています、Apple 以外の UEFI システムは i386 EFI ファームウェアを使っていません。

Note: 古い Intel サーバーボードには Intel EFI 1.10 ファームウェアを使っているものがあることが知られています、それらは i386 EFI アプリケーションを必要とします。

64 ビット Linux や Windows とは異なり、x86_64 EFI ファームウェアは 32 ビットの EFI アプリを実行することができません。従ってブートローダがアーキテクチャに正しくコンパイルされている必要があります。

UEFI でのマルチブート

OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるためにブートローダのロード機構に頼る必要はなくなります。

Linux Windows x86_64 UEFI-GPT マルチブート

Windows Vista (SP1+) や 7、8 の x86_64 版は UEFI ファームウェアを使った起動をネイティブでサポートしています。しかしそれをするためには、UEFI ブートに使うディスクが GPT でパーティションされている必要があります。Windows の x86_64 版は UEFI-GPT ブートと BIOS-MBR ブート両方をサポートしています。Windows の 32 ビット版は BIOS-MBR ブートしかサポートしていません。マルチブートをどうやるのかはリファレンスセクション内のフォーラムリンクにある指示に従ってください。詳しくは http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 を見て下さい。

Windows のような制限は Linux カーネルには存在しませんが、使用するブートローダによっては制限が存在します。Windows UEFI ブートの手前、同じディスクから起動するときには使用する Linux ブートローダも UEFI-GPT モードでインストールしなくてはなりません。

UEFI でのブートプロセス

  1. システムに電源が入る - Power On Self Test, POST 処理が行われる。
  2. UEFI ファームウェアがロードされる。
  3. ファームウェアはブートマネージャを読み込み、起動する UEFI アプリケーションがどれかを決める。
  4. ファームウェアのブートマネージャのブートエントリで定義されているように、ファームウェアは、FAT32 でフォーマットされた UEFISYS パーティションから UEFI アプリケーションを起動する。
  5. UEFI アプリケーションの設定により、UEFI アプリケーションは他のアプリケーションを起動したり (UEFI シェルや rEFInd などのブートマネージャの場合) またはカーネルや initramfs を起動する (GRUB などのブートローダの場合)。

UEFI ファームウェアアーキテクチャ

mac 以外の UEFI システムの場合、ファームウェアは x86_64 (または 64 ビット) UEFI 2.x です。

知られている x86_64 UEFI 2.x ファームウェアには Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O などがあります。

それらファームウェアを使っているシステムとして知られているものには Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, Intel の多くのサーバー・デスクトップマザーボードなどがあります。


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 なら、i386 EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x86_64 EFI 1.x ファームウェアです。Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI の仕様に完全には準拠していないからです。

Linux カーネルの UEFI サポート

UEFI の Linux カーネル設定オプション

UEFI システムのために必要な Linux カーネル設定オプションは:

CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_RELOCATABLE=y
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y

UEFI ランタイム変数・サービスは 'efivars' カーネルモジュールをサポートしています。efibootmgr のようなツールを使って UEFI ランタイム変数を操作するには次のオプションが必要になります。

CONFIG_EFI_VARS=m
Note: Arch の core/testing では、このオプションはモジュールとしてコンパイルされています。
Note: Linux が UEFI Runtime Service にアクセスするには、UEFI ファームウェアのプロセッサーアーキテクチャと Linux カーネルのプロセッサーアーキテクチャが一致している必要があります。これは使用するブートローダとは関係ありません。
Note: UEFI ファームウェアのアーキテクチャと Linux カーネルのアーキテクチャが異なっている場合、カーネルパニックを避けて起動するには "noefi" カーネルパラメータを使わなくてはなりません。"noefi" オプションはカーネルを UEFI ランタイムサービスにアクセスしないようにします。

GUID Partition Table GPT コンフィグオプション - UEFI サポートのために必須

CONFIG_EFI_PARTITION=y
Note: Linux を UEFI で起動するには上記のオプション全てが必要です。公式リポジトリの Archlinux カーネルでは有効になっています。

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD より。

UEFI 変数サポート

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

Note: The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.

UEFI ランタイムサービスへのアクセスは "efivars" カーネルモジュールによって提供されています。このモジュールは CONFIG_EFI_VAR=y カーネルコンフィグオプションで有効にします。モジュールがロードされると /sys/firmware/efi/vars 下 (カーネル3.8以降では /sys/firmware/efi/efivars) に変数が現れます。システムが UEFI ブートモードで起動したかどうか確認するひとつの方法は、"efivars" カーネルモジュールをロードして /sys/firmware/efi/vars (カーネル3.8以降では /sys/firmware/efi/efivars) ディレクトリが以下のような内容で存在しているか確認することです:

サンプル出力 (x86_64 カーネルの x86_64-UEFI 2.3.1):

# ls -1 /sys/firmware/efi/vars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootOrder-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/
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
MTC-eb704011-1402-11d3-8e77-00a0c969723b/
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/
del_var
new_var

ブートローダメニューであなたが "noefi" カーネルパラメータを使った場合は UEFI ランタイム変数は現れません。このカーネルパラメータは UEFI ランタイムサービスを完全に無視するようにカーネルに命じるからです。

ユーザースペースツール

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

  1. efibootmgr - UEFI ブートマネージャのブートエントリを作成・修正するのに使われます - efibootmgrefibootmgr-gitAUR
  2. uefivars - シンプルに変数を出力します - uefivars-gitAUR - efibootmgr ライブラリを使っています
  3. Ubuntu's Firmware Test Suite - fwts - fwts-gitAUR - uefidump コマンド - fwts uefidump

Mac 以外の UEFI システム

efibootmgr

Warning: Apple Mac で efibootmgr を使うとファームウェアが塞がれマザーボード ROM のリセットが必要になる可能性があります。これに関して Ubuntu/Launch バグトラッカーでバグの報告があります。Mac の場合は bless コマンドだけを使って下さい。Fedora による実験的な Linux 用 "bless" ユーティリティがあります - mactel-bootAUR
Note: efibootmgr コマンドはシステムを UEFI モードで起動した時だけ動作します。このコマンドを使うには UEFI ランタイム変数へのアクセスが必要で、もちろんそれは UEFI ブートモードでだけ使うことができるからです (そして "noefi" カーネルパラメータを使っていない状態)。さもなければ Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables メッセージが表示されます。
Note: efibootmgr を使えない場合、UEFI BIOS によっては BIOS から直接 uefi ブートオプションを管理できます。例えば、ASUS の BIOS には "Add New Boot Option" から EFI システムパーティションを選んで EFI の位置を入力できるものがあります (例: '\EFI\refind\refind_x64.efi')。

UEFI ブートローダがインストールされシステムが BIOS モードで起動した場合、最初にユーザーは手動でファームウェアからブートローダを起動する必要があります (UEFI シェルを使います)。それから efibootmgr を実行して UEFI ブートローダエントリを UEFI ブートマネージャのデフォルトエントリにする必要があります。

efibootmgr を使うには、(モジュールとしてコンパイルされている場合) まず 'efivars' カーネルモジュールをロードします:

# modprobe efivars

もしこのコマンドで no such device found エラーが表示されるなら、それはシステムが UEFI モードで起動してないか、なんらかの理由でカーネルが UEFI ランタイム変数にアクセスできないことを意味しています (noefi?)。

/sys/firmware/efi/vars/ (カーネル3.8以上では /sys/firmware/efi/efivars/) ディレクトリにファイルがあるかどうか確認してください。このディレクトリとその中身は "efivars" カーネルモジュールによって作成されます、そして UEFI モードで起動し、"noefi" カーネルパラメータが使われていないときだけ存在しているはずです。

/sys/firmware/efi/vars/ ディレクトリが空だったり存在しない場合、efibootmgr コマンドは動作しません。UEFI モードで ISO/CD/DVD/USB の起動ができない場合は #ISO から UEFI ブータブル USB を作成する を試して下さい。

Note: 以下のコマンドでは例として gummiboot ブートローダを使っています。

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: 現在 Gummiboot は自身のインストーラを持っています。よって以下の手順は gummiboot をインストールするのに使ってはいけません。例を変える必要があります。 (Discuss in Talk:Unified Extensible Firmware Interface (日本語)#)

起動するブートローダファイルが /boot/efi/EFI/gummiboot/gummibootx64.efi だと仮定します。/boot/efi/EFI/gummiboot/gummibootx64.efi/boot/efi/EFI/gummiboot/gummibootx64.efi とに分割できますが、/boot/efi は UEFI システムパーティションのマウントポイントで、ここでは /dev/sdXY と仮定します (この X と Y は本当の値の代替値です - 例:- /dev/sda1 , X=a Y=1)。

実際の UEFI システムパーティションの (/dev/sdXY という形式の) デバイスパスを調べるには、次を実行してください:

# findmnt /boot/efi
TARGET SOURCE  FSTYPE OPTIONS
/boot/efi  /dev/sdXY  vfat         rw,flush,tz=UTC

それから efibootmgr を使って以下のようにブートエントリを作成します:

# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'

In the above command /boot/efi/EFI/gummiboot/gummibootx64.efi translates to /boot/efi and /EFI/gummiboot/gummibootx64.efi which in turn translate to drive /dev/sdX -> partition Y -> file /EFI/gummiboot/gummibootx64.efi.

UEFI はパスの区切り記号としてバックスラッシュを使います (Windows のパスと似ています)。

'label' は UEFI ブートメニューで表示されるメニューエントリの名前です。この名前はユーザーが選ぶことができシステムのブートには影響がありません。詳しくは efibootmgr GIT README を見て下さい。

FAT32 ファイルシステムは UTF-8 エンコードを使わないのでデフォルトで大文字・小文字を区別しません。上の場合ではファームウェアは小文字の 'efi' の代わりに大文字の 'EFI' を使っていますが、\EFI\gummiboot\gummibootx64.efi\efi\gummiboot\gummibootx64.efi に違いはありません (ファイルシステムのエンコードが UTF-8 の場合は話が変わります)。

UEFI 用の Linux ブートローダ

UEFI Bootloaders を見て下さい。

Linux で UEFI システムパーティションを作る

Note: UEFI System Partition と EFI System Partition (ESP) は同じものです。
Note: UEFISYS パーティションのサイズは FAT32 ファイルシステムでサポートされている範囲で自由に決めることができます。Microsoft のドキュメントによれば、FAT32 の最小パーティション・ボリュームサイズは 512 MiB です。しかしながら多くの Linux ディストロや Microsoft Windows では FAT32 でフォーマットされた ESP は 100 MiB からサポートしているので、パーティションは小さくするほうが良いかもしれません。ただし互換性を保つには ESP は 512 MiB 以上の容量を取るのが推奨されます。ext2/3/4, reiserfs, NTFS, UDF などの FAT 以外のファイルシステムはサポートされていません。
Note: ESP は LVM などのソフトウェア RAID や RAID ライクなシステムの外に置く必要があります。ESP は UEFI ファームウェアによってアクセスされるので、LVM などのシステムを読み込むことができません。
Note: Linux EFISUTB ブートを使おうと思っているならば、まず UEFISYS パーティションにカーネルと Initramfs ファイルが入る十分な容量があるか確認してください。

GPT でパーティションされたディスク

選択肢がふたつあります:

  • GNU Parted/GParted を使う: FAT32 パーティションを作成して、そのパーティションに "boot" フラグを設定してください。
  • GPT fdisk (または gdisk) を使う: gdisk タイプコード "EF00" のパーティションを作成して、mkfs.vfat -F32 /dev/<THAT_PARTITION> を使ってパーティションを FAT32 でフォーマットしてください。
Note: MBR パーティションで "boot" フラグを立てることはそのパーティションが有効であることを示しますが、GPT パーティションでは同じ "boot" フラグが、そのパーティションが "UEFI System Partition" だということを示しています。
Warning: GPT ディスクのタイプコードを変更するのに util-linux の fdisk, cfdisk, sfdisk を使わないで下さい。同じく MBR ディスクで gptfdisk の gdisk, cgdisk, sgdisk を使わないで下さい、自動で GPT に変換されてしまいます (データ消失はありませんが、システムが起動に失敗するようになります)。

MBR でパーティションされたディスク

選択肢がふたつあります:

  • GNU Parted/GParted を使う: FAT32 パーティションを作成してください。それから fdisk, cfdisk, sfdisk を使ってパーティションのタイプコードを 0xEF に変更してください。
  • fdisk を使う: パーティションタイプ 0xEF でパーティションを作成し mkfs.vfat -F32 /dev/<THAT_PARTITION> を使ってパーティションを FAT32 としてフォーマットしてください。
Note: いくつかの UEFI ファームウェアは UEFI-MBR ブートができないので UEFI ブートにはいつも GPT を使うことが推奨されます。

UEFI シェル

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

UEFI シェルダウンロードリンク

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

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

UEFI シェルの起動

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

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

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

重要な 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) で詳しく説明されています。

Note: Users are recommended to try bcfg only if efibootmgr fails to create working boot entries in their system.
Note: UEFI Shell 1.0 は bcfg コマンドをサポートしていません。

現在のブートエントリのリストを出力するには -

Shell> bcfg boot dump -v

4番目の(番号は0から始まります)オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには:

Shell> bcfg boot add 3 fs0:\EFI\arch\refind\refindx64.efi "Arch Linux (rEFInd)"

fs0: は UEFI System Partition に、\EFI\arch\refind\refindx64.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 の改行コードを扱うことができます。

例として、UEFI システムパーティションの rEFInd の refind.conf を編集するには (fs0: ファームウェア内)

Shell> fs0:
FS0:\> cd \EFI\arch\refind
FS0:\EFI\arch\refind\> edit refind.conf

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

ハードウェアの互換性

Main page HCL/Firmwares/UEFI

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

Note: 以下の説明は Archiso と公式メディアに対応して書かれています; Archboot preparation is identical, with this refind.conf instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement.
Note: USB は MBR か GPT どちらかのパーティションテーブルを使うことができます (そのため、既にパーティションが作られた USB を使ってもかまいません)。ファイルシステムは FAT32 (推奨) か FAT16 でなくてはなりません。FAT12 はフロッピーディスク用に設計されているので USB ドライブでの使用はお勧めできません。

まず fdisk を使って USB にパーティションテーブルと1つのパーティションを作り Arch Linux download page から入手した ISO イメージをマウントしてください。

# mkdir -p /mnt/{usb,iso}
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso

そして (必要ならアンマウントしてから) USB パーティションをマウントし Archiso の設定で使われているラベルで FAT32 ファイルシステムを作成します。 ラベルは /mnt/iso/loader/entries/archiso-x86_64.conf から取得してください; これは initramfs の archiso フックでインストールメディアの udev パスを確認するために使われています。mkfs.vfatdosfstools パッケージに入っています。

# 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}

エラーの修復

次のエラーが出た場合: "No loader found. Configuration files in /loader/entries/*.conf are needed." 他の uefi ブートローダを使うとエラーが回避できるかもしれません。

refind-efi パッケージをインストールしてください。USB のファイルシステム中の、EFI/boot/bootx64.efi/usr/lib/refind/refind_x64.efi で上書きします。

それから以下のテキストを EFI/boot/refind.conf にコピーします。Arch menu セクションのラベル (ARCH_201302) をあなたの USB のラベルに書き換えてください。

refind.conf
timeout 5
textonly

showtools about,reboot,shutdown,exit
# scan_driver_dirs EFI/tools/drivers_x64
scanfor manual,internal,external,optical

scan_delay 1
dont_scan_dirs EFI/boot

max_tags 0
default_selection "Arch Linux Archiso x86_64 UEFI USB"

menuentry "Arch Linux Archiso x86_64 UEFI USB" {
  loader /arch/boot/x86_64/vmlinuz
  initrd /arch/boot/x86_64/archiso.img
  ostype Linux
  graphics off
  options "archisobasedir=arch archisolabel=ARCH_201301 add_efi_memmap"
}

menuentry "UEFI x86_64 Shell v2" {
  loader /EFI/shellx64_v2.efi
  graphics off
}

menuentry "UEFI x86_64 Shell v1" {
  loader /EFI/shellx64_v1.efi
  graphics off
}

これで起動ができるようになり、ロードしたい EFI を選ぶことができるはずです。

ISO から UEFI ブートサポートを削除する

Warning: In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section

Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.

Mount the official installation media and obtain the archisolabel as shown in the previous section.

Rebuild the ISO using xorriso from libisoburn:

$ 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/"

Burn ~/archiso.iso to optical media and proceed with installation normally.

参照