UEFI 何時以及為何需要訪問分區表?
我有一個帶有
UEFI
韌體的工作站和一個帶有GPT
類型分區表的磁碟。根據 EFI Boot Manager,系統被指示從 UUID 引導7e169454-1df0-40bf-9c63-0f6b094c1e15
:# efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* debian HD(1,GPT,7e169454-1df0-40bf-9c63-0f6b094c1e15,0x800,0xee000)/File(\EFI\debian\grubx64.efi) #
7e169454-1df0-40bf-9c63-0f6b094c1e15
是帶有文件系統的/dev/sdb
磁碟的第一個分區:FAT32
# blkid /dev/sdb1 /dev/sdb1: UUID="DA79-BCEA" TYPE="vfat" PARTUUID="7e169454-1df0-40bf-9c63-0f6b094c1e15" #
根據這個 UEFI 指南,UEFI 規範要求 UEFI 能夠讀取 (
GPT
) 分區表。是否僅在安裝/編輯 EFI 引導管理器期間需要?據我了解,efibootmgr
將分區的起始扇區和結束扇區添加到 EFI 引導管理器條目。例如,根據上面的範例,我的 EFI 引導管理器條目包含0x800
(2048
十進制) 和0xee000
(974848
十進制),它們與 顯示的開始和結束扇區匹配,fdisk
它們從以下位置讀取GPT
:# fdisk /dev/sdb Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): i Partition number (1-4, default 4): 1 Device: /dev/sdb1 Start: 2048 End: 976895 Sectors: 974848 Size: 476M Type: EFI System Type-UUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B UUID: 7E169454-1DF0-40BF-9C63-0F6B094C1E15
是否
UEFI
需要訪問分區表才能使用開始和結束扇區資訊填充 EFI 引導管理器?或者可能
UEFI
需要在每次啟動期間訪問分區表,因為它需要找到匹配的分區UUID
?如果我正確理解了本UEFI
指南,那麼在啟動過程UEFI
中將不按特定順序初始化每個外圍設備,直到找到與UUID
. 所以在我的例子中,它會7e169454-1df0-40bf-9c63-0f6b094c1e15
從 EFI 引導管理器中讀取,然後遍歷每個塊設備並讀取它們的 GPT,直到7e169454-1df0-40bf-9c63-0f6b094c1e15
找到分區?
根據這個 UEFI 指南,UEFI 規範要求 UEFI 能夠讀取(GPT)分區表。
這是規範要求,因此這意味著雖然特定 UEFI 韌體實現也可能支持其他分區表格式,但每個UEFI 實現也必須支持 GPT 才能符合規範。因此,PC 硬體上的 UEFI 實現通常也支持經典的 MBR 分區,至少足以辨識它。蘋果的 UEFI 實現也可能支持蘋果自己的舊分區方案,Oracle/Sun UEFI 也可能理解 Solaris VTOC 磁碟標籤,等等。
是否僅在安裝/編輯 EFI 引導管理器期間需要?
EFI 引導管理器內置於 UEFI 韌體中。你永遠不會“安裝”它。使用該
efibootmgr
命令,您可以編輯儲存在主機板上的非易失性儲存器 (NVRAM) 中的參數。UEFI 韌體需要能夠在每次啟動時讀取 GPT 分區表,除非系統已使用特定 UEFI 實現支持的替代分區表格式安裝。
HD(1,GPT,7e169454-1df0-40bf-9c63-0f6b094c1e15,0x800,0xee000)
輸出中的字元串efibootmgr
不僅僅是任何字元串:它是UEFI硬碟驅動器媒體設備路徑資料結構的簡明人類可讀表示。該資料結構是數據實際儲存在 EFI 引導管理器的 NVRAM 中的方式。UEFI 規範說(我強調並分成幾段):
引導管理器還必須支持從以硬碟驅動器媒體設備路徑的第一個元素開始的短格式設備路徑引導(參見表 77)。引導管理器必須使用硬碟驅動器設備路徑中的 GUID 或簽名和分區號,以將其與系統中的設備相匹配。
如果驅動器支持 GPT 分區方案,則將硬碟驅動器媒體設備路徑中的 GUID 與 GUID 分區條目的欄位進行比較
UniquePartitionGuid
(參見表 18)。如果驅動器支持 PC-AT MBR 方案,則將硬碟驅動器媒體設備路徑中的簽名與UniqueMBRSignature
Legacy Master Boot Record 中的簽名進行比較(參見表 13)。如果進行了簽名匹配,則分區號也必須匹配。可以將硬碟驅動器設備路徑附加到匹配的硬體設備路徑,然後可以使用正常的引導行為。如果多個設備與硬碟驅動器設備路徑匹配,則引導管理器將任意選擇一個。因此,作業系統必須確保硬碟驅動器上簽名的唯一性,以保證確定的引導行為。
所以分區唯一UUID的匹配是主要機制。開始和結束扇區資訊只是為了提供冗餘:任何 UEFI 實現都可以自由使用或忽略它。
UEFI 韌體可能會使用開始和結束扇區資訊來進一步檢查 NVRAM 資訊和磁碟內容是否相互匹配。如果磁碟的分區表似乎已損壞,它還允許韌體嘗試按位置查找 ESP 分區,從而使系統能夠更強大地防止數據錯誤。每個 UEFI 韌體實施者都可以自行決定是否要使用這些額外資訊,如果他們願意,他們的總體策略是什麼。
具有安全意識的 UEFI 實現可能會停止引導過程並報告任何差異的錯誤,而為最大可靠性而設計的實現可能會在失敗之前嘗試冗餘資訊的所有組合,以最大限度地解決任一錯誤的機會。 NVRAM 或分區表。如果它未能找到匹配的簽名並完全忽略額外資訊,則極簡 UEFI 實現可能會停止並顯示錯誤消息。
如果您想更好地了解 UEFI 及其功能,您應該嘗試使用 UEFI shell。一些 UEFI 實現(例如 Intel 或 Phoenix)將其作為內置的;
shellx64.efi
如果將文件添加到 ESP(EFI 系統分區)的根目錄,則其他人(由 AMI 提供)具有執行文件的特定選項。如果一切都失敗了,您始終可以.efi
將 shell 文件放到您的 ESP 上,並使用efibootmgr
它來將其配置為 EFI 引導管理器中的附加引導菜單項。在撰寫本文時,TianoCore 項目提供的 UEFI shell 的最新預編譯版本似乎位於: https ://github.com/tianocore/edk2/releases/download/edk2-stable201911/ShellBinPkg.zip