「Unified Extensible Firmware Interface」の版間の差分
細 (→Microsoft Windows で: typo) |
(TranslationStatus) |
||
(同じ利用者による、間の22版が非表示) | |||
13行目: | 13行目: | ||
{{Related articles end}} |
{{Related articles end}} |
||
− | [https://www.uefi.org/ Unified Extensible Firmware Interface] (もしくは省略して UEFI や EFI)はオペレーティングシステムとファームウェア間のインターフェイスのモデルですオペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。 |
+ | [https://www.uefi.org/ Unified Extensible Firmware Interface] (もしくは省略して UEFI や EFI)はオペレーティングシステムとファームウェア間のインターフェイスのモデルです。オペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。 |
UEFI は [[Wikipedia:ja:BIOS|BIOS]] システムで一般的に使われている "[[Master Boot Record|MBR]] ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては [[Arch ブートプロセス]] を見てください。UEFI ブートローダをセットアップするには [[ブートローダー]] を見てください。 |
UEFI は [[Wikipedia:ja:BIOS|BIOS]] システムで一般的に使われている "[[Master Boot Record|MBR]] ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては [[Arch ブートプロセス]] を見てください。UEFI ブートローダをセットアップするには [[ブートローダー]] を見てください。 |
||
70行目: | 70行目: | ||
== UEFI の Linux カーネル設定オプション == |
== UEFI の Linux カーネル設定オプション == |
||
− | UEFI システムのために必要な Linux カーネル設定オプションは: |
+ | UEFI システムのために必要な Linux カーネル設定オプション[https://docs.kernel.org/x86/x86_64/uefi.html]は: |
CONFIG_RELOCATABLE=y |
CONFIG_RELOCATABLE=y |
||
79行目: | 79行目: | ||
CONFIG_FRAMEBUFFER_CONSOLE=y |
CONFIG_FRAMEBUFFER_CONSOLE=y |
||
− | UEFI Runtime Variables Support ('''efivarfs''' ファイルシステム - {{ic|/sys/firmware/efi/efivars}})。このオプションは |
+ | UEFI Runtime Variables Support ('''efivarfs''' ファイルシステム - {{ic|/sys/firmware/efi/efivars}})。このオプションは [[#efibootmgr|efibootmgr]] などのツールを使って UEFI ランタイム変数を操作するのに必要なので重要です。次の設定オプションはカーネル 3.10 以上で追加されています。 |
CONFIG_EFIVAR_FS=y |
CONFIG_EFIVAR_FS=y |
||
87行目: | 87行目: | ||
CONFIG_EFI_VARS=n |
CONFIG_EFI_VARS=n |
||
− | + | [[GUID Partition Table]] (GPT) 設定オプション - UEFI サポートのために必須 |
|
CONFIG_EFI_PARTITION=y |
CONFIG_EFI_PARTITION=y |
||
111行目: | 111行目: | ||
# カーネルが [[EFISTUB]](任意で [[ブートマネージャー]])を通して、または[[ブートローダー]]によって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。 |
# カーネルが [[EFISTUB]](任意で [[ブートマネージャー]])を通して、または[[ブートローダー]]によって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。 |
||
# EFI Runtime Services サポートがカーネルに存在する必要があります ({{ic|1=CONFIG_EFI=y}})。{{ic|zgrep CONFIG_EFI /proc/config.gz}} で確認できます。 |
# EFI Runtime Services サポートがカーネルに存在する必要があります ({{ic|1=CONFIG_EFI=y}})。{{ic|zgrep CONFIG_EFI /proc/config.gz}} で確認できます。 |
||
− | # カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり {{ic|noefi}} カーネル |
+ | # カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり {{ic|noefi}} [[カーネルコマンドライン]]は使わないで下さい。 |
# {{ic|efivarfs}} ファイルシステムが {{ic|/sys/firmware/efi/efivars}} にマウントされている必要があります。マウントされていない時は下の [[#efivarfs のマウント]] セクションに従って下さい。 |
# {{ic|efivarfs}} ファイルシステムが {{ic|/sys/firmware/efi/efivars}} にマウントされている必要があります。マウントされていない時は下の [[#efivarfs のマウント]] セクションに従って下さい。 |
||
# {{ic|efivar}} はエラーを出さずに EFI 変数をリストアップ ({{ic|-l}}/{{ic|--list}} オプション) するはずです。 |
# {{ic|efivar}} はエラーを出さずに EFI 変数をリストアップ ({{ic|-l}}/{{ic|--list}} オプション) するはずです。 |
||
126行目: | 126行目: | ||
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars |
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars |
||
− | {{Note|上のコマンドは [[chroot]] の前と後、両方で実行する必要があります。 |
+ | {{Note|上のコマンドは [[chroot]] の前と後、両方で実行する必要があります。}} |
カーネルドキュメントの [https://www.kernel.org/doc/html/latest/filesystems/efivarfs.html efivarfs.html] を参照してください。 |
カーネルドキュメントの [https://www.kernel.org/doc/html/latest/filesystems/efivarfs.html efivarfs.html] を参照してください。 |
||
190行目: | 190行目: | ||
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。 |
UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。 |
||
− | === UEFI シェルを入手する === |
+ | === UEFI シェルを入手する === |
− | + | Tianocore EDK2 プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます: |
|
− | Shell v2: |
+ | * Shell v2: |
− | * Arch インストールメディアの {{ic|/shellx64.efi}} |
+ | ** Arch インストールメディアの {{ic|/shellx64.efi}}。ISO がビルドされたときの {{ic|/usr/share/edk2-shell/x64/Shell_Full.efi}} のコピーです。 |
− | * {{Pkg|edk2-shell}} パッケージ - x86_64 環境の x86_64 シェルと |
+ | ** {{Pkg|edk2-shell}} パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル |
− | * {{AUR|uefi-shell-git}} パッケージ - x86_64 環境の x86_64 シェルと |
+ | ** {{AUR|uefi-shell-git}} パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル |
− | Shell v1: |
+ | * Shell v1: |
− | * [https://github.com/tianocore/edk2/tree/ |
+ | ** TianoCore 由来の [https://github.com/tianocore/edk2/tree/UDK2018/EdkShellBinPkg プリコンパイル済み UEFI Shell v1 バイナリ] (2014/1/10 から上流は一度もアップデートされていません)。 |
− | 派生版: |
+ | * 派生版: |
− | * [https:// |
+ | ** [https://drive.google.com/uc?export=download&id=1OBXYj6MEs7VAZbYnjD9FxOYcZYIQoq36 プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg] - Clover EFI ブートローダ由来。 |
+ | ** [https://github.com/acidanthera/OpenCorePkg/releases 広い範囲のファームウェアと互換性のあるプリコンパイル済み UEFI Shell v2 バイナリ] - OpenCore ブートローダ由来。リリースアーカイブでは: {{ic|EFI/OC/Tools/OpenShell.efi}}。 |
||
+ | Shell v2 は UEFI 2.3 以上のシステム上でだけ動作します。UEFI 2.3 以上のシステムでは Shell v1 より v2 を使うことが推奨されます。Shell v1 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは [https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg ShellPkg] や [https://edk2-devel.narkive.com/zCN4CEnb/inclusion-of-uefi-shell-in-linux-distro-iso Inclusion of UEFI shell in Linux distro iso] を見て下さい。 |
||
− | |||
− | 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 シェルの起動 === |
||
− | Asus や AMI Aptio のマザーボード |
+ | 数少ない Asus や他の AMI Aptio x86_64 UEFI ファームウェアベースのマザーボード(Sandy Bridge 以降)では、''Launch EFI Shell from filesystem device'' と呼ばれるオプションが提供されています。これらのマザーボードでは、x86_64 UEFI Shell を [[EFI システムパーティション]] のルートに {{ic|shellx64.efi}} という名前で コピーしてください。 |
+ | |||
+ | {{Tip| |
||
+ | * Arch Linux インストールメディアにはボリュームのルートに {{ic|shellx64.efi}} があります。 |
||
+ | * [[rEFInd]] と [[systemd-boot]] は、{{ic|shellx64.efi}} が [[EFI システムパーティション]]のルートにある場合、自動的に UEFI シェルのブートメニューエントリを追加します。 |
||
+ | }} |
||
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており {{ic|F6}}, {{ic|F11}}, {{ic|F12}} キーのどれかで起動できます。 |
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており {{ic|F6}}, {{ic|F11}}, {{ic|F12}} キーのどれかで起動できます。 |
||
− | {{Note|上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、{{ic| |
+ | {{Note|上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、{{ic|''/USB_drive_mointpoint''/EFI/BOOT/BOOTx64.EFI}} としてコピーされた EFI バイナリのある [[FAT32]] USB ペンドライブを作成してください。この USB はファームウェアブートメニューを表示するはずです。このオプションを起動することで UEFI シェルが起動されます。}} |
=== 重要な UEFI シェルコマンド === |
=== 重要な UEFI シェルコマンド === |
||
220行目: | 225行目: | ||
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる {{ic|-b}} オプションをサポートしています。利用できるコマンドを表示するには {{ic|help -b}} を実行してください。 |
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる {{ic|-b}} オプションをサポートしています。利用できるコマンドを表示するには {{ic|help -b}} を実行してください。 |
||
− | 詳しい情報は https://software.intel.com/en-us/articles/efi-shells-and-scripting/ |
+ | 詳しい情報は [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ Intel Scripting Guide 2008] と [https://software.intel.com/en-us/articles/uefi-shell Intel "Course" 2011] を見てください。 |
==== bcfg ==== |
==== bcfg ==== |
||
− | {{ic|bcfg}} コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては |
+ | {{ic|bcfg}} コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては [https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf UEFI Shell Specification 2.2] ドキュメントの 96 ページ (Section 5.3) で詳しく説明されています。 |
{{Note| |
{{Note| |
||
* {{ic|efibootmgr}} が上手くブートエントリを作成できないときだけ {{ic|bcfg}} を使うことが推奨されています。 |
* {{ic|efibootmgr}} が上手くブートエントリを作成できないときだけ {{ic|bcfg}} を使うことが推奨されています。 |
||
− | * UEFI Shell v1 の公式バイナリは {{ic|bcfg}} コマンドをサポートしていません。UEFI pre-2.3 ファームウェアで動作する |
+ | * UEFI Shell v1 の公式バイナリは {{ic|bcfg}} コマンドをサポートしていません。[[#UEFI シェルを入手する]] を見て、UEFI pre-2.3 ファームウェアで動作する、修正された UEFI Shell v2 バイナリを入手してください。 |
}} |
}} |
||
237行目: | 242行目: | ||
4番目の(番号は0から始まります)オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには: |
4番目の(番号は0から始まります)オプションとしてブートメニューに rEFInd (例) のブートメニューエントリを追加するには: |
||
− | Shell> bcfg boot add 3 |
+ | Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager" |
− | {{ic| |
+ | {{ic|FS0:}} は EFI System Partition に、{{ic|FS0:\EFI\refind\refind_x64.efi}} は起動するファイルにそれぞれ適切にマッピングしてください。 |
+ | |||
+ | ブートローダ無しでシステムを直接ブートするエントリを追加するには、カーネルを [[EFISTUB#bcfg|EFISTUB]] として使用してブートオプションを設定してください: |
||
+ | |||
+ | Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux" |
||
+ | Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img" |
||
+ | |||
+ | {{ic|N}} は優先度、{{ic|V}} は EFI システムパーティションのボリューム番号、{{ic|/dev/sdX#}} はルートパーティションです。 |
||
4番目のブートオプションを削除するには: |
4番目のブートオプションを削除するには: |
||
259行目: | 271行目: | ||
==== map ==== |
==== map ==== |
||
− | {{ic|map}} はデバイスマッピング (利用可能なファイルシステム ({{ic| |
+ | {{ic|map}} はデバイスマッピング (つまり、利用可能なファイルシステム ({{ic|FS0}}) とストレージデバイス ({{ic|blk0}}) の名前) の一覧を表示します。 |
{{ic|cd}} や {{ic|ls}} などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります: |
{{ic|cd}} や {{ic|ls}} などのファイルシステムコマンドを実行する前に、ファイルシステムの名前を入力してシェルを適切なファイルシステムに変更する必要があります: |
||
270行目: | 282行目: | ||
{{ic|edit}} コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。 |
{{ic|edit}} コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。 |
||
− | 例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic| |
+ | 例として、システムパーティションの rEFInd の {{ic|refind.conf}} を編集するには (ファームウェア内の {{ic|FS0:}}) |
− | Shell> |
+ | Shell> edit FS0:\EFI\refind\refind.conf |
− | FS0:\> cd \EFI\arch\refind |
||
− | FS0:\EFI\arch\refind\> edit refind.conf |
||
− | ヘルプを出すには {{ic|Ctrl |
+ | ヘルプを出すには {{ic|Ctrl+e}} を押して下さい。 |
+ | |||
+ | == UEFI ドライバ == |
||
+ | |||
+ | {{Expansion|Explain what are and how to use UEFI drivers. Add automatic UEFI driver loading setup with efibootmgr's {{ic|-r}}/{{ic|--driver}} option. Mention rEFInd's file system drivers (and how it loads them), and also [https://github.com/systemd/systemd/issues/15617 systemd-boot's planned feature].}} |
||
== UEFI ブータブルメディア == |
== UEFI ブータブルメディア == |
||
282行目: | 296行目: | ||
=== ISO から UEFI ブータブル USB を作成する === |
=== ISO から UEFI ブータブル USB を作成する === |
||
− | [[USB インストールメディア#BIOS |
+ | [[USB インストールメディア#ISO をそのまま使う(BIOS と UEFI)]] を参照してください。 |
− | === |
+ | === 光学メディアから UEFI ブートサポートを削除する === |
+ | {{Note| |
||
− | {{Note|このセクションでは USB フラッシュドライブではなく '''CD/DVD''' (オプティカルメディア) から UEFI ブートサポートを削除する方法を説明しています。}} |
||
+ | * このセクションでは USB フラッシュドライブではなく '''CD/DVD''' (EL Torito からブートする光学メディア) から UEFI ブートサポートを削除する方法を説明しています。 |
||
+ | * USB スティック上の UEFI 機構を隠すには、ISO をフラッシュドライブにコピーしたあとでパーティションエディタを使ってください。{{ic|EF}} タイプのパーティションを削除してください。GPT に変換するか尋ねられたときは'''いいえ'''と答えてください。 |
||
+ | }} |
||
− | ほとんどの32ビット EFI Mac と |
+ | ほとんどの32ビット EFI Mac と一部の64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。光学メディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があるかもしれません。 |
− | + | UEFI 特有のディレクトリを除いて ISO を展開してください: |
|
+ | $ mkdir extracted_iso |
||
− | # mount -o loop ''input.iso'' /mnt/iso |
||
+ | $ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-''version''-x86_64.iso -C extracted_iso |
||
− | + | そして、{{Pkg|libisoburn}} の {{man|1|xorriso}} を使って ISO を再ビルドしてください。この時、UEFI 光学メディアのブートサポートを除いてください。正しいボリュームラベルを設定してください(例えば {{ic|ARCH_202103}})。ボリュームラベルは、オリジナルの ISO に対して {{man|1|file}} を使うことで得られます。 |
|
{{bc|1= |
{{bc|1= |
||
− | $ xorriso -as mkisofs |
+ | $ xorriso -as mkisofs \ |
− | - |
+ | -iso-level 3 \ |
− | - |
+ | -full-iso9660-filenames \ |
− | - |
+ | -joliet \ |
+ | -joliet-long \ |
||
− | -publisher "Arch Linux <https://www.archlinux.org>" \ |
||
+ | -rational-rock \ |
||
+ | -volid "ARCH_''YYYYMM''" \ |
||
+ | -appid "Arch Linux Live/Rescue CD" \ |
||
+ | -publisher "Arch Linux <https://archlinux.org>" \ |
||
-preparer "prepared by $USER" \ |
-preparer "prepared by $USER" \ |
||
− | -eltorito-boot |
+ | -eltorito-boot syslinux/isolinux.bin \ |
− | -eltorito-catalog |
+ | -eltorito-catalog syslinux/boot.cat \ |
-no-emul-boot -boot-load-size 4 -boot-info-table \ |
-no-emul-boot -boot-load-size 4 -boot-info-table \ |
||
− | -isohybrid-mbr "/ |
+ | -isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \ |
− | -output '' |
+ | -output archlinux-''version''-x86_64-noUEFI.iso extracted_iso/ |
}} |
}} |
||
− | + | {{ic|archlinux-''version''-x86_64-noUEFI.iso}} を光学メディアに焼いて、通常のインストールを続けてください。 |
|
− | + | == ネイティブサポートのない環境で UEFI をテストする == |
|
+ | === 仮想マシン用の OVMF === |
||
− | [[Archiso|公式 ISO]] は、32ビット (IA32) UEFI システムからの起動をサポートしていません ({{Bug|53182}})。カーネル内で、UEFI モード から起動するために EFISTUB を利用しているためです。64ビットカーネルを32ビット UEFIから起動するには、EFI Boot スタブに依存せずにカーネルを動かすようなブートローダーを利用しなければなりません。 |
||
+ | [https://github.com/tianocore/tianocore.github.io/wiki/OVMF OVMF] は仮想マシンで UEFI サポートを有効にする TianoCore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。 |
||
− | {{Tip|[[Archboot]] ISO は32ビット UEFI システムからの起動をサポートしています。}} |
||
+ | {{Pkg|edk2-ovmf}} をインストールできます。 |
||
− | == ネイティブサポートのない環境で UEFI をテストする == |
||
+ | 仮想マシンの非揮発性変数のローカルコピーを作成することが[https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt 推奨]されています: |
||
− | === 仮想マシン用の OVMF === |
||
+ | $ cp /usr/share/edk2-ovmf/x64/OVMF_VARS.fd my_uefi_vars.fd |
||
− | [https://tianocore.github.io/ovmf/ OVMF] は仮想マシンで UEFI サポートを有効にする tianocore プロジェクトです。OVMF には QEMU 用のサンプル UEFI ファームウェアが含まれています。 |
||
+ | OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください: |
||
− | [[公式リポジトリ]]から {{pkg|ovmf}}{{Broken package link|置換パッケージ: {{Pkg|edk2-ovmf}}}} をインストールして次のように実行することができます: |
||
+ | -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ |
||
− | $ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly |
||
+ | -drive if=pflash,format=raw,file=my_uefi_vars.fd |
||
+ | |||
+ | 例えば: |
||
+ | |||
+ | $ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd … |
||
=== BIOS システム用の DUET === |
=== BIOS システム用の DUET === |
||
− | DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする |
+ | DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする TianoCore プロジェクトです。この方法については https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ で広く議論されています。ビルド済み DUET イメージは https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer にあるリポジトリのどれかからダウンロードできます。DUET をセットアップする特定の方法については https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt で見られます。しかし、2018年11月に DUET のコードが TianoCore git リポジトリから削除されました。 |
− | また、修正 DUET イメージを提供する |
+ | また、修正 DUET イメージを提供する https://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の修正が含まれており gitlab リポジトリと比べて頻繁に更新されています。 |
== トラブルシューティング == |
== トラブルシューティング == |
||
+ | |||
+ | === Windows で固まった際に Arch Linux に戻る === |
||
+ | |||
+ | Windows で固まった際に Arch Linux に戻るには、Windows PowerShell コマンド {{ic|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 では、{{ic|F2}} や {{ic|F12}} のようなキーを使用しても何も起こりません。OEM にノート PC を返却しメインボード情報の修復を行えばおそらく修正可能ですが、時々これが不可能である、または望ましくない場合があります。しかし、ファームウェアセットアップに入る他の方法が存在します: |
||
+ | |||
+ | * [[systemd#電源管理|systemctl]] を使用: {{bc|$ systemctl reboot --firmware-setup}} これによりコンピュータが再起動され、ファームウェアセットアップに入ります。 |
||
+ | * [[GRUB]] を使用: コマンドラインに入るために {{ic|c}} を押し、GRUB コマンドラインで {{ic|fwsetup}} を使用してファームウェアセットアップに入る。 |
||
+ | * Windows で: ''Advanced Startup'' に入る。[[#Windows で固まった際に Arch Linux に戻る]] を見てください。 |
||
+ | |||
+ | === ユーザスペースのツールが UEFI 変数のデータを変更できない === |
||
+ | |||
+ | 如何なるユーザスペースツールを持ってしても UEFI 変数のデータを変更できない場合、{{ic|/sys/firmware/efi/efivars/dump-*}} ファイルが存在するかどうかを確認してください。存在する場合、それらを削除し、再起動して再び試してみてください。 |
||
+ | |||
+ | この手順でもこの問題を解決できない場合、{{ic|efi_no_storage_paranoia}} [[カーネルパラメータ]]を使用して起動してみてください(このカーネルパラメータは、UEFI 変数の書き込み/変更を妨げてしまうカーネル UEFI 変数ストレージスペースチェックを無効化します)。 |
||
+ | |||
+ | {{Warning|{{ic|efi_no_storage_paranoia}} は必要なときにだけ使用するべきで、普段のブートオプションとして残しておくべきではありません。このカーネルコマンドラインは、NVRAM が満杯になった際にマシンが起動できなることを防止するセーフガードを無効化する効果があります。詳細は {{Bug|34641}} を見てください。}} |
||
+ | |||
+ | === efibootmgr でブートエントリを新規作成できない === |
||
+ | |||
+ | カーネルと ''efibootmgr'' のバージョンの組み合わせによっては、ブートエントリの新規作成ができなるなるかもしれません。これは NVRAM の空き領域の不足によるものであることがあります。[[#ユーザスペースのツールが UEFI 変数のデータを変更できない]] の解決策を試すことができます。 |
||
+ | |||
+ | また、''efibootmgr'' をバージョン 0.11.0 まで[[ダウングレード]]してみることもできます。このバージョンは Linux バージョン 4.0.6 で機能します。詳細はバグのディスカッション {{Bug|34641}}、特に [https://bugs.archlinux.org/task/34641#comment111365 closing comment] を見てください。 |
||
=== UEFI モードで Windows 7 が起動しない === |
=== UEFI モードで Windows 7 が起動しない === |
||
+ | |||
+ | {{Note|Windows 7 は、インストールでは CSM が要求されますが、CSM サポートの無い純粋な UEFI class 3 で起動できます([https://web.archive.org/web/20150720172223/https://support.microsoft.com/en-us/kb/2828074 specifically INT 10 H])。}} |
||
Windows を GPT パーティションの別のハードディスクにインストールしていてコンピュータに MBR でパーティションされたハードディスクを接続している場合、UEFI BIOS が (MBR パーティションを起動するための) CSM サポートを起動しているせいで Windows が起動できなくなっている可能性があります。解決するには MBR ハードディスクを GPT パーティションに結合するか、MBR ハードディスクが接続されている SATA ポートを無効化する、もしくはハードディスクから SATA コネクタを抜いて下さい。 |
Windows を GPT パーティションの別のハードディスクにインストールしていてコンピュータに MBR でパーティションされたハードディスクを接続している場合、UEFI BIOS が (MBR パーティションを起動するための) CSM サポートを起動しているせいで Windows が起動できなくなっている可能性があります。解決するには MBR ハードディスクを GPT パーティションに結合するか、MBR ハードディスクが接続されている SATA ポートを無効化する、もしくはハードディスクから SATA コネクタを抜いて下さい。 |
||
346行目: | 401行目: | ||
=== Windows によってブート順序が変わってしまう === |
=== Windows によってブート順序が変わってしまう === |
||
+ | |||
− | マザーボードによっては起動する度に Windows 8 によって NVRAM の起動順序が変わってしまうことがあります (ASRock Z77 Extreme4 で確認)。この問題は Windows Boot Manager に Windows を起動する代わりに他のローダーをロードしてもらうようにすれば解決できます。Windows の管理者モードのコンソールで次のコマンドを実行してください: |
||
+ | [[Windows と Arch のデュアルブート]]をしていて、マザーボードがあなたの選んだ EFI アプリケーションではなく Windows を即座に起動する場合、いくつかのあり得る原因と回避策があります。 |
||
− | bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi |
||
+ | |||
+ | * [[Windows と Arch のデュアルブート#高速スタートアップとハイバネート|高速スタートアップ]]が Windows の電源オプションで無効化されていることを確認してください。 |
||
+ | * [[セキュアブート]]がファームウェアで無効化されていることを確認してください(署名済みのブートローダを使用していない場合)。 |
||
+ | * UEFI のブート順序で Windows Boot Manager が1番めに設定されていないことを確認してください(例: [[#efibootmgr|efibootmgr]] を使用)。一部のマザーボードは、Windows によって efibootmgr を使って設定したものを検出するとデフォルトで上書きします。これは Packard Bell ノート PC で確認されています。 |
||
+ | * マザーボードがデフォルトブートパス ({{ic|\EFI\BOOT\BOOTx64.EFI}}) を起動する場合、このファイルは Windows ブートローダで上書きされる場合があります。[[#efibootmgr|efibootmgr]] などを使用して、正しい |
||
+ | ブートパスを設定してみてください。 |
||
+ | * 前の手順でうまく行かなかった場合、Windows ブートローダに異なる EFI アプリケーションを実行するように指示することができます。Windows 管理者コマンドプロンプトから {{ic|bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}。 |
||
+ | * または、{{ic|efibootmgr -A -b ''bootnumber''}} を root として実行することで Windows Boot Manager を無効化する。{{ic|''bootnumber''}} の部分は実際の Windows Boot Manager のブート番号に置き換えてください。{{ic|efibootmgr}} をオプション足で実行することでブート番号を確認できます。 |
||
+ | * または、Windows を起動するたびにブート順序が正しく設定されているかを確認するスタートアップスクリプトを Windows で設定することができます。 |
||
+ | *# 管理者権限でコマンドプロンプトを開き、{{ic|bcdedit /enum firmware}} を実行して、お望みのブートエントリを見つけてください。 |
||
+ | *# カッコも含めて識別子をコピーしてください。例: {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}} |
||
+ | *# 次のコマンドを含むバッチファイルを作成してください: {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "''{コピーしたブート識別子}''"}} |
||
+ | *# ''gpedit.msc'' を開き、''Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)'' にある ''Startup'' をクリックしてください。 |
||
+ | *# ''Scripts'' タブに行き、''Add'' ボタンをクリックし、そのバッチファイルを選択してください。 |
||
+ | :: 注: [https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/how-to-install-gpeditmsc-in-window-10/f5e9c4fa-8d46-444c-acd7-5cabaea9fc71 Windows 10 Home は公式には gpedit.msc を含んでいません。しかし、それを手動でインストールする、サポートされない回避策があります。] |
||
+ | * または、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 メディアが黒画面で固まる === |
=== USB メディアが黒画面で固まる === |
||
− | + | この問題は [[Kernel Mode Setting|KMS]] の問題によって起こることがあります。USB を起動するときは [[Kernel_Mode_Setting#モードセッティングを無効にする|KMS を無効化]]してみて下さい。 |
|
+ | === ファームウェアのメニューに UEFI ブートローダーが表示されない === |
||
− | * 問題が KMS によるものではない場合、おそらく [[EFISTUB]] ブートのバグによる問題です (詳しくは {{Bug|33745}} や [https://bbs.archlinux.org/viewtopic.php?id=156670] を見て下さい)。公式 ISO ([[Archiso]]) と [[Archboot]] iso はどちらも UEFI モードでカーネルを起動するのに EFISTUB (メニューは [[Gummiboot]] ブートマネージャ) を使っています。この問題が起こった場合は下のセクションで書かれているように USB の UEFI ブートローダーとして [[GRUB]] を使って下さい。 |
||
+ | 一部のファームウェアはカスタムのブートエントリをサポートしていません。そのようなファームウェアはハードコードされたブートエントリからしか起動しません。 |
||
− | ==== GRUB の使用 ==== |
||
+ | 典型的な回避策は、NVRAM のブートエントリに頼るのではなく、[[EFI システムパーティション]]内の共通フォールバックパスの一つに[[ブートローダー]]をインストールすることです。 |
||
− | * [[USB インストールメディア#BIOS・UEFI ブータブル USB]] に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。 |
||
+ | 以下のセクションではそのフォールバックパスについて説明しています。 |
||
− | * {{ic|<USB>/EFI/boot/loader.efi}} を {{ic|<USB>/EFI/boot/gummiboot.efi}} にバックアップしてください。 |
||
+ | ==== リムーバブルドライブのデフォルトブートパス ==== |
||
− | * [[GRUB#GRUB_Standalone|GRUB スタンドアロンイメージを作成]]して {{ic|<USB>/EFI/boot/loader.efi}} にコピーしてください。 |
||
+ | UEFI 仕様では、リムーバブルメディアから起動するための EFI バイナリのデフォルトファイルパスが定義されています。関連するものとしては: |
||
− | * 以下の内容で {{ic|<USB>/EFI/boot/grub.cfg}} を作成してください ({{ic|ARCH_YYYYMM}} は USB ディスクのラベルに置き換えて下さい、例: {{ic|ARCH_201507}}): |
||
+ | * {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} - x86_64 UEFI 用 |
||
− | {{hc|grub.cfg for Official ISO|<nowiki> |
||
+ | * {{ic|''esp''/EFI/BOOT/BOOTIA.EFI}} - IA32 UEFI 用 |
||
− | insmod part_gpt |
||
− | insmod part_msdos |
||
− | insmod fat |
||
+ | 仕様では、これらはリムーバブルドライブのみ用であると定義されている一方、ほとんどのファームウェアはこれらの起動をすべてのドライブでサポートしています。 |
||
− | insmod efi_gop |
||
− | insmod efi_uga |
||
− | insmod video_bochs |
||
− | insmod video_cirrus |
||
+ | ブートローダーをデフォルト/フォールバックブートパスにインストール/統合する方法については適切な[[ブートローダー]]の記事を見てください。 |
||
− | insmod font |
||
+ | ==== Microsoft Windows ブートローダの場所 ==== |
||
− | if loadfont "${prefix}/fonts/unicode.pf2" ; then |
||
− | insmod gfxterm |
||
− | set gfxmode="1024x768x32;auto" |
||
− | terminal_input console |
||
− | terminal_output gfxterm |
||
− | fi |
||
+ | Itenl Z77 チップセット搭載の一部のボードのような特定の UEFI マザーボードでは、UEFI シェルから {{ic|efibootmgr}}/{{ic|bcfg}} を使用してエントリを追加することができません。NVRAM に追加したあとにエントリがブートメニューに表示されないためです。 |
||
− | 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 |
||
− | } |
||
+ | この問題はマザーボードが Microsoft Windows しか読み込めないため発生します。これを解決するには、Windows が使用する場所に ''.efi'' ファイルを配置する必要があります。 |
||
− | 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 |
||
− | } |
||
− | </nowiki>}} |
||
+ | Arch Linux インストールメディア({{ic|FSO:}}) からハードドライブ({{ic|FS1:}})上の [[ESP]] パーティション内の Microsoft ディレクトリへ {{ic|BOOTx64.EFI}} ファイルをコピーしてください。EFI シェルを起動し、以下を実行してください: |
||
− | {{hc|grub.cfg for Archboot ISO|<nowiki> |
||
− | insmod part_gpt |
||
− | insmod part_msdos |
||
− | insmod fat |
||
+ | Shell> mkdir FS1:\EFI\Microsoft |
||
− | insmod efi_gop |
||
+ | Shell> mkdir FS1:\EFI\Microsoft\Boot |
||
− | insmod efi_uga |
||
+ | Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi |
||
− | insmod video_bochs |
||
− | insmod video_cirrus |
||
+ | 再起動後、NVRAM に追加したエントリがブートメニュに表示されるはずです。 |
||
− | insmod font |
||
+ | === efibootmgr で作成したブートエントリが UEFI に表示されない === |
||
− | if loadfont "${prefix}/fonts/unicode.pf2" ; then |
||
− | insmod gfxterm |
||
− | set gfxmode="1024x768x32;auto" |
||
− | terminal_input console |
||
− | terminal_output gfxterm |
||
− | fi |
||
+ | ''efibootmgr'' は EDD 3.0 の検出に失敗する可能性があり、その結果、NVRAM に利用不可能なブートエントリを作成してしまいます。詳細は [https://github.com/rhboot/efibootmgr/issues/86 efibootmgr issue 86] を見てください。 |
||
− | 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 |
||
− | } |
||
+ | これを回避するには、ブートエントリを手動で作成する際に、{{ic|-e 3}} オプションを ''efibootmgr'' コマンドに追加してください。例: |
||
− | 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 |
||
− | } |
||
− | </nowiki>}} |
||
+ | # efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose '''-e 3''' |
||
− | === ファームウェアのメニューに UEFI ブートローダーが表示されない === |
||
+ | {{ic|grub-install}} や {{ic|refind-install}} のようなブートローダインストーラを修復するには、{{ic|/usr/local/bin/efibootmgr}} ラッパースクリプトを作成し、それを[[実行可能属性|実行可能]]にしてください: |
||
− | Intel Z77 チップセットなどが搭載された一部の UEFI マザーボードでは、UEFI シェルから {{ic|efibootmgr}} や {{ic|bcfg}} を使ってエントリを追加しても、ブートメニューのリストに表示されないため使うことができません。 |
||
+ | {{hc|/usr/local/bin/efibootmgr| |
||
− | この問題はマザーボードが Microsoft Windows しかロードしないようになっているのが原因です。解決するには Windows が使っている場所に ".efi" ファイルを配置するしかありません。 |
||
+ | #!/bin/sh |
||
+ | exec /usr/bin/efibootmgr -e 3 "$@" |
||
− | Arch Linux のインストールメディア ({{ic|FSO:}}) から {{ic|bootx64.efi}} ファイルをコピーしてハードドライブ ({{ic|FS1:}}) 上の ESP パーティションの Microsoft ディレクトリに配置してください。EFI シェルを起動して以下を実行します: |
||
+ | }} |
||
+ | === UEFI ブートエントリが、参照するドライブを取り外すと消える === |
||
− | 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 に追加されたエントリがブートメニューに表示されるはずです。 |
||
+ | |||
+ | 解決策は、[[ブートローダー]]を[[#リムーバブルドライブのデフォルトブートパス|デフォルト/フォールバックブートパス]]にインストールすることです。 |
||
== 参照 == |
== 参照 == |
||
458行目: | 495行目: | ||
* [https://www.uefi.org/home/ UEFI Forum] - 公式の [https://uefi.org/specifications UEFI の仕様書] - GUID Partition Table は UEFI の仕様に含まれています |
* [https://www.uefi.org/home/ UEFI Forum] - 公式の [https://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 によるブログ記事] |
||
− | * [https:// |
+ | * [https://docs.kernel.org/x86/x86_64/uefi.html Linux カーネル x86_64 UEFI ドキュメント] |
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel の EFI に関するページ] |
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel の EFI に関するページ] |
||
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center] |
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center] |
||
− | * [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub] |
+ | * [https://web.archive.org/web/20191230095118/https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub] |
− | * [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux] |
+ | * [https://web.archive.org/web/20190319175019/https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux] |
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: クイックインストールガイド] |
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: クイックインストールガイド] |
||
− | * [https:// |
+ | * [https://lore.kernel.org/lkml/20110608192950.GA29235@srcf.ucam.org/ 一部の新しいマシンでの UEFI ブート問題 (LKML)] |
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux] |
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux] |
||
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1] |
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI チュートリアル : part 1] |
||
474行目: | 511行目: | ||
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成] |
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Linux BIOS+UEFI と Windows x64 BIOS+UEFI ブータブル USB ドライブの作成] |
||
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation] |
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation] |
||
− | * |
+ | *[https://web.archive.org/web/20190404074007/https://software.intel.com/en-us/articles/efi-shells-and-scripting/ - Intel ドキュメント] |
− | * [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell |
+ | * [https://web.archive.org/web/20190117223426/https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel ドキュメント] |
− | * [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報] |
+ | * [https://web.archive.org/web/20130929114218/http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg コマンドの情報] |
+ | * [https://lwn.net/Articles/632528/ The bootstrap process on EFI systems] |
||
+ | |||
+ | {{TranslationStatus|Unified Extensible Firmware Interface|2022-09-09|745252}} |
2022年9月9日 (金) 11:01時点における版
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 UEFI モードで Windows 7 が起動しない
- 9.6 Windows によってブート順序が変わってしまう
- 9.7 USB メディアが黒画面で固まる
- 9.8 ファームウェアのメニューに UEFI ブートローダーが表示されない
- 9.9 efibootmgr で作成したブートエントリが UEFI に表示されない
- 9.10 UEFI ブートエントリが、参照するドライブを取り外すと消える
- 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 を含む UEFI ファームウェアの大部分は x86_64 UEFI ファームウェアを使用します。IA32 (32ビット) の UEFI を使うことが知られているデバイスは古い(2008年以前) Apple Mac や Intel Atom System-on-Chip システム(2013年11月2日現在)[1]、そして Intel EFI 1.10 ファームウェア上で動作することが知られている一部の古い Intel のサーバーボードだけです。
x86_64 UEFI ファームウェアは 32ビットの EFI アプリケーションの起動をサポートしません(x86_64 Linux とそのようなサポートを含む Windows のバージョン とは違って)。それゆえ、EFI アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。
UEFI ファームウェアのビット数を調べる
ファームウェアのビット数は起動されたオペレーティングシステムから確認できます。
Linux で
Linux カーネル 4.0 以上が走るディストリビューションでは、UEFI ファームウェアのビット数は sysfs インターフェイスを通して確認できます。以下を実行してください:
$ cat /sys/firmware/efi/fw_platform_size
このコマンドは、64ビット(x86_64) UEFI の場合は 64
、32ビット(IA32) UEFI の場合は 32
を返します。このファイルが存在しない場合は UEFI モードで起動していないということです。
macOS で
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 の仕様に完全には準拠していないからです。
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 (efivarfs ファイルシステム - /sys/firmware/efi/efivars
)。このオプションは efibootmgr などのツールを使って UEFI ランタイム変数を操作するのに必要なので重要です。次の設定オプションはカーネル 3.10 以上で追加されています。
CONFIG_EFIVAR_FS=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
この例では、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" --verbose
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
さらなる情報は efibootmgr(8) または efibootmgr README を見てください。
UEFI 変数へのアクセスを無効化
UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。貧弱な 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 パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 リリースから直接コンパイル
- uefi-shell-gitAUR パッケージ - x86_64 (64ビット) UEFI 環境用の x86_64 シェルと IA32 (32ビット) UEFI 環境用の IA32 シェルを提供します - 最新の Tianocore EDK2 ソースから直接コンパイル
- Arch インストールメディアの
- Shell v1:
- TianoCore 由来の プリコンパイル済み UEFI Shell v1 バイナリ (2014/1/10 から上流は一度もアップデートされていません)。
- 派生版:
- プリコンパイル済み UEFI Shell v2 バイナリと、UEFI pre-2.3 ファームウェアで動くように変更された bcfg - 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 x86_64 UEFI ファームウェアベースのマザーボード(Sandy Bridge 以降)では、Launch EFI Shell from filesystem device と呼ばれるオプションが提供されています。これらのマザーボードでは、x86_64 UEFI Shell を EFI システムパーティション のルートに shellx64.efi
という名前で コピーしてください。
Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており F6
, F11
, F12
キーのどれかで起動できます。
重要な UEFI シェルコマンド
UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b
オプションをサポートしています。利用できるコマンドを表示するには help -b
を実行してください。
詳しい情報は Intel Scripting Guide 2008 と Intel "Course" 2011 を見てください。
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 ブータブルメディア
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-ovmf/x64/OVMF_VARS.fd my_uefi_vars.fd
OVMF ファームウェアとこの変数を使うには、以下を QEMU コマンドに追加してください:
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=my_uefi_vars.fd
例えば:
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd …
BIOS システム用の DUET
DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする TianoCore プロジェクトです。この方法については https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ で広く議論されています。ビルド済み DUET イメージは https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer にあるリポジトリのどれかからダウンロードできます。DUET をセットアップする特定の方法については https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt で見られます。しかし、2018年11月に DUET のコードが TianoCore git リポジトリから削除されました。
また、修正 DUET イメージを提供する https://sourceforge.net/projects/cloverefiboot/ を試すことも可能です。特定環境の修正が含まれており 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 を見てください。
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 と 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
- x86_64 UEFI 用esp/EFI/BOOT/BOOTIA.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" --verbose -e 3
grub-install
や refind-install
のようなブートローダインストーラを修復するには、/usr/local/bin/efibootmgr
ラッパースクリプトを作成し、それを実行可能にしてください:
/usr/local/bin/efibootmgr
#!/bin/sh exec /usr/bin/efibootmgr -e 3 "$@"
UEFI ブートエントリが、参照するドライブを取り外すと消える
一部のファームウェアは、参照されているドライブが起動中に存在しない場合、そのブートエントリを削除します。これは、ドライブを頻繁に取り付け/取り外ししたり、リムーバブルドライブから起動する際に問題となりえます。
解決策は、ブートローダーをデフォルト/フォールバックブートパスにインストールすることです。
参照
- 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
- 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