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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎トラブルシューティング: いくつかのセクションを追加(英語版より))
344行目: 344行目:
   
 
== トラブルシューティング ==
  
== トラブルシューティング ==
  +
  +
=== Windows で固まった際に Arch Linux に戻る ===
  +
  +
To boot back into Arch Linux when you are stuck with Windows, reach ''Advanced startup'' in Windows by the Windows PowerShell command {{ic|shutdown /r /o}}, or via ''Settings > Update & Security > Recovery > Advanced startup'' and select ''Restart now''. When you have reached the ''Advanced startup'' menu, choose ''Use a device'', which actually contains your UEFI boot options (not limited to USB or CD, but can also boot operating system in hard drive), and choose "Arch Linux".
  +
  +
=== ファンクションキー無しでファームウェアセットアップに入る ===
  +
  +
On some laptops, like [[Lenovo XiaoXin 15are 2020]], using keys like {{ic|F2}} or {{ic|F12}} does not do anything. This can possibly be fixed by returning laptops to OEM to repair mainboard information, but sometimes this is not possible or not desired. There are however other means to enter firmware setup:
  +
  +
* With [[systemd#Power management|systemctl]]: {{bc|$ systemctl reboot --firmware-setup}} This will reboot your computer to firmware setup.
  +
* With [[GRUB]]: Press {{ic|c}} for command line and in GRUB command line use {{ic|fwsetup}} to enter firmware setup.
  +
* In Windows: Enter ''Advanced Startup'', see [[#Boot back to Arch Linux when stuck with Windows]].
  +
  +
=== ユーザスペースのツールが UEFI 変数のデータを変更できない ===
  +
  +
If any userspace tool is unable to modify UEFI variable data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.
  +
If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.
  +
  +
{{Warning|{{ic|efi_no_storage_paranoia}} should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See {{Bug|34641}} for more information.}}
  +
  +
=== efibootmgr でブートエントリを新規作成できない ===
  +
  +
Some kernel and ''efibootmgr'' version combinations might refuse to create new boot entries. This could be due to lack of free space in the NVRAM. You can try the solution at [[#Userspace tools are unable to modify UEFI variable data]].
  +
  +
You can also try to [[downgrade]] your ''efibootmgr'' install to version 0.11.0. This version works with Linux version 4.0.6. See the bug discussion {{Bug|34641}}, in particular the [https://bugs.archlinux.org/task/34641#comment111365 closing comment], for more information.
   
 
=== UEFI モードで Windows 7 が起動しない ===
  
=== UEFI モードで Windows 7 が起動しない ===
  +
  +
{{Note|Windows 7 can boot in pure UEFI class 3 without CSM support, though installation requires CSM ([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 コネクタを抜いて下さい。
355行目: 382行目:
   
 
=== Windows によってブート順序が変わってしまう ===
  
=== Windows によってブート順序が変わってしまう ===
  +
−
マザーボードによっては起動する度に Windows 8 によって NVRAM の起動順序が変わってしまうことがあります (ASRock Z77 Extreme4 で確認)。この問題は Windows Boot Manager に Windows を起動する代わりに他のローダーをロードしてもらうようにすれば解決できます。Windows の管理者モードのコンソールで次のコマンドを実行してください:
  
  +
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen EFI application, there are several possible causes and workarounds.
−
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi
  
  +
  +
* Ensure [[Dual boot with Windows#Fast Startup and hibernation|Fast Startup]] is disabled in your Windows power options
  +
* Ensure [[Secure Boot]] is disabled in your firmware (if you are not using a signed boot loader)
  +
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr|efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.
  +
* If your motherboard is booting the default boot path ({{ic|\EFI\BOOT\BOOTx64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr|efibootmgr]].
  +
* If the previous steps do not work, you can tell the Windows boot loader to run a different EFI application. From a Windows administrator command prompt {{ic|bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}
  +
* Alternatively, deactivate the Windows Boot Manager by running {{ic|efibootmgr -A -b ''bootnumber''}} as root. Replace {{ic|''bootnumber''}} with the actual Windows Boot Manager boot number; you can see it by running {{ic|efibootmgr}} with no options.
  +
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.
  +
*# Open a command prompt with administrator privileges. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.
  +
*# Copy the identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}
  +
*# Create a batch file with the command {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "''{copied-boot-identifier}''"}}
  +
*# Open ''gpedit.msc'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)'', choose ''Startup''
  +
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file
  +
:: Note: [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 does not officially include gpedit.msc, although there are unsupported workarounds to install it manually.]
  +
* Alternatively, Task Scheduler can be used to run a startup script in Windows:
  +
*# Follow steps 1-3 above to create the batch file.
  +
*# Run ''taskschd.msc'', then choose ''Create Task...'' from the ''Action'' menu.
  +
*# On the ''General'' tab:
  +
*#: Enter any suitable ''Name'' and ''Description''.
  +
*#: Ensure the user account selected is an "Administrator", not a "Standard User".
  +
*#: Select "''Run whether user is logged in or not''".
  +
*#: Select "''Run with highest privileges''".
  +
*# On the ''Triggers'' tab, choose "''At startup''" from the menu, then click ''OK''.
  +
*# On the ''Actions'' tab, click ''New...'', then ''Browse...'', and locate the batch file from step 1.
  +
*# On the ''Conditions tab'', untick the ''Power'' options so the script runs when on battery power (for laptops).
  +
*# Click ''OK'', and enter the password of the user account selected in step 4 when prompted.
   
 
=== USB メディアが黒画面で固まる ===
  
=== USB メディアが黒画面で固まる ===
   
−
* この問題は [[Kernel Mode Setting|KMS]] の問題によって起こることがあります。USB を起動するときは [[Kernel_Mode_Setting#モードセッティングを無効にする|KMS を無効化]]してみて下さい。
 +
この問題は [[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]] を使って下さい。
  
   
  +
Some firmware do not support custom boot entries. They will instead only boot from hardcoded boot entries.
−
==== GRUB の使用 ====
  
   
  +
A typical workaround is to not rely on boot entries in the NVRAM and install the boot loader to one of the common fallback paths on the EFI system partition.
−
* [[USB インストールメディア#BIOS・UEFI ブータブル USB]] に書かれているように USB フラッシュインストールドライブを作成してください。その後以下の手順に従って Gummiboot の代わりに GRUB を使って下さい。
  
   
  +
The following sections describe the fallback paths.
−
* {{ic|<USB>/EFI/boot/loader.efi}} を {{ic|<USB>/EFI/boot/gummiboot.efi}} にバックアップしてください。
  
   
−
* [[GRUB#GRUB_Standalone|GRUB スタンドアロンイメージを作成]]して {{ic|<USB>/EFI/boot/loader.efi}} にコピーしてください。
  
   
  +
==== リムーバブルドライブのデフォルトブートパス ====
−
* 以下の内容で {{ic|<USB>/EFI/boot/grub.cfg}} を作成してください ({{ic|ARCH_YYYYMM}} は USB ディスクのラベルに置き換えて下さい、例: {{ic|ARCH_201507}}):
  
   
  +
The UEFI specification defines default file paths for EFI binaries for booting from removable media. The relevant ones are:
−
{{hc|grub.cfg for Official ISO|<nowiki>
  
−
insmod part_gpt
  
−
insmod part_msdos
  
−
insmod fat
  
   
  +
* {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} for x86_64 UEFI
−
insmod efi_gop
  
  +
* {{ic|''esp''/EFI/BOOT/BOOTIA.EFI}} for IA32 UEFI.
−
insmod efi_uga
  
−
insmod video_bochs
  
−
insmod video_cirrus
  
   
  +
While the specification defines these for removable drives only, most firmware support booting these from any drive.
−
insmod font
  
   
  +
See the appropriate [[boot loader]] article on how to install or migrate the boot loader to the default/fallback boot path.
−
if loadfont "${prefix}/fonts/unicode.pf2" ; then
  
−
insmod gfxterm
  
−
set gfxmode="1024x768x32;auto"
  
−
terminal_input console
  
−
terminal_output gfxterm
  
−
fi
  
   
  +
==== Microsoft Windows ブートローダの場所 ====
−
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
  
−
}
  
   
  +
On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the UEFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.
−
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>}}
  
   
  +
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the ''.efi'' file in the location that Windows uses.
−
{{hc|grub.cfg for Archboot ISO|<nowiki>
  
−
insmod part_gpt
  
−
insmod part_msdos
  
−
insmod fat
  
   
  +
Copy the {{ic|BOOTx64.EFI}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:
−
insmod efi_gop
  
−
insmod efi_uga
  
−
insmod video_bochs
  
−
insmod video_cirrus
  
   
  +
Shell> mkdir FS1:\EFI\Microsoft
−
insmod font
  
  +
Shell> mkdir FS1:\EFI\Microsoft\Boot
  +
Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi
   
  +
After reboot, any entries added to NVRAM should show up in the boot menu.
−
if loadfont "${prefix}/fonts/unicode.pf2" ; then
  
−
insmod gfxterm
  
−
set gfxmode="1024x768x32;auto"
  
−
terminal_input console
  
−
terminal_output gfxterm
  
−
fi
  
   
  +
=== ハードウェアの変更や他のオペレーティングシステムを起動したあとにシステムが EFI シェルに入る ===
−
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
  
−
}
  
   
  +
{{Style|Too GRUB-specific, most boot loader install commands have an option to install to the default/fallback boot path. Duplicates [[#Windows changes boot order]] and [[GRUB#Default/fallback boot path]].}}
−
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>}}
  
   
  +
{{Accuracy|Why would booting Windows change/remove UEFI boot entries? If such an issue actually exists, it needs a reference.}}
−
=== ファームウェアのメニューに UEFI ブートローダーが表示されない ===
  
   
  +
EFI stores state on the motherboard, called EFIVARS. Your bootloader (e.g. GRUB) may need to set up these variables in a certain way in order to boot. If your hardware configuration changes, your motherboard is replaced, or you boot into another operating system which overwrites these variables (Windows), you may be dumped into the EFI shell or boot menu (where your device is not listed). Upon attempting to boot Arch Linux since the EFIVARS are incorrect and EFI can no longer find your bootloader.
−
Intel Z77 チップセットなどが搭載された一部の UEFI マザーボードでは、UEFI シェルから {{ic|efibootmgr}} や {{ic|bcfg}} を使ってエントリを追加しても、ブートメニューのリストに表示されないため使うことができません。
  
   
  +
At this point, you can use the EFI shell to find and boot your bootloader manually. Usually something like:
−
この問題はマザーボードが Microsoft Windows しかロードしないようになっているのが原因です。解決するには Windows が使っている場所に ".efi" ファイルを配置するしかありません。
  
   
  +
Shell> ls fs0:
−
Arch Linux のインストールメディア ({{ic|FSO:}}) から {{ic|bootx64.efi}} ファイルをコピーしてハードドライブ ({{ic|FS1:}}) 上の ESP パーティションの Microsoft ディレクトリに配置してください。EFI シェルを起動して以下を実行します:
  
  +
EFI\
  +
initramfs-linux.img
  +
intel-ucode.img
  +
loader\
  +
vmlinuz-linux
   
−
Shell> mkdir FS1:\EFI\Microsoft
 +
Shell> ls fs0:EFI\
  +
BOOT\
−
Shell> mkdir FS1:\EFI\Microsoft\Boot
  
  +
Linux\
−
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
  
  +
systemd
  +
  +
Shell> ls fs0:EFI\BOOT\
  +
BOOTx64.EFI
  +
  +
Shell> fs0:EFI\BOOT\BOOTx64.EFI
  +
Starting fs0:EFI\BOOT\BOOTx64.EFI...
  +
  +
To prevent booting into the EFI shell again, you can install your bootloader to the default EFI boot location. To do this with GRUB's {{ic|grub-install}}, see [[GRUB#Default/fallback boot path]].
  +
  +
There is no guaranteed success for the "Default/fallback boot path" method. Some board firmware (for example AsRock C2550D4I and C2750D4I) will search and boot the default locations on removable drives only. Booting from non removable drives (such as internal HDD, NVMe, etc.) requires fixing the efivars. For example using {{ic|efibootmgr}}:
  +
  +
# efibootmgr --create --disk /dev/nvme0n1 --label "Arch Linux" --loader /vmlinuz-linux --unicode "root=PARTUUID=cd3a4f01-035a-25e3-b1ac-ea834e75aac1 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img" --verbose
  +
  +
=== efibootmgr で作成したブートエントリが UEFI に表示されない ===
  +
  +
''efibootmgr'' can fail to detect EDD 3.0 and as a result create unusable boot entries in NVRAM. See [https://github.com/rhboot/efibootmgr/issues/86 efibootmgr issue 86] for the details.
  +
  +
To work around this, when creating boot entries manually, add the {{ic|-e 3}} option to the ''efibootmgr'' command. E.g.
  +
  +
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose '''-e 3'''
  +
  +
To fix boot loader installers, like {{ic|grub-install}} and {{ic|refind-install}}, create a wrapper script {{ic|/usr/local/bin/efibootmgr}} and make it [[executable]]:
  +
  +
{{hc|/usr/local/bin/efibootmgr|
  +
#!/bin/sh
  +
  +
exec /usr/bin/efibootmgr -e 3 "$@"
  +
}}
  +
  +
=== UEFI ブートエントリが、参照するドライブを取り外すと消える ===
  +
  +
Some firmware will remove boot entries referencing drives that are not present during boot. This could be an issue when frequently detaching/attaching drives or when booting from a removable drive.
   
  +
The solution is to install the [[boot loader]] to [[#Default boot path for removable drives|the default/fallback boot path]].
−
再起動後、NVRAM に追加されたエントリがブートメニューに表示されるはずです。
  
   
 
== 参照 ==
  
== 参照 ==

2022年6月14日 (火) 07:12時点における版

関連記事

Unified Extensible Firmware Interface (もしくは省略して UEFI や EFI)はオペレーティングシステムとファームウェア間のインターフェイスのモデルですオペレーティングシステムを起動したり、プリブートアプリケーション用の標準的な環境を提供します。

UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なります。これらの違いや UEFI を用いた起動プロセスについては Arch ブートプロセス を見てください。UEFI ブートローダをセットアップするには ブートローダー を見てください。

ノート: 初期のベンダー UEFI 実装は BIOS のものよりも多くのバグを含んでいる場合があります。そのようなシステムで解決不可能な問題に直面した場合は、レガシー BIOS を使用して起動することを検討してください。

目次

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 アプリケーションは特定のファームウェアプロセッサのビット数/アーキテクチャ用にコンパイルされなければなりません。

ノート: IA32 UEFI のシステムでは、異なるモードでの起動をサポートするブートローダを使用する必要があります。例えば、i386-efi を対象にしてインストールされた GRUB などです。

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 カーネル設定オプションは: 

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)。このオプションは /usr/bin/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 変数のサポートを正しく動作させるための必要条件

  1. カーネルが EFISTUB(任意で ブートマネージャー)を通して、またはブートローダーによって UEFI モードで起動している必要があります。BIOS や CSM、(同じく CSM の) Apple の Boot Camp を通して起動してはいない必要があります。
  2. EFI Runtime Services サポートがカーネルに存在する必要があります (CONFIG_EFI=y)。zgrep CONFIG_EFI /proc/config.gz で確認できます。
  3. カーネルコマンドラインでカーネルの EFI Runtime Services を無効にしてはいけません。つまり noefi カーネルパラメータは使わないで下さい。
  4. efivarfs ファイルシステムが /sys/firmware/efi/efivars にマウントされている必要があります。マウントされていない時は下の #efivarfs のマウント セクションに従って下さい。
  5. efivar はエラーを出さずに EFI 変数をリストアップ (-l/--list オプション) するはずです。

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

  1. UEFI 変数のリストアップ(efivar -l)の際に efivar: error listing variables: Function not implemented と言うメッセージが出て、かつ、システムがリアルタイムカーネルで起動する場合、カーネルパラメータに efi=runtime を追加して再起動してください(これらのカーネルでは efivarfs 機能がデフォルトで無効化されています)。
  2. さらなるドラブルシューティング手順は #ユーザスペースのツールが UEFI 変数のデータを変更できない を見てください。

efivarfs のマウント

efivarfs が起動中にsystemd によって自動的に /sys/firmware/efi/efivars にマウントされない場合、UEFI 変数を efibootmgr のようなユーザースペースツールに公開するために efivarfs を手動でマウントする必要があります: 

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

}

カーネルドキュメントの efivarfs.html を参照してください。

ユーザースペースツール

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

  • efivar — UEFI 変数を操作するためのライブラリとツール (vathpela の efibootmgr によって使われます)
https://github.com/rhboot/efivar || efivar
  • efibootmgr — UEFI Firmware Boot Manager の設定を操作するツール
https://github.com/rhboot/efibootmgr || efibootmgr
  • uefivars — EFI 変数と追加の PCI 関連情報を表示します (内部で efibootmgr のコードを使っています)。
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  • efitools — UEFI セキュアブートプラットフォームを操作するための UEFI ツール
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools
  • Ubuntu's Firmware Test Suite — Intel/AMD PC のファームウェア上でサニティチェックを行うためのテストスイート
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR

efibootmgr

efibootmgr パッケージをインストールする必要があります。

ノート:
  • あなたの環境で efibootmgr が完全に動かない場合、再起動して #UEFI シェル に入り bcfg コマンドを使ってブートローダのブートエントリを作成してください。
  • efibootmgr を使えない場合、UEFI BIOS によっては BIOS から直接 uefi のブートオプションを管理できることがあります。例えば、ASUS の BIOS には "Add New Boot Option" からローカルの EFI System Partition を選択して直接 EFI スタブの位置を入力できます (例えば \EFI\refind\refind_x64.efi)。
  • 下のコマンドではサンプルとして rEFInd ブートローダを使っています。

efibootmgr を使って新しいブートオプションを追加するには、以下の3つを知っている必要があります:

  1. EFI システムパーティション (ESP) を含むディスク (例: /dev/sda /dev/nvme0n1)。
  2. そのディスク上にある ESP のパーティション番号。/dev/sdaY や /dev/nvme0n1pY の Y の部分のことです。
  3. 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 では逆スラッシュ \ がパスセパレータとして使用されますが、efibootmgr は自動的に UNIX スタイルの / パスセパレータに変換してくれます。

UEFI 変数へのアクセスを無効化

UEFI へのアクセスは OS の実行レベルを超えて害を及ぼす可能性があります。貧弱な UEFI 実装では場合によってはハードウェアレベルで起動不可能にすることも可能です。[2]

ゆえに、UEFI 変数へのアクセスは日常的なシステム使用において必要とされないので、潜在的なセキュリティ違反や偶発的な害を防ぐために無効化しておくことをおすすめします。

可能な方法は:

  • efivars を fstab を用いて読み取り専用モードでマウントする。例えば: 
    efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
  • noefi カーネルパラメータを使用して、OS から UEFI へのアクセスを完全に無効化する。
ノート: UEFI ユーザスペースツール は UEFI 変数へのアクセスが無効化された状態では使用できないので、必要な設定をすべて前もって行っておいてください。また、UEFI 関連のコマンド(例: systemctl reboot --firmware-setup) も機能しなくなります。

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 ソースから直接コンパイル

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 という名前で コピーしてください。

ヒント:
  • Arch Linux インストールメディアにはボリュームのルートに shellx64.efi があります。
  • rEFInd と systemd-boot は、shellx64.efi が EFI システムパーティションのルートにある場合、自動的に UEFI シェルのブートメニューエントリを追加します。

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

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

重要な UEFI シェルコマンド

UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。利用できるコマンドを表示するには help -b を実行してください。

詳しい情報は https://software.intel.com/en-us/articles/efi-shells-and-scripting/

bcfg

bcfg コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては "UEFI Shell Specification 2.0" pdf ドキュメントの 83 ページ (Section 5.3) で詳しく説明されています。

ノート:
  • efibootmgr が上手くブートエントリを作成できないときだけ bcfg を使うことが推奨されています。
  • UEFI Shell v1 の公式バイナリは bcfg コマンドをサポートしていません。UEFI pre-2.3 ファームウェアで動作する 修正 UEFI Shell v2 バイナリ をダウンロードできます。

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

Shell> bcfg boot dump -v

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

Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"

fs0: は EFI System Partition に、\EFI\refind\refind_x64.efi は起動するファイルにそれぞれ適切にマッピングしてください。

4番目のブートオプションを削除するには: 

Shell> bcfg boot rm 3

ブートオプション #3 を #0 (つまり UEFI ブートメニューの最初のエントリ) に移動するには: 

Shell> bcfg boot mv 3 0

bcfg のヘルプを見るには 

Shell> help bcfg -v -b

もしくは 

Shell> bcfg -? -v -b

map

map はデバイスマッピング (利用可能なファイルシステム (fs0) とストレージデバイス (blk0) の名前) の一覧を表示します。

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

Shell> fs0:
fs0:\> cd EFI/

edit

edit コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。

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

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

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

UEFI ドライバ

この記事またはセクションは加筆を必要としています。
理由: Explain what are and how to use UEFI drivers. Add automatic UEFI driver loading setup with efibootmgr's -r/--driver option. Mention rEFInd's file system drivers (and how it loads them), and also systemd-boot's planned feature. (議論: トーク:Unified Extensible Firmware Interface#)

UEFI ブータブルメディア

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

USB インストールメディア#BIOS・UEFI ブータブル USB を参照してください。

オプティカルメディアから UEFI ブートサポートを削除する

ノート: このセクションでは USB フラッシュドライブではなく CD/DVD (オプティカルメディア) から UEFI ブートサポートを削除する方法を説明しています。

ほとんどの32ビット EFI Mac といくつかの64ビット EFI Mac は UEFI(X64)+BIOS ブータブル CD/DVD からの起動を拒否します。オプティカルメディアを使ってインストールをしたい場合、まず UEFI サポートを削除する必要があります。

  • 公式インストールメディアをマウントして前のセクションで示されているように archisolabel を取得してください。
# mount -o loop input.iso /mnt/iso
  • libisoburn に含まれている xorriso を使って UEFI Optical Media ブートサポートを除いた ISO を再生成してください (archisolabel は "ARCH_201411" などに適当に置き換えて下さい)。
$ xorriso -as mkisofs -iso-level 3 \
    -full-iso9660-filenames\
    -volid "archisolabel" \
    -appid "Arch Linux CD" \
    -publisher "Arch Linux <https://www.archlinux.org>" \
    -preparer "prepared by $USER" \
    -eltorito-boot isolinux/isolinux.bin \
    -eltorito-catalog isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \
    -output output.iso /mnt/iso/
  • output.iso をオプティカルメディアに焼いて通常通りインストールに進んで下さい。

32ビット UEFI で 64ビットカーネルを起動する

公式 ISO は、32ビット (IA32) UEFI システムからの起動をサポートしていません (FS#53182)。カーネル内で、UEFI モード から起動するために EFISTUB を利用しているためです。64ビットカーネルを32ビット UEFIから起動するには、EFI Boot スタブに依存せずにカーネルを動かすようなブートローダーを利用しなければなりません。

ヒント: Archboot ISO は32ビット UEFI システムからの起動をサポートしています。

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

仮想マシン用の OVMF

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

公式リポジトリから ovmf[リンク切れ: 置換パッケージ: edk2-ovmf] をインストールして次のように実行することができます: 

$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly

BIOS システム用の DUET

DUET は、BIOS の OS ブートと同じような方法で、BIOS 環境から完全な UEFI 環境をチェーンロードできるようにする tianocore プロジェクトです。この方法については http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ で広く議論されています。DUET を設定する手順は https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt にあります。

また、修正 DUET イメージを提供する Clover EFI bootloader を試すことも可能です。特定環境の fix が含まれており DUET と比べて頻繁に更新されています。

トラブルシューティング

Windows で固まった際に Arch Linux に戻る

To boot back into Arch Linux when you are stuck with Windows, reach Advanced startup in Windows by the Windows PowerShell command shutdown /r /o, or via Settings > Update & Security > Recovery > Advanced startup and select Restart now. When you have reached the Advanced startup menu, choose Use a device, which actually contains your UEFI boot options (not limited to USB or CD, but can also boot operating system in hard drive), and choose "Arch Linux".

ファンクションキー無しでファームウェアセットアップに入る

On some laptops, like Lenovo XiaoXin 15are 2020, using keys like F2 or F12 does not do anything. This can possibly be fixed by returning laptops to OEM to repair mainboard information, but sometimes this is not possible or not desired. There are however other means to enter firmware setup:

ユーザスペースのツールが UEFI 変数のデータを変更できない

If any userspace tool is unable to modify UEFI variable data, check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist, delete them, reboot and retry again. If the above step does not fix the issue, try booting with efi_no_storage_paranoia kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.

警告: efi_no_storage_paranoia should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See FS#34641 for more information.

efibootmgr でブートエントリを新規作成できない

Some kernel and efibootmgr version combinations might refuse to create new boot entries. This could be due to lack of free space in the NVRAM. You can try the solution at #Userspace tools are unable to modify UEFI variable data.

You can also try to downgrade your efibootmgr install to version 0.11.0. This version works with Linux version 4.0.6. See the bug discussion FS#34641, in particular the closing comment, for more information.

UEFI モードで Windows 7 が起動しない

ノート: Windows 7 can boot in pure UEFI class 3 without CSM support, though installation requires CSM (specifically INT 10 H).

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 によってブート順序が変わってしまう

If you dual boot with Windows and your motherboard just boots Windows immediately instead of your chosen EFI application, there are several possible causes and workarounds.

  • Ensure Fast Startup is disabled in your Windows power options
  • Ensure Secure Boot is disabled in your firmware (if you are not using a signed boot loader)
  • Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using efibootmgr and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.
  • If your motherboard is booting the default boot path (\EFI\BOOT\BOOTx64.EFI), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using efibootmgr.
  • If the previous steps do not work, you can tell the Windows boot loader to run a different EFI application. From a Windows administrator command prompt bcdedit /set "{bootmgr}" path "\EFI\path\to\app.efi"
  • Alternatively, deactivate the Windows Boot Manager by running efibootmgr -A -b bootnumber as root. Replace bootnumber with the actual Windows Boot Manager boot number; you can see it by running efibootmgr with no options.
  • Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.
    1. Open a command prompt with administrator privileges. Run bcdedit /enum firmware and find your desired boot entry.
    2. Copy the identifier, including the brackets, e.g. {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
    3. Create a batch file with the command bcdedit /set "{fwbootmgr}" DEFAULT "{copied-boot-identifier}"
    4. Open gpedit.msc and under Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown), choose Startup
    5. Under the Scripts tab, choose the Add button, and select your batch file
Note: Windows 10 Home does not officially include gpedit.msc, although there are unsupported workarounds to install it manually.
  • Alternatively, Task Scheduler can be used to run a startup script in Windows:
    1. Follow steps 1-3 above to create the batch file.
    2. Run taskschd.msc, then choose Create Task... from the Action menu.
    3. On the General tab:
      Enter any suitable Name and Description.
      Ensure the user account selected is an "Administrator", not a "Standard User".
      Select "Run whether user is logged in or not".
      Select "Run with highest privileges".
    4. On the Triggers tab, choose "At startup" from the menu, then click OK.
    5. On the Actions tab, click New..., then Browse..., and locate the batch file from step 1.
    6. On the Conditions tab, untick the Power options so the script runs when on battery power (for laptops).
    7. Click OK, and enter the password of the user account selected in step 4 when prompted.

USB メディアが黒画面で固まる

この問題は KMS の問題によって起こることがあります。USB を起動するときは KMS を無効化してみて下さい。

ファームウェアのメニューに UEFI ブートローダーが表示されない

Some firmware do not support custom boot entries. They will instead only boot from hardcoded boot entries.

A typical workaround is to not rely on boot entries in the NVRAM and install the boot loader to one of the common fallback paths on the EFI system partition.

The following sections describe the fallback paths.


リムーバブルドライブのデフォルトブートパス

The UEFI specification defines default file paths for EFI binaries for booting from removable media. The relevant ones are:

  • esp/EFI/BOOT/BOOTx64.EFI for x86_64 UEFI
  • esp/EFI/BOOT/BOOTIA.EFI for IA32 UEFI.

While the specification defines these for removable drives only, most firmware support booting these from any drive.

See the appropriate boot loader article on how to install or migrate the boot loader to the default/fallback boot path.

Microsoft Windows ブートローダの場所

On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with efibootmgr or bcfg from the UEFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.

This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the .efi file in the location that Windows uses.

Copy the BOOTx64.EFI file from the Arch Linux installation medium (FSO:) to the Microsoft directory your ESP partition on your hard drive (FS1:). Do this by booting into EFI shell and typing: 

Shell> mkdir FS1:\EFI\Microsoft
Shell> mkdir FS1:\EFI\Microsoft\Boot
Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi

After reboot, any entries added to NVRAM should show up in the boot menu.

ハードウェアの変更や他のオペレーティングシステムを起動したあとにシステムが EFI シェルに入る

この記事あるいはセクションで使われている用語や表現には問題が存在します。
議論: Too GRUB-specific, most boot loader install commands have an option to install to the default/fallback boot path. Duplicates #Windows changes boot order and GRUB#Default/fallback boot path. (議論: トーク:Unified Extensible Firmware Interface#)
この記事またはセクションの正確性には問題があります。
理由: Why would booting Windows change/remove UEFI boot entries? If such an issue actually exists, it needs a reference. (議論: トーク:Unified Extensible Firmware Interface#)

EFI stores state on the motherboard, called EFIVARS. Your bootloader (e.g. GRUB) may need to set up these variables in a certain way in order to boot. If your hardware configuration changes, your motherboard is replaced, or you boot into another operating system which overwrites these variables (Windows), you may be dumped into the EFI shell or boot menu (where your device is not listed). Upon attempting to boot Arch Linux since the EFIVARS are incorrect and EFI can no longer find your bootloader.

At this point, you can use the EFI shell to find and boot your bootloader manually. Usually something like: 

Shell> ls fs0:
  EFI\
  initramfs-linux.img
  intel-ucode.img
  loader\
  vmlinuz-linux

Shell> ls fs0:EFI\
  BOOT\
  Linux\
  systemd

Shell> ls fs0:EFI\BOOT\
  BOOTx64.EFI

Shell> fs0:EFI\BOOT\BOOTx64.EFI
  Starting fs0:EFI\BOOT\BOOTx64.EFI...

To prevent booting into the EFI shell again, you can install your bootloader to the default EFI boot location. To do this with GRUB's grub-install, see GRUB#Default/fallback boot path.

There is no guaranteed success for the "Default/fallback boot path" method. Some board firmware (for example AsRock C2550D4I and C2750D4I) will search and boot the default locations on removable drives only. Booting from non removable drives (such as internal HDD, NVMe, etc.) requires fixing the efivars. For example using efibootmgr: 

# efibootmgr --create --disk /dev/nvme0n1 --label "Arch Linux" --loader /vmlinuz-linux --unicode "root=PARTUUID=cd3a4f01-035a-25e3-b1ac-ea834e75aac1 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img" --verbose

efibootmgr で作成したブートエントリが UEFI に表示されない

efibootmgr can fail to detect EDD 3.0 and as a result create unusable boot entries in NVRAM. See efibootmgr issue 86 for the details.

To work around this, when creating boot entries manually, add the -e 3 option to the efibootmgr command. E.g. 

# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose -e 3

To fix boot loader installers, like grub-install and refind-install, create a wrapper script /usr/local/bin/efibootmgr and make it executable: 

/usr/local/bin/efibootmgr
#!/bin/sh

exec /usr/bin/efibootmgr -e 3 "$@"

UEFI ブートエントリが、参照するドライブを取り外すと消える

Some firmware will remove boot entries referencing drives that are not present during boot. This could be an issue when frequently detaching/attaching drives or when booting from a removable drive.

The solution is to install the boot loader to the default/fallback boot path.

参照

「https://wiki.archlinux.jp/index.php?title=Unified_Extensible_Firmware_Interface&oldid=25914」から取得