安裝後啟動 CentOS 時，是什麼導致我的 EFI 分區損壞？
我正在嘗試在小型 PC ASUS Eee Box EB1037上安裝最新的 CentOS 7.5 x64 。它是帶有板載 NVIDIA GeForce GT 820M的Intel Celeron J1900 （Bay Trail）。除非首先禁用 Nouveau，否則安裝媒體將鎖定。這可以。但在安裝和隨後的重新啟動後，EFI 分區似乎已損壞。
這個問題不是關於如何引導故障排除，而是理解為什麼這個引導失敗會破壞 EFI 分區並導致 GRUB 失敗。
下面是安裝過程：
- 將 CentOS 7.5 刻錄到 USB
- 引導至 USB 安裝程序（grub 引導載入程序）
- 編輯 grub 選項以添加“nouveau.modeset=0”
- 設置時區
- 軟體選擇：最小安裝（無更改）
- 網路和主機名：設置主機名
- 將手動分區設置為“標準分區”（無 LVM）和自動分區佈局
- 安裝繼續
- 設置root密碼和使用者帳戶（作為管理員）
- 安裝完成
- 重啟
- 硬碟GRUB出現
我沒有更改任何 GRUB 設置（例如禁用 Nouveau）。在此處查看預設設置：
嘗試使用這些預設值啟動 CentOS，它按預期掛起（因為我沒有禁用 Nouveau）。我所能看到的只是一個黑屏。顯示器已打開，但鍵盤指示燈和背光以及光學滑鼠 LED 均已關閉。鍵盤對 ctrl-alt-del 不負責任。
按住電源按鈕執行硬重置。系統第二次啟動到硬碟 GRUB 菜單，沒有問題。嘗試再次使用預設值啟動，它鎖定和以前一樣（正如預期的那樣，因為我還沒有禁用 Nouveau）。
請注意，我仍然插入了 CentOS USB 安裝程序。在第三次重新啟動後（在前兩次安裝後重新啟動之後），系統將我帶到 USB GRUB 而不是硬碟之一。奇怪的。彈出 CentOS USB 並使用 ctrl-alt-del 重新啟動。
現在我在螢幕上看到一條來自 GRUB flash 的消息，簡要指出它無法讀取 EFI 分區：
片刻之後它消失了，我看到了這個：
系統現在不再可引導至 EFI 分區。
為什麼會這樣？EFI 分區是如何損壞的？
附加資訊
Secure Boot 在 BIOS 中已啟用，無法禁用，但設置為“Other OS”。
設備內部只有一個 SATA 埠，由三星 850 Pro 500GB SSD 填充。儘管設置為 AHCI 並且顯示為 SATA1 並且是唯一連接到系統的磁碟，但 CentOS 將其辨識為
sdb而不是sda，可能是因為它認為 USB 安裝介質是sda. 但是，它不會在安裝過程中將 USB 驅動器顯示為第二個磁碟，而是將三星 SSD 顯示為唯一可見的驅動器。
GRUB 將附加的 CentOS 安裝 USB 媒體視為 (hd0)，將板載 SATA 視為 (hd1)，當兩者都插入時。當 USB 介質被移除時，板載 SATA 被視為 (hd0)。
sd有趣的是，板載 SATA 被CentOS 安裝程序視為，但hd被 GRUB 視為。
強調
- 系統有一個 Nvidia 圖形處理器（擎天柱？）
- 安全啟動已啟用（無法禁用）
- BIOS 將 USB 磁碟顯示為附加的 SATA 磁碟？（
sda在安裝期間，hd0在 GRUB 中）請注意
nouveau.modeset=0在安裝、設置和更新 GRUB 之後，我已經可以通過移除 U 盤來啟動系統/boot/efi/EFI/centos/grub.cfg。問題是要了解是什麼破壞了 EFI 分區！
系統啟動照片：
這個名字
\EFI\BOOT\grubx64.efi告訴我係統沒有使用 CentOS 預設的 UEFI 引導路徑，而是回退路徑。但是備份引導路徑是\EFI\BOOT\bootx64.efi，它將被 SecureBoot shim 佔用。所以看起來填充程序已載入，但它無法執行下一步：從備用目錄載入實際的 GRUB 引導載入程序。我的理論：
- 安裝以通常的方式設置引導載入程序：
\EFI\CentOS\shimx64.efi是 SecureBoot 墊片引導載入程序，並且\EFI\CentOS\grubx64.efi是實際的 GRUB 引導載入程序。該路徑\EFI\CentOS\shimx64.efi已註冊到 UEFI NVRAM 引導變數中。安裝程序還（嘗試）在預設備份/可移動媒體引導路徑中使用 shim 設置第二個副本，\EFI\BOOT\bootx64.efi並將 GRUB 設置為\EFI\BOOT\grubx64.efi.- 在安裝程序觸發的第一次重啟中，NVRAM 啟動變數完好無損，韌體執行了“熱重啟”，使用
\EFI\CentOS\shimx64.efi和成功啟動核心\EFI\CentOS\grubx64.efi。此引導嘗試隨後導致掛起，因為 Nouveau 未被禁用。- 然後，某些原因導致韌體忘記了 NVRAM 引導變數，從而導致系統嘗試從備用路徑引導
\EFI\BOOT\bootx64.efi。當您告訴 UEFI 從特定磁碟引導但未指定引導載入程序路徑時，就會發生這種情況。出於某種原因，這允許載入 SecureBoot shim 的備份副本，但隨後載入失敗\EFI\BOOT\grubx64.efi。請注意，它並不是說文件已損壞：它只是說該文件不存在。現在，您可能應該使用
efibootmgr -v查看目前存在的 UEFI 啟動變數，並記下目前的設置，或者至少是 CentOS 啟動條目，以便在它再次失去時能夠重現它。在這種情況下，您可以從 CentOS 安裝媒體啟動進入救援模式並使用efibootmgr命令來修復 NVRAM 變數，或者如果允許，也可以使用 UEFI“啟動設置”菜單輸入正確的設置。（遺憾的是，我見過的大多數 UEFI 實現都不會。）您還應該驗證備用 GRUB 引導載入程序是否完好無損。該文件應該可以像
/boot/efi/EFI/BOOT/grubx64.efi在 Linux 中一樣訪問。驗證文件是否存在並且與/boot/efi/EFI/CentOS/grubx64.efi.我真的不知道是什麼導致 UEFI NVRAM 引導變數在第一次重新啟動和第三次重新啟動之間失去。那裡有各種錯誤的 UEFI 實現。或者您是否可能重置了“BIOS 設置”作為對原來由 Nouveau 引起的掛起進行故障排除的一部分？重置 UEFI“BIOS 設置”可能也可能不會重置 NVRAM 引導變數，具體取決於 UEFI 實現。
如果發現 UEFI NVRAM 引導變數偶爾失去是韌體錯誤，您可能會檢查 BIOS 升級：執行
dmidecode -s bios-version以查看目前版本。根據華碩支持頁面，適用於您系統的最新 UEFI BIOS 版本為 1301。華碩通常在 UEFI BIOS 本身中包含更新功能；如果在您的系統上是這樣，您只需將更新文件保存到 EFI 系統分區（=/boot/efiCentOS 中的任何位置），進入 BIOS 設置，從那裡啟動更新工具，並告訴它更新文件在哪裡。NVRAM 損壞的一個可能原因是
efi-pstore核心模組。如果它被啟用（或內置在 CentOS 標準核心中）並且在pstore核心恐慌時儲存核心日誌的功能處於活動狀態，這可能已經用一系列包含核心日誌的變數填充 NVRAM 到 100%。這可能導致韌體將變數儲存檢測為損壞並自動重新初始化 NVRAM 引導變數。如果回退
/boot/efi/EFI/BOOT/grubx64.efi實際上沒有損壞，則無法從回退路徑引導可能是由 SecureBoot shim 中的錯誤引起的，或者是由於在 HDD 回退引導路徑中過度執行安全啟動（技術上是 UEFI 韌體錯誤未記錄的功能）這使其與 SecureBoot 墊片不兼容）。在這種情況下，更新 SecureBoot 墊片可能會有所幫助。