「Unified Extensible Firmware Interface」の版間の差分
(同期) |
細 (→UEFI ドライバ: typo) |
||
| 296行目: | 296行目: | ||
{{Tip| |
{{Tip| |
||
* [[systemd-boot]] は {{ic|''esp''/EFI/systemd/drivers/}} から UEFI ドライバを自動的に読み込みます。 |
* [[systemd-boot]] は {{ic|''esp''/EFI/systemd/drivers/}} から UEFI ドライバを自動的に読み込みます。 |
||
| − | * [[rEFInd]] は、ESP 上の rEFInd インストール先ディレクトリのサブディレクトリ {{ic|drivers}} と {{ic|drivers_x64}} (例: {{ic|''esp''/EFI/refind/drivers_x64/}}) から UEFI ドライ |
+ | * [[rEFInd]] は、ESP 上の rEFInd インストール先ディレクトリのサブディレクトリ {{ic|drivers}} と {{ic|drivers_x64}} (例: {{ic|''esp''/EFI/refind/drivers_x64/}}) から UEFI ドライブを自動的に読み込みます。他のディレクトリをスキャンするように設定することも可能です。 |
}} |
}} |
||
2024年3月31日 (日) 11:39時点における版
Unified Extensible Firmware Interface (UEFI、EFI の後継) はオペレーティングシステムとファームウェア間のインターフェイスです。オペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。
UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては Arch ブートプロセス を見てください。UEFI ブートローダをセットアップするには ブートローダー を見てください。
目次
- 1 UEFI のバージョン
- 2 UEFI ファームウェアのビット数
- 3 UEFI の Linux カーネル設定オプション
- 4 UEFI 変数
- 5 UEFI シェル
- 6 UEFI ドライバ
- 7 UEFI ブータブルメディア
- 8 ネイティブサポートのない環境で UEFI をテストする
- 9 トラブルシューティング
- 9.1 Windows で固まった際に Arch Linux に戻る
- 9.2 ファンクションキー無しでファームウェアセットアップに入る
- 9.3 ユーザスペースのツールが UEFI 変数のデータを変更できない
- 9.4 efibootmgr でブートエントリを新規作成できない
- 9.5 Windows によってブート順序が変わってしまう
- 9.6 USB メディアが黒画面で固まる
- 9.7 ファームウェアのメニューに UEFI ブートローダーが表示されない
- 9.8 efibootmgr で作成したブートエントリが UEFI に表示されない
- 9.9 UEFI ブートエントリが、参照するドライブを取り外すと消える
- 9.10 ブートエントリがランダムに削除される
- 10 参照
UEFI のバージョン
- UEFI は Intel の EFI としてバージョン 1.x で始まりました。
- その後、the UEFI Forum とよばれる企業のグループが開発を引き継ぎ、EFI は Unified EFI へと名前を変え、バージョン 2.0 になりました。
- EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。
- Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは (U)EFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。また、以下の手順は明白に書かれている部分を除き、一般的な UEFI を対象としており、場合によっては手順のいくつかは Apple Mac では動かなかったり違っていたりする可能性があります。
最新の UEFI 仕様は https://uefi.org/specifications にて確認できます。
UEFI ファームウェアのビット数
UEFI においては、すべてのプログラムは OS ローダーであろうとユーティリティ(メモリテストやリカバリツール)であろうと、UEFI ファームウェアのビット数/アーキテクチャに対応する EFI アプリケーションである必要があります。
最近の Apple Mac を含む x86_64 システムの大部分は x64 (64 ビット) UEFI ファームウェアを使用します。IA32 (32ビット) の UEFI を使うことが知られているデバイスは古い(2008年以前) Apple Mac や Intel Atom System-on-Chip システム(2013年11月2日現在)[1]、そして Intel EFI 1.10 ファームウェア上で動作することが知られている一部の古い Intel のサーバーボードだけです。
x64 UEFI ファームウェアは 32ビットの EFI アプリケーションの起動をサポートしません(x86_64 Linux とそのようなサポートを含む Windows のバージョン とは違って)。それゆえ、EFI アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。
UEFI ファームウェアのビット数を調べる
ファームウェアのビット数は起動されたオペレーティングシステムから確認できます。
Linux で
Linux カーネル 4.0 以上が走るディストリビューションでは、UEFI ファームウェアのビット数は sysfs インターフェイスを通して確認できます。以下を実行してください:
$ cat /sys/firmware/efi/fw_platform_size
このコマンドは、64ビット (x64) UEFI の場合は 64、32ビット(IA32) UEFI の場合は 32 を返します。このファイルが存在しない場合は UEFI モードで起動していないということです。
macOS で
2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年以降の Mac のファームウェアはほとんど x64 EFI です。Mac OS X Snow Leopard を動かすことのできる全ての Mac は x64 EFI 1.x ファームウェアを使っています。
Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X の端末に次のコマンドを入力してください:
$ ioreg -l -p IODeviceTree | grep firmware-abi
コマンドの返事が EFI32 なら、IA32 (32ビット) EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x64 EFI ファームウェアです。ほとんどの Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI 2.x の仕様に完全には準拠していないからです。
Microsoft Windows で
64ビット Windows は 32ビット UEFI からの起動をサポートしていません。なので、UEFI モードで 32ビット Windows を起動している場合は 32ビット UEFI を使用しているということになります。
ビット数を調べるには msinfo32.exe を実行してください。システムの要約を開き、"システムの種類"と"BIOS モード"の値を見てください。
64ビット UEFI 上で動作している 64ビット Windows では システムの種類: x64-ベース PC、BIOS モード: UEFI となります。32ビット UEFI 上で動作する 32ビット Windows では システムの種類: x86-ベース PC、BIOS モード: UEFI となります。もし、"BIOS モード" が UEFI でない場合、Windows は UEFI モードで起動していないということです。
UEFI の Linux カーネル設定オプション
UEFI システムのために必要な Linux カーネル設定オプション[2]は:
CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_X86_SYSFB=y CONFIG_FB_SIMPLE=y CONFIG_FRAMEBUFFER_CONSOLE=y
UEFI Runtime Variables Support (古い efivars sysfs インターフェイス - /sys/firmware/efi/vars)。このオプションは efivars と sysfs-efivars がともに有効な場合の潜在的な問題を回避するため無効にしてください。
CONFIG_EFI_VARS=n
GUID Partition Table (GPT) 設定オプション - UEFI サポートのために必須
CONFIG_EFI_PARTITION=y
EFI mixed-mode サポート - IA32 UEFI で x86_64 カーネルを起動するのに必要:
CONFIG_EFI_MIXED=y
UEFI 変数
UEFI はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。次を実行することでリストを取得できます:
$ efivar --list
Linux カーネルでの UEFI 変数のサポート
Linux カーネルは efivarfs (EFI VARiable FileSystem) インターフェイスを通して UEFI 変数のデータをユーザスペースに公開します(CONFIG_EFIVAR_FS)。このインターフェイスは efivarfs カーネルモジュールを使って /sys/firmware/efi/efivars にマウントされます。変数ごとの最大サイズ制限は無く、UEFI Secure Boot 変数をサポートします。これはカーネル 3.8 で導入されました。
UEFI 変数のサポートを正しく動作させるための必要条件
- カーネルが EFISTUB(任意で ブートマネージャー)を通して、またはブートローダーによって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
- EFI Runtime Services サポートがカーネルに存在する必要があります (
CONFIG_EFI=y)。zgrep CONFIG_EFI /proc/config.gzで確認できます。 - カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり
noefiカーネルコマンドラインは使わないで下さい。 efivarfsファイルシステムが/sys/firmware/efi/efivarsにマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい。efivarはエラーを出さずに EFI 変数をリストアップ (-l/--listオプション) するはずです。
上記の条件が満たされても EFI 変数のサポートが動かないときは、以下の回避策を試して下さい:
- UEFI 変数のリストアップ(
efivar -l)の際にefivar: error listing variables: Function not implementedと言うメッセージが出て、かつ、システムがリアルタイムカーネルで起動する場合、カーネルパラメータにefi=runtimeを追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。 - さらなるドラブルシューティング手順は #ユーザスペースのツールが UEFI 変数のデータを変更できない を見てください。
efivarfs のマウント
efivarfs が起動中にsystemd によって自動的に /sys/firmware/efi/efivars にマウントされない場合、UEFI 変数を efibootmgr のようなユーザースペースツールに公開するために efivarfs を手動でマウントする必要があります:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
カーネルドキュメントの efivarfs.html を参照してください。
ユーザースペースツール
UEFI 変数を表示・変更することができるツールがいくつかあります、即ち
- efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
- efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール
- uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。
- efitools — UEFI セキュアブートプラットフォームを操作するための UEFI ツール
- Ubuntu's Firmware Test Suite — Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート
efibootmgr
efibootmgr パッケージをインストールする必要があります。
efibootmgr を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:
- EFI システムパーティション (ESP) を含むディスク (例:
/dev/sda/dev/nvme0n1)。 - そのディスク上にある ESP のパーティション番号。
/dev/sdaYや/dev/nvme0n1pYのYの部分のことです。 - EFI アプリケーションへのパス (ESP のルートからの相対パス)
例えば、/efi が ESP のマウントポイントである場合に /efi/EFI/refind/refind_x64.efi 用のブートオプションを追加したい場合、以下を実行してください:
$ findmnt /efi
TARGET SOURCE FSTYPE OPTIONS /efi /dev/sda1 vfat rw,flush,tz=UTC
この例では、findmnt(8) コマンドは、ESP がディスク /dev/sda 上にあり、そのパーティション番号が 1 であることを示しています。EFI アプリケーションへの、ESP をルートとした相対パスは /EFI/refind/refind_x64.efi となっています。故に、ブートエントリを以下のように作成することになります:
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode
さらなる情報は efibootmgr(8) または efibootmgr README を見てください。
UEFI 変数へのアクセスを無効化
UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。実際、悪意のあるアクターがマシンの完全な制御を奪うことのできる LogoFAIL という危険な UEFI エクスプロイトが存在します。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[3]
ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。
可能な方法は:
efivarsを fstab を用いて読み取り専用モードでマウントする。例えば:efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
noefiカーネルパラメータを使用して、OS から UEFI へのアクセスを完全に無効化する。
UEFI シェル
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。
UEFI シェルを入手する
Tianocore EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます:
- Shell v2:
- Arch インストールメディアの
/shellx64.efi。ISO がビルドされたときの/usr/share/edk2-shell/x64/Shell_Full.efiのコピーです。 - edk2-shell パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
- uefi-shell-gitAUR パッケージ - x64 (64ビット) UEFI 環境用の x64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル
- Arch インストールメディアの
- Shell v1:
- TianoCore 由来の プリコンパイル済み UEFI Shell v1 バイナリ (2014/1/10 から上流は一度もアップデートされていません)。
- 派生版:
- プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg[リンク切れ 2023-07-30] - Clover EFI ブートローダ由来。
- 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ - OpenCore ブートローダ由来。リリースアーカイブでは:
EFI/OC/Tools/OpenShell.efi。
Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkg や Inclusion of UEFI shell in Linux distro iso を見て下さい。
UEFI シェルの起動
数少ない Asus や他の AMI Aptio x64 UEFI ファームウェアベースのマザーボード (Sandy Bridge 以降) では、Launch EFI Shell from filesystem device と呼ばれるオプションが提供されています。これらのマザーボードでは、x64 UEFI Shell を EFI システムパーティション のルートに shellx64.efi という名前で コピーしてください。
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており F6, F11, F12 キーのどれかで起動できます。
重要な UEFI シェルコマンド
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。利用できるコマンドを表示するには help -b を実行してください。
詳しい情報は Intel Scripting Guide 2008[リンク切れ 2023-07-30] と Intel "Course" 2011[リンク切れ 2023-07-30] を見てください。
bcfg
bcfg コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては UEFI Shell Specification 2.2 ドキュメントの 96 ページ (Section 5.3) で詳しく説明されています。
現在のブートエントリのリストを出力するには:
Shell> bcfg boot dump -v
4番目の（番号は0から始まります）オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには:
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
FS0: は EFI System Partition に、FS0:\EFI\refind\refind_x64.efi は起動するファイルにそれぞれ適切にマッピングしてください。
ブートローダ無しでシステムを直接ブートするエントリを追加するには、カーネルを EFISTUB として使用してブートオプションを設定してください:
Shell> bcfg boot add N fsV:\vmlinuz-linux "Arch Linux" Shell> bcfg boot -opt N "root=/dev/sdX# initrd=\initramfs-linux.img"
N は優先度、V は EFI システムパーティションのボリューム番号、/dev/sdX# はルートパーティションです。
4番目のブートオプションを削除するには:
Shell> bcfg boot rm 3
ブートオプション #3 を #0 (つまり UEFI ブートメニューの最初のエントリ) に移動するには:
Shell> bcfg boot mv 3 0
bcfg のヘルプを見るには
Shell> help bcfg -v -b
もしくは
Shell> bcfg -? -v -b
map
map はデバイスマッピング (つまり、利用可能なファイルシステム (FS0) とストレージデバイス (blk0) の名前) の一覧を表示します。
cd や ls などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります:
Shell> fs0: fs0:\> cd EFI/
edit
edit コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。
例として、システムパーティションの rEFInd の refind.conf を編集するには (ファームウェア内の FS0:)
Shell> edit FS0:\EFI\refind\refind.conf
ヘルプを出すには Ctrl+e を押して下さい。
UEFI ドライバ
UEFI ドライバとは、なんらかの機能をサポートするためのソフトウェアのことです。例えば、NTFS でフォーマットされたパーティションは通常 UEFI シェルからアクセスできません。efifs パッケージには、EFI シェル内から多くのファイルシステムを読み込めるようにするドライバが含まれています。使用例を挙げましょう。そのようなドライバを UEFI シェルからアクセス可能なパーティションにコピーして、UEFI シェルから以下のようなコマンドを実行します:
Shell> load ntfs_x64.efi Shell> map -r
map コマンドを実行したあと、ユーザは NTFS でフォーマットされたパーティションに UEFI シェル内からアクセスできるようになっているはずです。
UEFI ブータブルメディア
ISO から UEFI ブータブル USB を作成する
USB インストールメディア#ISO をそのまま使う (BIOS と UEFI) を参照してください。
光学メディアから UEFI ブートサポートを削除する
ほとんどの32ビット EFI Mac と一部の64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。光学メディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があるかもしれません。
UEFI 特有のディレクトリを除いて ISO を展開してください:
$ mkdir extracted_iso $ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-version-x86_64.iso -C extracted_iso
そして、libisoburn の xorriso(1) を使って ISO を再ビルドしてください。この時、UEFI 光学メディアのブートサポートを除いてください。正しいボリュームラベルを設定してください(例えば ARCH_202103)。ボリュームラベルは、オリジナルの ISO に対して file(1) を使うことで得られます。
$ xorriso -as mkisofs \
-iso-level 3 \
-full-iso9660-filenames \
-joliet \
-joliet-long \
-rational-rock \
-volid "ARCH_YYYYMM" \
-appid "Arch Linux Live/Rescue CD" \
-publisher "Arch Linux <https://archlinux.org>" \
-preparer "prepared by $USER" \
-eltorito-boot syslinux/isolinux.bin \
-eltorito-catalog syslinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \
-output archlinux-version-x86_64-noUEFI.iso extracted_iso/
archlinux-version-x86_64-noUEFI.iso を光学メディアに焼いて、通常のインストールを続けてください。
ネイティブサポートのない環境で UEFI をテストする
仮想マシン用の OVMF
OVMF は仮想マシンで UEFI サポートを有効にする TianoCore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。
edk2-ovmf をインストールできます。
仮想マシンの非揮発性変数のローカルコピーを作成することが推奨されています:
$ cp /usr/share/edk2/x64/OVMF_VARS.4m.fd my_OVMF_VARS.4m.fd
OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください:
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd \ -drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd
例えば:
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd -drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd …
BIOS システム専用の DUET
DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする TianoCore プロジェクトです。この方法については広く議論されています。ビルド済み DUET イメージは、いくつかのリポジトリ[リンク切れ 2023-04-07]のどれかからダウンロードできます。DUET をセットアップする特定の方法については、特定の指示[リンク切れ 2023-04-07]を読んでください。しかし、2018年11月に DUET のコードが TianoCore git リポジトリから削除されました。
また、修正 DUET イメージを提供する Clover を試すことも可能です。特定環境の修正が含まれており gitlab リポジトリと比べて頻繁に更新されています。
トラブルシューティング
Windows で固まった際に Arch Linux に戻る
Windows で固まった際に Arch Linux に戻るには、Windows PowerShell コマンド shutdown /r /o、または Settings > Update & Security > Recovery > Advanced startup の Restart now を選んで Windows の Advanced startup に進んでください。Advanced startup メニューに行き着いた際に、Use a device を選んでください。これには実際の UEFI ブートオプションが含まれています(USB や CD に限らず、ハードドライブ内の OS も起動できます)。そして、"Arch Linux" を選んでください。
ファンクションキー無しでファームウェアセットアップに入る
en:Lenovo XiaoXin 15are 2020 のような一部のノート PC では、F2 や F12 のようなキーを使用しても何も起こりません。OEM にノート PC を返却しメインボード情報の修復を行えばおそらく修正可能ですが、時々これが不可能である、または望ましくない場合があります。しかし、ファームウェアセットアップに入る他の方法が存在します:
- systemctl を使用:
$ systemctl reboot --firmware-setup
これによりコンピュータが再起動され、ファームウェアセットアップに入ります。 - GRUB を使用: コマンドラインに入るために
cを押し、GRUB コマンドラインでfwsetupを使用してファームウェアセットアップに入る。 - Windows で: Advanced Startup に入る。#Windows で固まった際に Arch Linux に戻る を見てください。
ユーザスペースのツールが UEFI 変数のデータを変更できない
如何なるユーザスペースツールを持ってしても UEFI 変数のデータを変更できない場合、/sys/firmware/efi/efivars/dump-* ファイルが存在するかどうかを確認してください。存在する場合、それらを削除し、再起動して再び試してみてください。
この手順でもこの問題を解決できない場合、efi_no_storage_paranoia カーネルパラメータを使用して起動してみてください(このカーネルパラメータは、UEFI 変数の書き込み/変更を妨げてしまうカーネル UEFI 変数ストレージスペースチェックを無効化します)。
efibootmgr でブートエントリを新規作成できない
カーネルと efibootmgr のバージョンの組み合わせによっては、ブートエントリの新規作成ができなるなるかもしれません。これは NVRAM の空き領域の不足によるものであることがあります。#ユーザスペースのツールが UEFI 変数のデータを変更できない の解決策を試すことができます。
また、efibootmgr をバージョン 0.11.0 までダウングレードしてみることもできます。このバージョンは Linux バージョン 4.0.6 で機能します。詳細はバグのディスカッション FS#34641、特に closing comment を見てください。
Windows によってブート順序が変わってしまう
Windows と Arch のデュアルブートをしていて、マザーボードがあなたの選んだ EFI アプリケーションではなく Windows を即座に起動する場合、いくつかのあり得る原因と回避策があります。
- 高速スタートアップが Windows の電源オプションで無効化されていることを確認してください。
- セキュアブートがファームウェアで無効化されていることを確認してください(署名済みのブートローダを使用していない場合)。
- UEFI のブート順序で Windows Boot Manager が1番めに設定されていないことを確認してください(例: efibootmgr を使用)。一部のマザーボードは、Windows によって efibootmgr を使って設定したものを検出するとデフォルトで上書きします。これは Packard Bell ノート PC で確認されています。
- マザーボードがデフォルトブートパス (
\EFI\BOOT\BOOTx64.EFI) を起動する場合、このファイルは Windows ブートローダで上書きされる場合があります。efibootmgr などを使用して、正しい
ブートパスを設定してみてください。
- 前の手順でうまく行かなかった場合、Windows ブートローダに異なる EFI アプリケーションを実行するように指示することができます。Windows 管理者コマンドプロンプトから
bcdedit /set "{bootmgr}" path "\EFI\path\to\app.efi"。 - または、
efibootmgr -A -b bootnumberを root として実行することで Windows Boot Manager を無効化する。bootnumberの部分は実際の Windows Boot Manager のブート番号に置き換えてください。efibootmgrをオプション足で実行することでブート番号を確認できます。 - または、Windows を起動するたびにブート順序が正しく設定されているかを確認するスタートアップスクリプトを Windows で設定することができます。
- 管理者権限でコマンドプロンプトを開き、
bcdedit /enum firmwareを実行して、お望みのブートエントリを見つけてください。 - カッコも含めて識別子をコピーしてください。例:
{31d0d5f4-22ad-11e5-b30b-806e6f6e6963} - 次のコマンドを含むバッチファイルを作成してください:
bcdedit /set "{fwbootmgr}" DEFAULT "{コピーしたブート識別子}" - gpedit.msc を開き、Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) にある Startup をクリックしてください。
- Scripts タブに行き、Add ボタンをクリックし、そのバッチファイルを選択してください。
- 管理者権限でコマンドプロンプトを開き、
- または、Windows でスタートアップするクリプトを実行するためにタスクスケジューラを使用することができます:
- 上記の1から3の手順に従って、バッチファイルを作成してください。
- taskschd.msc を実行し、Action メニュから Create Task... を選んでください。
- General タブで:
- 適当な任意の Name と Description を入力してください。
- 選択したユーザアカウントが "Administrator" (管理者)であることを確認してください。"Standard User" であってはなりません。
- "Run whether user is logged in or not" を選択してください。
- "Run with highest privileges" を選択してください。
- Triggers タブで、メニューから "At startup" を選択して、その後 OK を押してください。
- Actions タブで、New... をクリックし、Browse... をクリックし、手順1 で作成したバッチファイルを選択してください。
- Conditions tab タブで、Power オプションのチェックを解除してください。そうすれば、バッテリ駆動時にスクリプトが実行されます(ラップトップの場合)。
- OK をクリックして、パスワードのプロンプトが表示された場合は手順4で選択したユーザアカウントのパスワードを入力してください。
USB メディアが黒画面で固まる
この問題は KMS の問題によって起こることがあります。USB を起動するときは KMS を無効化してみて下さい。
ファームウェアのメニューに UEFI ブートローダーが表示されない
一部のファームウェアはカスタムのブートエントリをサポートしていません。そのようなファームウェアはハードコードされたブートエントリからしか起動しません。
典型的な回避策は、NVRAM のブートエントリに頼るのではなく、EFI システムパーティション内の共通フォールバックパスの一つにブートローダーをインストールすることです。
以下のセクションではそのフォールバックパスについて説明しています。
リムーバブルドライブのデフォルトブートパス
UEFI 仕様では、リムーバブルメディアから起動するための EFI バイナリのデフォルトファイルパスが定義されています。関連するものとしては:
esp/EFI/BOOT/BOOTx64.EFI- x64 UEFI 用esp/EFI/BOOT/BOOTIA32.EFI- IA32 UEFI 用
仕様では、これらはリムーバブルドライブのみ用であると定義されている一方、ほとんどのファームウェアはこれらの起動をすべてのドライブでサポートしています。
ブートローダーをデフォルト/フォールバックブートパスにインストール/統合する方法については適切なブートローダーの記事を見てください。
Microsoft Windows ブートローダの場所
Itenl Z77 チップセット搭載の一部のボードのような特定の UEFI マザーボードでは、UEFI シェルから efibootmgr/bcfg を使用してエントリを追加することができません。NVRAM に追加したあとにエントリがブートメニューに表示されないためです。
この問題はマザーボードが Microsoft Windows しか読み込めないため発生します。これを解決するには、Windows が使用する場所に .efi ファイルを配置する必要があります。
Arch Linux インストールメディア(FSO:) からハードドライブ(FS1:)上の ESP パーティション内の Microsoft ディレクトリへ BOOTx64.EFI ファイルをコピーしてください。EFI シェルを起動し、以下を実行してください:
Shell> mkdir FS1:\EFI\Microsoft Shell> mkdir FS1:\EFI\Microsoft\Boot Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi
再起動後、NVRAM に追加したエントリがブートメニュに表示されるはずです。
efibootmgr で作成したブートエントリが UEFI に表示されない
efibootmgr は EDD 3.0 の検出に失敗する可能性があり、その結果、NVRAM に利用不可能なブートエントリを作成してしまいます。詳細は efibootmgr issue 86 を見てください。
これを回避するには、ブートエントリを手動で作成する際に、-e 3 オプションを efibootmgr コマンドに追加してください。例:
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode -e 3
grub-install や refind-install のようなブートローダインストーラを修復するには、/usr/local/bin/efibootmgr ラッパースクリプトを作成し、それを実行可能にしてください:
/usr/local/bin/efibootmgr
#!/bin/sh exec /usr/bin/efibootmgr -e 3 "$@"
UEFI ブートエントリが、参照するドライブを取り外すと消える
一部のファームウェアは、参照されているドライブが起動中に存在しない場合、そのブートエントリを削除します。これは、ドライブを頻繁に取り付け/取り外ししたり、リムーバブルドライブから起動する際に問題となりえます。
解決策は、ブートローダーをデフォルト/フォールバックブートパスにインストールすることです。
ブートエントリがランダムに削除される
一部のマザーボードは、NVRAM の空き領域が足りない場合、ブートエントリの作成時にエラーを表示せずに、ブートエントリを削除してしまうことがあります。これを防ぐには、エントリの作成プロセスを最小限にして、追加されるブートエントリの数を減らし、さらに、UEFI 設定から Compatibility Support Module (CSM) を無効化して、自動ドライブブートエントリの数も減らしてください。BBS#1608838 を参照してください。
ブートエントリが削除されてしまう他の原因として、UEFI 仕様では「NVRAM メンテナンス」をブート中に実行することが OEM に許可されていることも挙げられます。そのようなメーカーのデバイスは、事前定義されハードコードされているデバイス上のパスで EFI アプリケーションを探索するだけです。何も見つけられなかった場合、デバイス上には OS が存在しないと結論づけ、NVRAM 上に破損しているまたは古いデータが存在すると推測し、そのデバイスと関連する NVRAM からすべてのブートエントリを消してしまいます。Windows をインストールする予定がなく、ファームウェアから Linux カーネルを直接ロードしたい場合、解決策として空のファイル esp/EFI/BOOT/BOOTx64.EFI を作成するというものがあります:
# mkdir -p esp/EFI/BOOT # touch esp/EFI/BOOT/BOOTx64.EFI
そして、削除されたブートエントリを作り直してください。これで、再起動すれば、マザーボードは「偽のOS」を検出し、NVRAM から他のブートエントリを削除しなくなるはずです。この偽の OS ローダは実際の EFI アプリケーションに自由に変更することもできます。もちろん、標準のフォールバック名を使い続ける限りです。
参照
- Wikipedia:ja:UEFI
- UEFI Forum - 公式の UEFI の仕様書 - GUID Partition Table は UEFI の仕様に含まれています
- UEFI boot: how does that actually work, then? - AdamW によるブログ記事
- Linux カーネルの x86_64 プラットフォーム向け UEFI ドキュメント
- Intel の EFI に関するページ
- Intel Architecture Firmware Resource Center[リンク切れ 2023-07-30]
- Matt Fleming - The Linux EFI Boot Stub
- Matt Fleming - Accessing UEFI Variables from Linux
- Rod Smith - Linux on UEFI: クイックインストールガイド
- 一部の新しいマシンでの UEFI ブート問題 (LKML)
- LPC 2012 Plumbing UEFI into Linux
- LPC 2012 UEFI チュートリアル : part 1
- LPC 2012 UEFI チュートリアル : part 2
- Intel の Tianocore プロジェクト 直接 BIOS で起動するための DuetPkg や QEMU や Oracle VirtualBox で使用される OvmfPkg が含まれているオープンソースの UEFI ファームウェア
- FGA: The EFI boot process
- Microsoft の Windows と GPT の FAQ
- 再インストールせずに Windows x64 を BIOS-MBR モードから UEFI-GPT モードに移行
- Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成
- Rod Smith - A BIOS to UEFI Transformation
- - Intel ドキュメント
- UEFI Shell - Intel ドキュメント
- UEFI Shell - bcfg コマンドの情報
- The bootstrap process on EFI systems