Difference between revisions of "Unified Extensible Firmware Interface (日本語)"
m (→Apple Mac) |
|||
Line 65: | Line 65: | ||
==== Apple Mac ==== | ==== Apple Mac ==== | ||
− | 2008年以前のほとんどの 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 の端末に次のコマンドを入力してください: | Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください: |
Revision as of 12:31, 23 February 2014
zh-CN:Unified Extensible Firmware Interface Template:Related articles start (日本語)
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 ブートローダの設定は説明しません。そのような情報は Boot Loaders (日本語) を見て下さい。
- EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。また、以下の手順は明白に書かれている部分を除き、一般的なものであり、場合によっては手順のいくつかは Mac では動かなかったり違っていたりする可能性があります。Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。
Contents
BIOS
BIOS (Basic Input-Output System) はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラム(ファームウェア)です。ほとんどの場合マザーボード上のフラッシュメモリに保存されており、システムのストレージとは独立しています。BIOS は BIOS のディスク順で一番最初のディスクから最初の 440 バイト (Master Boot Record) を起動します。440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、通常は GRUB, Syslinux, LILO などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。詳しくは Arch Boot Process (日本語) を参照してください。
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 などのブートローダの場合) を起動します
<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 だけです。詳しくは 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 の仕様に完全には準拠していないからです。
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 を起動することが可能になりました。Failed to Start loader... I will now execute HashTool
というメッセージが表示されます。HashTool を使って loader.efi と vmlinzu.efi のハッシュを登録するには、以下の手順に従って下さい。
OK
を選択してください- HashTool のメインメニューから
Enroll Hash
を選択し、\loader.efi
を選んでYes
で確定します。また、Enroll Hash
とarchiso
を選択して archiso のディレクトリに入り、vmlinuz-efi
を選んでYes
で確定してください。それからExit
を選択してブートデバイスの選択メニューに戻って下さい。 - ブートデバイスの選択メニューから
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 カーネル設定オプションは:
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 プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:
$ efivar -l
Linux カーネルでの UEFI 変数のサポート
Linux カーネルは2つのインターフェイスを使って EFI 変数のデータをユーザ空間に渡します:
- 新しい efivarfs インターフェイス (
efivarfs
カーネルモジュールによって/sys/firmware/efi/efivars
にマウントされます) は sysfs-efivars インターフェイスの限界を越えるために作られました。変数のサイズ制限を取り払って、UEFI Secure Boot 変数をサポートしておりカーネルの上流から使用を推奨されています。カーネル 3.8 から導入され、カーネル 3.10 ではefivars
カーネルモジュールからefivarfs
モジュールは分割されています。 - 古い 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日現在)。
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 変数のサポートを正しく動作させるための必要条件
- EFI Runtime Services サポートがカーネルに存在する必要があります (
CONFIG_EFI=y
)。zgrep CONFIG_EFI /proc/config.gz
で確認できます。 - カーネルのプロセッサのビット数・アーキテクチャが 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
にマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さいefivar
はエラーを出さずに EFI 変数をリストアップ (-l
オプション) するはずです。出力の例は #UEFI 変数のサンプルリスト を見て下さい
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
- ユーザスペースのツールが efi 変数のデータを修正できない場合、
/sys/firmware/efi/efivars/dump-*
ファイルが存在しているかチェックしてください。存在しているときは、ファイルを削除してから再起動してもう一度試して下さい。 - 上の手順で問題が修正されない場合、
efi_no_storage_paranoia
カーネルパラメータを使って起動してカーネルの efi 変数ストレージ領域チェックを無効にしてください。これによって efi 変数の書き込み・修正が止められている可能性があります。
efi_no_storage_paranoia
は必要な時だけに使い、通常のブートオプションに使用してはいけません。このカーネルコマンドライン・パラメータは NVRAM を満杯にしてマシンを文鎮化するようなことを避ける安全装置を外してしまいます。efivarfs のマウント
起動時に systemd によって自動で efivarfs
がマウントされなかった時は、手動で efivarfs をマウントして efibootmgr
などのユーザースペースツールを使うために UEFI Variable サポートを有効にする必要があります:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
下のように /etc/fstab
で起動時 efivarfs
を自動でマウントするように記述すると良いかもしれません:
/etc/fstab
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0
ユーザースペースツール
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-gitAUR
- Ubuntu's Firmware Test Suite — Ubuntu のファームウェアテストスイート。
- https://wiki.ubuntu.com/FirmwareTestSuite/ || fwtsAUR (と fwts-efi-runtime-dkmsAUR) もしくは fwts-gitAUR
efibootmgr
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
と仮定します (この 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"
\
を使います (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 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 パーティション容量の制限よりは多くなります)。詳しくはここを見て下さい。
- UEFI ファームウェアによっては UEFI-MBR ブートができないため UEFI ブートでは出来るだけ GPT を使うことが推奨されます。
- GNU Parted では、
boot
フラグ (legacy_boot
フラグとは区別されます) は MBR と GPT のディスクで異なる効果があります。MBR ディスクでは、パーティションが有効であるとマークされます。GPT ディスクでは、パーティションのタイプコードをEFI System Partition
のタイプに変更します。Parted には MBR ディスクでパーティションを ESP とするフラグがありません (fdisk を使えば可能です)。 - Microsoft のドキュメントには ESP の容量について説明があります: Advanced Format 4K Native (4-KB-per-sector) のドライブでは、FAT32 ファイルフォーマットの制限によって、最小容量は 260 MB となります。FAT32 のドライブの最小パーティションサイズはセクターサイズ (4KB) x 65527 = 256 MB と計算されます。Advanced Format 512e ドライブはセクターサイズが 512 バイトだとエミュレートされているのでこの制限を受けません。512 バイト x 65527 = 32 MB、これはパーティションの最小容量 100 MB よりも少ない値です。参照: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules
- EFISTUB の場合、カーネルと initramfs のファイルは EFI System Partition に保存する必要があります。また、EFISTUB ブートでは
/boot
パーティションを別に作らないで ESP を/boot
パーティションとして使うことでシンプルにすることも可能です。
GPT でパーティションされたディスク
- gdisk (gptfdisk パッケージにあります) を使ってパーティションタイプ
ef00
かEF00
のパーティションを作成してください。そしてmkfs.vfat -F32 /dev/<THAT_PARTITION>
を実行して FAT32 でパーティションをフォーマットしてください
もしくは
- GNU Parted で FAT32 パーティションを作成し、パーティションに
boot
フラグ (legacy_boot
フラグではありません) を設定してください
WARNING: Not enough clusters for a 32 bit FAT!
クラスタ容量を mkfs.fat -s2 -F32 ...
か -s1
で減らしてください。そうしないとパーティションが UEFI によって読み込めなくなってしまいます。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-svnAUR パッケージ (推奨) - 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
キーのどれかで起動できます。
(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) で詳しく説明されています。
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
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 を作成する
USB Installation Media (日本語)#BIOS・UEFI ブータブル USB を参照してください。
オプティカルメディアから UEFI ブートサポートを削除する
ほとんどの32ビット EFI Mac といくつかの64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。オプティカルメディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があります。
- 公式インストールメディアをマウントして前のセクションで示されているように
archisolabel
を取得してください。
# mount -o loop input.iso /mnt/iso
- libisoburn に含まれている
xorriso
を使って UEFI Optical Media ブートサポートを除いた ISO を再生成してください。
$ 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 [1] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
AUR ovmf-svnAUR から 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 が起動しない
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 の起動を阻止できません
USB メディアが黒画面で固まる
- 問題が KMS によるものではない場合、おそらく EFISTUB ブートのバグによる問題です (詳しくは [2] や [3] を見て下さい)。公式 ISO (Archiso) と Archboot iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは Gummiboot ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして GRUB を使って下さい。
GRUB の使用
- USB Installation Media (日本語)#BIOS・UEFI ブータブル USB に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。
<USB>/EFI/boot/loader.efi
を<USB>/EFI/boot/gummiboot.efi
にバックアップしてください。
- GRUB スタンドアロンイメージを作成して
<USB>/EFI/boot/loader.efi
にコピーしてください。
- 以下の内容で
<USB>/EFI/boot/grub.cfg
を作成してください:
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 ARCHISO_XXXXXX linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX add_efi_memmap initrd /arch/boot/x86_64/archiso.img } menuentry "UEFI Shell x86_64 v2" { search --no-floppy --set=root --label ARCHISO_XXXXXX chainloader /EFI/shellx64_v2.efi } menuentry "UEFI Shell x86_64 v1" { search --no-floppy --set=root --label ARCHISO_XXXXXX 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 }
参照
- Wikipedia:ja:UEFI
- Wikipedia:EFI System partition
- UEFI boot: how does that actually work, then? - A blog post by AdamW
- Linux カーネル x86_64 UEFI ドキュメント
- 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 UEFI Community Resource Center
- Intel の 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 コマンドの情報
- 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 チュートリアル : part 1
- LPC 2012 UEFI チュートリアル : part 2