UEFI - Arch Linux 中文维基

跳至內容

# UEFI

出自 Arch Linux 中文维基
翻譯狀態：

- 本文（或部分內容）譯自 Unified Extensible Firmware Interface，最近一次同步於 2026-02-07，若英文版本有所更改，則您可以幫助同步與翻譯更改的內容。
- 您可以在 ArchWiki 的對應頁面找到本文翻譯的原始修訂歷史。
- 本文可能與英文原文存在出入。

相關文章

- EFI 系統分區
- GUID 分區表
- 安全啟動
- 統一內核映像

統一可擴展固件接口（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 內核通過 efivarfs（EFI VARiable FileSystem，EFI 變量文件系統）接口（`CONFIG_EFIVAR_FS`），使用 `efivarfs` 內核模塊將 UEFI 變量數據掛載到了 `/sys/firmware/efi/efivars` 下，並暴露到用戶空間。它不限制單個變量的大小，並支持 UEFI 安全啟動變量。

### UEFI 變量正常工作的需求

1. 內核需通過 EFI boot stub（可選使用引導管理器）或 UEFI 引導加載程序啟動，而不是 BIOS/CSM（Compatibility Support Module，兼容性支持模塊）或者蘋果同為 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

- QEFI 啟動項管理器 — 這是一個基於 Qt 的圖形界面應用，用於管理 EFI 啟動項和 EFI 系統分區

  https://github.com/Inokinoki/QEFIEntryManager || qefientrymanagerAUR

#### 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：
  - 源自 TianoCore 的預編譯 UEFI Shell v1 二進制文件（從 2014 年 1 月 10 號開始上游就不再更新）。
- 打過補丁的 shells：
  - 源自 Clover EFI 啟動引導器的預編譯 UEFI Shell v2 二進制文件[失效連結 2023-07-30 ⓘ]，修改了 bcfg 以與 UEFI pre-2.3 固件配合使用。
  - 源自 OpenCore 啟動引導器的預編譯 UEFI Shell v2 二進制文件，與大量固件兼容，可從發布包中的 `EFI/OC/Tools/OpenShell.efi` 位置獲取。

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`，那麼 rEFInd 和 systemd-boot 會自動為其添加啟動項。

Phoenix SecureCore Tiano UEFI 固件已內嵌 UEFI Shell, 可按 `F6`, `F11` 或 `F12` 鍵來啟動。

注意：如果你用以上方法不能啟動 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` 是要啟動的文件。

如需添加直接啟動到系統而非通過引導加載器的條目，參見 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` 顯示設備的映射列表，即可用的文件系統（`FS0`）和存儲設備（`blk0`）

在執行 `cd` 或 `ls` 等文件系統命令前，你需要輸入其名稱來進入相應的文件系統。

    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 下的安裝目錄中的 `drivers` 和 `drivers_x64` 子目錄加載 UEFI 驅動，例如 `esp/EFI/refind/drivers_x64/`。可以配置掃描更多其它目錄。

## UEFI 可啟動介質

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

注意：

- 本部分內容為從僅 CD/DVD（利用 EL Torito 的光學介質啟動）介質移除 UEFI 啟動支持，而不是 U 盤。
- 為了隱藏USB啟動盤上的 UEFI 設備，在將 ISO 文件複製到快閃記憶體驅動器後，使用分區編輯器。刪除類型為 `EF` 的分區。切勿接受轉換為 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

確保已經設置了正確的卷標，比如`ARCH_202103`; 可以在原 ISO 中運行 file(1) 獲得。然後重新構建 ISO，並使用 libisoburn包 的 xorriso(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」。

### 無法使用熱鍵進入固件設置

在一些筆記本電腦上，比如聯想小新15are 2020，按 F2 或 F12 等按鍵可能沒有任何反應。這種情況有可能通過返廠讓OEM修復主板信息來解決，但有時這既不可能也不被希望。不過，還有其他方法可以進入固件設置：

- 使用 systemctl:

      $ systemctl reboot --firmware-setup

  這會讓電腦重啟到固件。
- 使用 GRUB: 按 `c` 進入 GRUB 命令行並輸入 `fwsetup`
- 在 Windows 中進入: 使用 Windows 高級重啟，參見 #Boot back to Arch Linux when stuck with Windows.

### 用戶空間工具無法修改 UEFI 變量

如果任何用戶空間工具無法修改 UEFI 變量，檢查是否存在 /sys/firmware/efi/efivars/dump-* 文件。如果這些文件存在，刪除它們，重啟後再嘗試。如果上述步驟無法解決問題，嘗試使用內核參數 `efi_no_storage_paranoia` 啟動系統，以禁用內核對UEFI變量存儲空間的檢查，這種檢查可能會阻止對 UEFI 變量的寫入或修改。

警告：`efi_no_storage_paranoia` 應僅在必要時使用，不應作為正常的啟動選項保留。該內核命令行參數的作用是關閉一個保護機制，該機制旨在防止當 NVRAM 過滿時導致設備變磚。更多信息請參見 FS#34641。

### efibootmgr 無法創建啟動條目

某些內核與 efibootmgr 版本組合可能會拒絕創建新的啟動項。這可能是 NVRAM 空間不足所致。你可以嘗試章節 #Userspace tools are unable to modify UEFI variable data 中提供的解決方案。

你也可以嘗試將 efibootmgr downgrade 到版本0.11.0。該版本兼容 Linux 內核 4.0.6。更多信息請參見錯誤討論 FS#34641，尤其是 closing comment 。

### 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 bootnumber`（`bootnumber` 為 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 選項卡中：
       輸入合適的 Name 和 Description。
       確保選擇的管理員帳號屬於「管理員」，而不是「標準用戶」。
       選中 "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。

### 固件中不顯示引導加載器

有些固件不支持自定義啟動項，它們只會從硬編碼的啟動項啟動。

一種常見的解決方法是不依賴NVRAM中的啟動項，而是將引導加載程序安裝到EFI系統分區上的常見回退路徑之一。

以下章節將介紹這些回退路徑。

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

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.

### Lenovo ThinkPad: boot entries not persistent due to "OS Optimized Defaults"

本文或本章節可能需要合併到Lenovo。

附註： Brand-specific issues should be on the dedicated page.（在 Talk:UEFI 中討論）

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

原因：Missing links to the "user reports". (在 Talk:UEFI 中討論)

On recent Lenovo ThinkPad laptops (e.g. T16 Gen 2 AMD models), users report that custom UEFI boot entries (created with `efibootmgr` or `bootctl`) are automatically deleted at each boot, with only Windows Boot Manager and Lenovo’s own entries (PXE, Recovery, Diagnostics) restored.

This is caused by the BIOS option "Restart / OS Optimized Defaults", which resets the UEFI boot variables at each reboot to defaults optimized for Windows.

Solution: Disable "OS Optimized Defaults" in the BIOS/UEFI setup. After doing so, manually created boot entries persist correctly, allowing systemd-boot or other custom boot managers to work as intended.

## 參見

- UEFI Forum - contains the official UEFI Specifications - GUID Partition Table is part of UEFI Specification
- UEFI boot: how does that actually work, then? - A blog post by AdamW
- Linux Kernel UEFI documentation for x86_64 platforms
- Intel's page on EFI
- Intel Architecture Firmware Resource Center[失效連結 2023-07-30 ⓘ]
- Matt Fleming - The Linux EFI Boot Stub
- Matt Fleming - Accessing UEFI Variables from Linux
- Rod Smith - Linux on UEFI: A Quick Installation Guide
- UEFI Boot problems on some newer machines (LKML)
- LPC 2012 Plumbing UEFI into Linux[失效連結 2021-05-17 ⓘ]
- LPC 2012 UEFI Tutorial : part 1[失效連結 2021-05-17 ⓘ]
- LPC 2012 UEFI Tutorial : part 2[失效連結 2021-05-17 ⓘ]
- Intel's TianoCore Project for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
- FGA: The EFI boot process
- Microsoft's Windows and GPT FAQ
- Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall
- Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive
- Rod Smith - A BIOS to UEFI Transformation
- EFI Shells and Scripting - Intel Documentation
- UEFI Shell - Intel Documentation
- UEFI Shell - bcfg command info
- The bootstrap process on EFI systems

分類：​

- 啟動過程
- 包含失效連結的頁面

隱藏分類：​

- 使用「模板:合併」標記的頁面或章節

UEFI
新增話題