跳至內容
出自 Arch Linux 中文维基

統一可擴展固件接口(Unified Extensible Firmware Interface,簡稱 UEFI)是作業系統和固件之間的接口。UEFI 提供了啟動作業系統或運行預啟動程序的標準環境。

UEFI 有別於傳統 BIOS 系統所使用的 MBR 引導代碼。二者的區別和使用 UEFI 啟動的過程見 Arch 的啟動流程。要配置 UEFI 引導加載程序,請參見 Arch 的啟動流程#引導加載程序

注意:
  • 主板製造商的早期 UEFI 實現可能相比其 BIOS 版本有著更多的錯誤。如果遇到無法解決的問題,請考慮對這類系統使用傳統 BIOS 引導。
  • 蘋果的 UEFI 實現不符標準。除非特別支持,本文內容皆為通用指南,部分可能不適用或與 Mac 上的操作有所不同。

UEFI 固件位數

UEFI 下每一個程序,無論它是某個 OS 引導器還是某個內存測試或數據恢復的工具,都要兼容於 EFI 固件位數或體系結構。

無論是系統引導器還是工具(例如內存測試或數據恢復工具),UEFI 下的所有程序都是 EFI 應用,都需要兼容對應的 UEFI 固件位數或架構。

當前大部分 x86_64 架構系統(包括較新的蘋果 Mac)都使用了 x64(64 位)UEFI 固件。目前已知還在使用 IA32(32 位)UEFI 固件的有 2008 年前生產的蘋果 Mac、Intel Atom SoC 設備(截至 2013 年 11 月 2 號)[1]和一些使用 Intel EFI 1.10 固件的 Intel 伺服器主板。

與 x86_64 Linux 和 Windows 系統不同,x64 UEFI 固件不兼容 32 位 EFI 程序,所以必須針對特定固件處理器的位數和架構編譯 EFI 應用。

注意:IA32 UEFI 平台上的系統需要使用支持混合引導模式的引導加載程序

檢查固件位數

可以在已啟動的系統上檢查固件位數。

Linux 系統

在運行 Linux 4.0 及以上版本內核的發行版中,可以通過 sysfs 接口查看 UEFI 系統位數。試著運行:

$ cat /sys/firmware/efi/fw_platform_size

如果返回 64 則代表 64 位(x64) UEFI 系統,如果返回 32 則代表 32 位(IA32) UEFI 系統。如果文件不存在,那麼代表並沒有以 UEFI 模式啟動

macOS 系統

2008 年以前的 Mac 大都使用 IA32 EFI 固件,2008 年及以後大都使用 x64 EFI。有能力運行 Mac OS X Snow Leopard 64 位內核的 Mac 使用的都是 x64 EFI 1.x 版的固件。

在 Mac OS X 的終端輸入以下命令可以找出該 Mac 的 EFI 固件架構:

$ ioreg -l -p IODeviceTree | grep firmware-abi

如果命令返回 EFI32。則對應的是 IA32(32 位)EFI 固件,返回 EFI64 對應的則是 x64 EFI 固件。由於蘋果的 EFI 實現不完全符合 UEFI 2.x 標準,因此大部分 Mac 沒有 UEFI 2.x 固件。

Windows 系統

64 位的 Windows 系統不支持在 32 位 UEFI 上啟動。所以如果你在 UEFI 模式下啟動了 32 位 Windows,那麼你使用的是 32 位 UEFI。

可以通過運行 msinfo32.exe 來查看固件位數。請看系統摘要條目下「系統類型」和「BIOS 模式」對應的值。

如果是 64 位 UEFI 上的 64 位 Windows,則會顯示 系統類型:基於x64的電腦BIOS 模式:UEFI;如果是 32 位 UEFI 上的 32 位 Windows,則會顯示 系統類型:基於x86的電腦BIOS 模式:UEFI。如果「BIOS 模式」不是 UEFI,那麼 Windows 並沒有用 UEFI 模式啟動。

UEFI 變量

UEFI 定義了一些變量,作業系統可以通過它們與固件進行交互。UEFI 引導變量只在早期系統啟動時由引導加載程序和作業系統使用。UEFI 運行時變量允許作業系統管理固件的某些設置,例如 UEFI 引導管理器或 UEFI 安全啟動協議的密鑰等。你可通過下面的命令來獲得變量列表:

$ efivar -l

Linux 內核中的 UEFI 變量支持

從 3.8 版本開始,Linux 內核通過 efivarfsEFI VARiable FileSystem,EFI 變量文件系統)接口(CONFIG_EFIVAR_FS),使用 efivarfs 內核模塊將 UEFI 變量數據掛載到了 /sys/firmware/efi/efivars 下,並暴露到用戶空間。它不限制單個變量的大小,並支持 UEFI 安全啟動變量。

UEFI 變量正常工作的需求

  1. 內核需通過 EFI boot stub(可選使用引導管理器)或 UEFI 引導加載程序啟動,而不是 BIOS/CSM 或者蘋果同為 CSM 的 Boot Camp 啟動。
  2. 內核需帶有 EFI 運行時服務支持(CONFIG_EFI=y,可運行 zgrep CONFIG_EFI /proc/config.gz 來檢查是否滿足)。
  3. 不應通過內核命令行參數禁用 EFI 運行時服務,即不應使用 noefi 內核參數。
  4. efivarfs 文件系統應被掛載在 /sys/firmware/efi/efivars,否則參考下文 #掛載 efivarfs 部分。
  5. efivar 在使用 -l/--list 選項列出 UEFI 變量時不應出現任何報錯。

如果 EFI 變量支持在滿足以上條件後仍有問題,嘗試以下解決方案:

  1. 如果在列出 UEFI 變量時出現以下報錯:efivar: error listing variables: Function not implemented,且系統啟動到了實時內核,嘗試添加 efi=runtime內核參數並重啟(這類內核默認會禁用 efivarfs)。
  2. 更多排障信息請參考 #Userspace tools are unable to modify UEFI variable data

掛載 efivarfs

如果 efivarfs 啟動時並沒有被 systemd 自動掛載在 /sys/firmware/efi/efivars,你需要通過手動掛載來把 UEFI 變量暴露給類似 efibootmgr用戶空間工具

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
注意:如果適用,以上命令需要在 chroot 之外(之前)之內都執行一次。

更多內核文檔請參考 efivarfs.html

用戶空間工具

有多個工具可以讀取/修改 UEFI 變量:

  • efivar — 操作 UEFI 變量的庫和工具(被 efibootmgr 用到)
https://github.com/rhboot/efivar || efivar
  • efibootmgr — 操作 UEFI 固件啟動管理器設置的工具
https://github.com/rhboot/efibootmgr || efibootmgr
  1. uefivars — 轉儲 UEFI 變量和 PCI 相關信息(內部使用 efibootmgr 源碼)
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  1. efitools — 控制 UEFI 安全啟動平台的工具
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools
  1. Ubuntu 固件測試套件 — 對 Intel/AMD 主機固件進行檢查的測試套件
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR

efibootmgr

首先需要安裝 efibootmgr

注意:
  • 如果 efibootmgr 完全無效,你可以重啟進入 #UEFI Shell 使用 bcfg 命令來給引導器創建一個啟動條目。
  • 如果你不能使用 efibootmgr,某些 UEFI 固件允許用戶用內建的啟動時界面管理啟動條目。例如,有些固件帶有「Add New Boot Option」選項,能讓你選擇本地 EFI 系統分區並手動輸入 EFI 應用位置(例如 \EFI\refind\refind_x64.efi)。
  • 下面的命令用 rEFInd 引導器作為例子。

要通過 efibootmgr 添加新的啟動參數,需要確認:

  1. 包含 EFI 系統分區(ESP)的磁碟編號,例如:/dev/sda/dev/nvme0n1
  2. ESP 分區在其硬碟上的分區編號,即 /dev/sdaY/dev/nvme0n1pY 中的 Y
  3. EFI 程序相對 ESP 根目錄的路徑

假設要為 /efi/EFI/refind/refind_x64.efi 添加啟動項,其中 /efi 是 ESP 的掛載目錄,需要執行:

$ findmnt /efi
TARGET SOURCE    FSTYPE OPTIONS
/efi   /dev/sda1 vfat   rw,flush,tz=UTC

在以上示例中,findmnt(8) 指出 /dev/sda 上 ESP 分區的編號為 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 --unicode

如需配置啟動順序,使用:

# efibootmgr --bootorder XXXX,XXXX --unicode

其中 XXXX 是上述 efibootmgr 命令輸出顯示的數字。

如需刪除不需要的啟動項,使用:

# efibootmgr --delete-bootnum --bootnum XXXX --unicode

更多信息請參考 efibootmgr(8)efibootmgr README

注意:UEFI 標準使用反斜槓 \ 作為路徑分隔符,不過 efibootmgr 會自動把 UNIX 的 / 路徑分隔符轉換為 \

禁止訪問 UEFI 變量

UEFI 變量訪問有可能會導致超出系統範圍的破壞。有些 UEFI 漏洞(例如 LogoFAIL)會讓黑客獲得系統的完整權限,在有些不完善的 UEFI 實現中甚至能導致硬體故障[2]

因此,鑑於日常使用系統時不會訪問 UEFI 變量,可以選擇將其禁用,以防止潛在安全漏洞和誤操作產生破壞。

可選方法有:

  • 使用 fstab 以只讀模式掛載 efivars,例如:
    efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
  • 使用 noefi 內核參數完全禁用系統對 UEFI 的訪問
注意:禁用後將無法使用 UEFI 用戶空間工具,因此需要在進行前完成所有必要配置。另外,UEFI 相關命令也將無法使用(例如 systemctl reboot --firmware-setup)。

UEFI Shell

UEFI Shell 是一個用於固件的命令行終端,可用於啟動如 UEFI 引導器等 EFI 程序。除此之外,它還可用於採集固件和系統的各種信息,例如內存映射(memmap),修改啟動管理器變量(bcfg),運行分區程序(diskpart),加載 UEFI 驅動,編輯文本文件(edit),十六進制編輯等等。

獲取 UEFI Shell

可以從 TianoCore EDK2 項目獲取到以 BSD 許可證發布的 UEFI Shell:

你可從 Intel 的 Tianocore UDK/EDK2 Sourceforge.net 工程下載以 BSD 許可證發布的 UEFI Shell.

  • Shell v2:
    • 在 Arch 安裝媒介上的位置為 /shellx64.efi,在構建 ISO 時從 /usr/share/edk2-shell/x64/Shell_Full.efi 複製而來。
    • edk2-shell - 從 TianoCore EDK2 最新版本編譯而來,為 x64(64 位)UEFI 提供了 x64 Shell,以及為 IA32(32 位)UEFI 提供了 IA32 Shell。
    • uefi-shell-gitAUR - 從 TianoCore EDK2 最新源碼編譯而來,為 x64(64 位)UEFI 提供了 x64 Shell,以及為 IA32(32 位)UEFI 提供了 IA32 Shell。
  • Shell v1:
  • 打過補丁的 shells:

Shell v2 在 UEFI 2.3+ 系統上表現最好,在這些系統上建議使用 v2 版本。Shell v1 應在所有 UEFI 系統上都可用,與固件遵循的 UEFI 標準無關。更多信息請參考 ShellPkg 和 EDK2 郵件清單 - Inclusion of UEFI shell in Linux distro iso

啟動 UEFI Shell

從 Sandy Bridge 開始,少數華碩和其它使用 AMI Aptio x64 UEFI 固件的主板提供了一個叫做 Launch EFI Shell from filesystem device 的選項。對於這些主板,需要將 x64 UEFI Shell 複製到 EFI 系統分區的根目錄下,並重命名為 shellx64.efi

提示:
  • Arch Linux 安裝媒介的根目錄包含 shellx64.efi
  • 如果 EFI 系統分區的根目錄下存在 shellx64.efi,那麼 rEFIndsystemd-boot 會自動為其添加啟動項。

Phoenix SecureCore Tiano UEFI 固件已內嵌 UEFI Shell, 可按 F6, F11F12 鍵來啟動。

注意:如果你用以上方法不能啟動 UEFI Shell,可以創建一個 FAT32 格式的 U 盤,並把 EFI 二進制文件複製到 /U_盤掛載點/EFI/BOOT/BOOTx64.EFI。這個 U 盤將會出現在固件的啟動菜單裡,啟動它就會啟動到 UEFI Shell。

重要 UEFI Shell 命令

UEFI Shell 命令通常支持 -b 選項,它會在輸出的每頁末尾暫停。運行 help -b 可以列出所有可用命令,這些命令都是內置在 shell 或單獨的 EFI 應用中。

詳細信息請參考 Intel 腳本編寫指南 2008[失效連結 2023-07-30 ⓘ]Intel「教程」2011[失效連結 2023-07-30 ⓘ]

bcfg

bcfg 命令用於修改 UEFI NVRAM 條目,它能讓用戶改變啟動條目或驅動器選項,在UEFI Shell Specification 2.2 PDF 文檔的 96 頁(Section 5.3) 有詳細說明。

注意:
  • 僅當 efibootmgr 無法創建啟動條目時才推薦嘗試 bcfg
  • UEFI Shell v1 官方二進制文件不支持 bcfg 命令,可以參考#獲取 UEFI Shell下載一個修改過的 UEFI Shell v2 二進制文件,有可能在 UEFI 2.3 版本前的固件上可用。

轉儲當前啟動條目:

Shell> bcfg boot dump -v

以為 rEFInd 為例,將其添加為第 4 個(從 0 開始計數)啟動項:

Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"

其中 FS0: 是 EFI 系統分區映射到的路徑,FS0:\EFI\refind\refind_x64.efi 是要啟動的文件。

To add an entry to boot directly into your system without a boot loader, see EFI boot stub#bcfg.

刪除第 4 個啟動選項:

Shell> bcfg boot rm 3

把第 3 個啟動選項移動到第 0 個(也就是第 1 個選項,是 UEFI 啟動菜單的默認啟動選項):

Shell> bcfg boot mv 3 0

bcfg 幫助信息:

Shell> help bcfg -v -b

或:

Shell> bcfg -? -v -b

map

map displays a list of device mappings i.e. the names of available file systems (FS0) and storage devices (blk0).

Before running file system commands such as cd or ls, you need to change the shell to the appropriate file system by typing its name:

Shell> FS0:
FS0:\> cd EFI/

edit

edit 命令提供了類似於 nano 界面的基本編輯器,但是功能略少一點。它以 UTF-8 編碼,並且兼容 LF 和 CRLF 行尾結束符。

本例中,編輯在固件 EFI 系統分區 (fs0: 中 rEFInd 的 refind.conf

Shell> edit FS0:\EFI\refind\refind.conf

按下 Ctrl+e 可顯示幫助信息。

UEFI 驅動

這篇文章的某些內容需要擴充。

原因:解釋 UEFI 驅動是什麼及如何使用;添加 efibootmgr 使用 -r/--driver 選項自動加載 UEFI 驅動的方法 (在 Talk:UEFI 中討論)

UEFI 驅動是一些用於提供額外功能的軟體。例如,UEFI shell 通常無法訪問 NTFS 格式的分區,而 efifs 提供了從 EFI shell 訪問多種文件系統讀取文件的驅動。其中一種用法是先將驅動複製到 UEFI shell 能訪問的分區,然後在 UEFI shell 中執行如下命令:

Shell> load ntfs_x64.efi
Shell> map -r

執行命令後,用戶就可以在 UEFI shell 中訪問 NTFS 格式的分區。

提示:
  • systemd-boot 會自動從 esp/EFI/systemd/drivers/ 加載 UEFI 驅動。
  • rEFInd 會自動從其 ESP 下的安裝目錄中的 driversdrivers_x64 子目錄加載 UEFI 驅動,例如 esp/EFI/refind/drivers_x64/。可以配置掃描更多其它目錄。

UEFI 可啟動介質

從光學介質裡移除 UEFI 啟動支持

注意:
  • 本部分內容為從僅 CD/DVD(利用 EL Torito 的光學介質啟動)介質移除 UEFI 啟動支持,而不是 U 盤。
  • In order to hide the UEFI equipment on USB stick, use a partition editor after having copied the ISO to the flash drive. Remove the partition of type EF. Do not accept offers to convert to GPT.

大部分 32 位 EFI Mac 和部分 64 位 EFI Mac 無法從 UEFI(X64)+ BIOS 可啟動 CD/DVD 啟動。如果希望使用光學介質完成安裝,可能首先需要移除 UEFI 啟動支持。

提取 ISO 內容,並跳過 UEFI 特定目錄:

$ mkdir extracted_iso
$ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-version-x86_64.iso -C extracted_iso

Be sure to set the correct volume label, e.g. ARCH_202103; it can be acquired using file(1) on the original ISO. 然後重新構建 ISO,並使用 libisoburnxorriso(1) 移除 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 包含了一個 UEFI 固件示例,和單獨一個用於 QEMU 的非易失性變量存儲。

可以從 extra 倉庫安裝 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 是一個 TianoCore 項目,使得可以從 BIOS 設備連鎖啟動到完整 UEFI 環境,與 BIOS 作業系統啟動類似。該方法在這裡有廣泛討論。預構建的 DUET 可以從代碼庫[失效連結 2023-04-07 ⓘ]下載,使用指南請參考這裡[失效連結 2023-04-07 ⓘ]。然而,從 2018 年 11 月開始,DUET 代碼庫已被從 TianoCore git 倉庫移除。

也可考慮 Clover,它提供的 DUET 鏡像可能包含了一些系統的專用補丁,並且比 gitlab 源更新得更頻繁。

疑難問題

困在 Windows 時啟動到 Arch Linux

當被困在 Windows 時,要啟動到 Arch Linux,可以通過 Windows PowerShell 命令 shutdown /r /o 進入 高級啟動,或是通過設置 > 更新與安全 > 恢復 > 高級啟動,選擇現在重啟。當你進入高級啟動菜單時,選擇使用設備(該項中為 UEFI 啟動項,包括 U 盤,CD 或硬碟上的作業系統),並選擇「Arch Linux」。

Enter firmware setup without function keys

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:

Userspace tools are unable to modify UEFI variable data

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.

Cannot create a new boot entry with 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.

Windows 改變了啟動次序

如果你使用 Arch + Windows 雙系統,且主板直接啟動到了 Windows,沒有出現 EFI 應用選擇菜單,那麼有多個可能的原因和解決方案。

  • 確保 Windows 電源選項中的 「快速啟動」選項已禁用
  • 如果引導管理器沒有簽名過,請確保固件中的 安全啟動選項已禁用
  • 確保 Windows Boot Manager 不是 UEFI 啟動首項,可以使用 efibootmgr 或查看 UEFI 配置工具中的信息。有些主板會默認覆蓋掉 Windows 通過 efibootmgr 做出的任何修改(例如 Packard Bell 筆記本)。
  • 如果你的主板啟動到了默認啟動路徑(\EFI\BOOT\BOOTx64.EFI),那麼該文件有可能會被 Windows boot loader 覆寫。請嘗試使用 efibootmgr 配置正確的啟動路徑。
  • 如果以上步驟無效,還可以直接讓 Windows boot loader 運行其它 EFI 應用。進入 Windows 管理員提示符終端,執行 bcdedit /set "{bootmgr}" path "\EFI\path\to\app.efi"
  • 或者,以根用戶權限執行 efibootmgr -A -b bootnumberbootnumber 為 Windows Boot Manager 的啟動編號)禁用 Windows Boot Manager,效果可通過不帶參數執行 efibootmgr 查看。
  • 或者可以在 Windows 上配置一個啟動腳本,在每次啟動 Windows 時配置正確的啟動順序:
    1. 使用管理員權限打開命令提示符終端,執行 bcdedit /enum firmware 並找到目標啟動項。
    2. 複製啟動項的標識符(包括大括號),例如 {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
    3. 創建一個 batch 腳本文件,內容為 bcdedit /set "{fwbootmgr}" DEFAULT "{複製來的啟動項標識符}"
    4. 打開 gpedit.msc,進入 Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown),選擇 Startup
    5. Scripts 選項卡下,點擊 Add 按鈕,選擇上面創建的 batch 文件
注意:Windows 10 家庭版默認不包含 gpedit.msc,但有非官方方法可以手動進行安裝。
  • 或者也可以使用 Windows 任務管理器執行啟動腳本:
    1. 參照步驟 1-3 創建 batch 文件
    2. 執行 taskschd.msc,然後在 Action 菜單中選擇 Create Task...
    3. General 選項卡中:
      輸入合適的 NameDescription
      確保選擇的管理員帳號屬於「管理員」,而不是「標準用戶」。
      選中 "Run whether user is logged in or not"。
      選中 "Run with highest privileges"。
    4. Triggers 選項卡下,在菜單中選擇「At startup「,然後點擊 OK
    5. Actions 選項卡下,點擊 New...Browse...,然後選擇步驟 1 創建的 batch 文件。
    6. Conditions 選項卡下,取消選擇 Power 選項,使得在使用電池時(例如筆記本)也會執行該腳本。
    7. 點擊 OK,在出現提示框時輸入步驟 4 選擇的用戶帳戶的密碼。

USB 介質卡在黑屏界面

可能是 KMS 的問題,從 USB 啟動時請嘗試 禁用 KMS

UEFI boot loader does not show up in firmware menu

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.

適用於可移除硬碟的默認啟動路徑

UEFI 標準規定了從可移除媒介啟動時的默認 EFI 二進制文件路徑:

  • x64 UEFI 固件 - esp/EFI/BOOT/BOOTx64.EFI
  • IA32 UEFI 固件 - esp/EFI/BOOT/BOOTIA32.EFI

雖然標準只針對了可移除硬碟,但大多數固件都支持從任意硬碟啟動。

關於如何安裝或從引導加載器遷移到默認/後備啟動路徑的信息,請參考對應的引導加載程序文章。

Microsoft Windows boot loader location

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.

UEFI/BIOS is stuck on loading screen

This is a recurring problem with Acer laptops, which occurs if .efi files have not been manually authorized. See Laptop/Acer#Firmware Setup became inaccessible after Linux installation.

Boot entries created with efibootmgr fail to show up in 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' --unicode -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 boot entry disappears after removing its referenced drive

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.

Boot entries are randomly removed

Some motherboards may remove boot entries due to lack of free space in the NVRAM instead of giving an error at creation. To prevent this from occurring, reduce the amount of boot entries being added by minimizing your entry creation process, as well as reducing the amount of automatic drive boot entries by the Compatibility Support Module (CSM) by disabling it from your UEFI settings. See BBS#1608838.

Another reason why boot entries might have been removed is the fact that UEFI specification allows OEMs to do "NVRAM maintenance" during boot process. Those manufacturers do it simply: they just look up for EFI applications in predefined, hardcoded paths on the device. If they fail to find any, they conclude there is no operating system on the device and wipe all boot entries from NVRAM associated with it, because they assume the NVRAM contains some corrupted or outdated data. If you do not plan to install Windows and still want to load the Linux kernel directly from the firmware, one possible workaround is to create an empty file esp/EFI/BOOT/BOOTx64.EFI:

# mkdir -p esp/EFI/BOOT 
# touch esp/EFI/BOOT/BOOTx64.EFI

And restore the deleted boot entry. Now after reboot the motherboard will see the "Fake OS" and should not wipe other boot entries from NVRAM. You can change the fake operating system loader with an actual EFI application if you want, of course, as long as you keep the standard fallback name.

參見