統一可擴展固件接口(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 應用。
檢查固件位數
可以在已啟動的系統上檢查固件位數。
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 變量正常工作的需求
- 內核需通過 EFI boot stub(可選使用引導管理器)或 UEFI 引導加載程序啟動,而不是 BIOS/CSM 或者蘋果同為 CSM 的 Boot Camp 啟動。
- 內核需帶有 EFI 運行時服務支持(
CONFIG_EFI=y
,可運行zgrep CONFIG_EFI /proc/config.gz
來檢查是否滿足)。 -
不應通過內核命令行參數禁用 EFI 運行時服務,即不應使用
noefi
內核參數。 -
efivarfs
文件系統應被掛載在/sys/firmware/efi/efivars
,否則參考下文 #掛載 efivarfs 部分。 -
efivar
在使用-l
/--list
選項列出 UEFI 變量時不應出現任何報錯。
如果 EFI 變量支持在滿足以上條件後仍有問題,嘗試以下解決方案:
- 如果在列出 UEFI 變量時出現以下報錯:
efivar: error listing variables: Function not implemented
,且系統啟動到了實時內核,嘗試添加efi=runtime
到內核參數並重啟(這類內核默認會禁用 efivarfs)。 - 更多排障信息請參考 #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
更多內核文檔請參考 efivarfs.html。
用戶空間工具
有多個工具可以讀取/修改 UEFI 變量:
- efivar — 操作 UEFI 變量的庫和工具(被 efibootmgr 用到)
- efibootmgr — 操作 UEFI 固件啟動管理器設置的工具
- uefivars — 轉儲 UEFI 變量和 PCI 相關信息(內部使用 efibootmgr 源碼)
- efitools — 控制 UEFI 安全啟動平台的工具
- Ubuntu 固件測試套件 — 對 Intel/AMD 主機固件進行檢查的測試套件
efibootmgr
首先需要安裝 efibootmgr包。
- 如果 efibootmgr 完全無效,你可以重啟進入 #UEFI Shell 使用
bcfg
命令來給引導器創建一個啟動條目。 - 如果你不能使用
efibootmgr
,某些 UEFI 固件允許用戶用內建的啟動時界面管理啟動條目。例如,有些固件帶有「Add New Boot Option」選項,能讓你選擇本地 EFI 系統分區並手動輸入 EFI 應用位置(例如\EFI\refind\refind_x64.efi
)。 - 下面的命令用 rEFInd 引導器作為例子。
要通過 efibootmgr 添加新的啟動參數,需要確認:
- 包含 EFI 系統分區(ESP)的磁碟編號,例如:
/dev/sda
,/dev/nvme0n1
- ESP 分區在其硬碟上的分區編號,即
/dev/sdaY
或/dev/nvme0n1pY
中的Y
。 - 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。
\
作為路徑分隔符,不過 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 的訪問
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。
- 在 Arch 安裝媒介上的位置為
- 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
鍵來啟動。
/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 驅動是一些用於提供額外功能的軟體。例如,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 盤。
- 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,並使用 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」。
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:
- With systemctl:
$ systemctl reboot --firmware-setup
This will reboot your computer to firmware setup. - With GRUB: Press
c
for command line and in GRUB command line usefwsetup
to enter firmware setup. - In Windows: Enter Advanced Startup, see #Boot back to Arch Linux when stuck with Windows.
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 bootnumber
(bootnumber
為 Windows Boot Manager 的啟動編號)禁用 Windows Boot Manager,效果可通過不帶參數執行efibootmgr
查看。 - 或者可以在 Windows 上配置一個啟動腳本,在每次啟動 Windows 時配置正確的啟動順序:
- 使用管理員權限打開命令提示符終端,執行
bcdedit /enum firmware
並找到目標啟動項。 - 複製啟動項的標識符(包括大括號),例如
{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
- 創建一個 batch 腳本文件,內容為
bcdedit /set "{fwbootmgr}" DEFAULT "{複製來的啟動項標識符}"
- 打開 gpedit.msc,進入 Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown),選擇 Startup
- 在 Scripts 選項卡下,點擊 Add 按鈕,選擇上面創建的 batch 文件
- 使用管理員權限打開命令提示符終端,執行
- 或者也可以使用 Windows 任務管理器執行啟動腳本:
- 參照步驟 1-3 創建 batch 文件
- 執行 taskschd.msc,然後在 Action 菜單中選擇 Create Task...。
- 在 General 選項卡中:
- 輸入合適的 Name 和 Description。
- 確保選擇的管理員帳號屬於「管理員」,而不是「標準用戶」。
- 選中 "Run whether user is logged in or not"。
- 選中 "Run with highest privileges"。
- 在 Triggers 選項卡下,在菜單中選擇「At startup「,然後點擊 OK。
- 在 Actions 選項卡下,點擊 New...,Browse...,然後選擇步驟 1 創建的 batch 文件。
- 在 Conditions 選項卡下,取消選擇 Power 選項,使得在使用電池時(例如筆記本)也會執行該腳本。
- 點擊 OK,在出現提示框時輸入步驟 4 選擇的用戶帳戶的密碼。
USB 介質卡在黑屏界面
可能是 KMS 的問題,從 USB 啟動時請嘗試 禁用 KMS。
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.
參見
- 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