GRUB 和 Windows 引導的問題
幾個月來，我一直在我的電腦上雙啟動 Windows 10 和 linux (KDE Neon)，沒有出現任何問題。但是，今天，在啟動到 linux 後，然後重新啟動並嘗試選擇 windows，我收到了這個錯誤：
Error: file /efi/microsoft/boot/bootmgfw.efi not found不確定我的 Windows 啟動有什麼問題，我回到 linux 並更新了 grub。這樣做的效果是 grub 在重新啟動或引導時根本沒有出現。
然後我使用 live USB 打開引導修復，它返回以下內容：
檢測到 GPT。請創建一個 BIOS-Boot 分區（>1MB，未格式化的文件系統，bios_grub 標誌）。這可以通過 Gparted 等工具執行。然後再試一次。或者，您可以在啟動後重試
$$ Separate /boot/efi partition: $$選項。
我不確定這意味著什麼，此時我擔心會進一步破壞任何東西。這是我的粘貼箱：https ://paste.ubuntu.com/p/K6qrpzmwZc//
我在 Ubuntu 論壇上問過這個問題並被重定向到這裡，儘管我有理由確定 linux 發行版對這個問題沒有影響。
即使引導修復以原生 UEFI 樣式引導（因為它可以向您顯示
efibootmgr -v輸出），它建議的修復與在 GPT 分區磁碟上設置傳統樣式引導有關。這似乎不適合您的情況。當心！關於未找到的錯誤消息
/efi/microsoft/boot/bootmgfw.efi表明您的系統最初使用的是 UEFI 本機引導樣式。對於 Windows，使用 GPT 分區的系統盤需要 UEFI 引導方式；你不能像 Linux 那樣混合使用 GPT + 傳統引導。應用建議的修復程序將無法選擇從 GRUB 引導的作業系統；您必須使用韌體設置（“BIOS 設置”）來切換引導順序和/或首選引導方式以在作業系統之間切換。看起來某些東西可能損壞了 EFI 系統分區 (ESP)。它通常是一個小的 FAT32 分區，由韌體 NVRAM 設置中的 UUID 標識。在 Debian、Ubuntu 和相關發行版中，它通常掛載到
/boot/efi.使用任何引導修復工具時，應小心以 UEFI 模式引導它們。當系統以舊模式啟動時，修復工具將無法訪問 UEFI NVRAM 啟動設置。
efibootmgr -v在 Linux 中，如果系統處於 UEFI 模式，您可以使用它來查看引導設置。根據
efibootmgr -vpastebin 中 Boot-Repair 的輸出，Boot-Repair 所指的分區/dev/sdb2應該包含兩個作業系統的 UEFI 引導載入程序（Windows 的 Windows 引導管理器和 Ubuntu 的安全引導 shim + GRUB）。但有些事情看起來很奇怪：BootCurrent: 0005 Timeout: 1 seconds BootOrder: 0002,0000,0001,0004,0005 Boot0000* Windows Boot Manager HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIUBUNTUGRUBX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...M................ Boot0001* Windows Boot Manager HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIMICROSOFTBOOTBOOTMGFW.EFI)..BO Boot0002* ubuntu HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFINEONSHIMX64.EFI) Boot0004* UEFI OS HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIBOOTBOOTX64.EFI)..BO Boot0005* UEFI: Imation Classic PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)..BO該
Boot0000條目被標記為 Windows 啟動管理器，但指的是\EFI\Ubuntu\grubx64.efi（我假設缺少反斜杠是使用 Pastebin 的產物？）。看起來對Boot0001Windows 基本有效（同樣沒有反斜杠），但它缺少出現在Boot0000. 主引導條目將是Boot0002，它啟動 Secure Boot shim\EFI\Neon\shimx64.efi，隨後將啟動\EFI\Neon\grubx64.efi。如果輸出中實際上缺少反斜杠，則
efibootmgr -v可能是某些東西錯誤地修改了您的引導 NVRAM 設置，或者您可能有一個非常嚴重的 UEFI 韌體錯誤。查看是否有適用於您的特定硬體型號的韌體更新（“BIOS 更新”）。但看起來兩者
\EFI\Neon和\EFI\Microsoft目錄都可能缺少 fronsdb2：/boot/efi detected in the fstab of sda3: UUID=E46B-39C6 (sdb2) Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bootx64.efi Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/fbx64.efi Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/grubx64.efi Presence of bkp file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi /usr/share/boot-sav/bs-cmd_terminal.sh: line 194: warning: command substitution: ignored null byte in input它應該也檢測到
/mnt/boot-sav/sdb2/EFI/Neon/shimx64.efi，/mnt/boot-sav/sdb2/EFI/Microsoft/Boot/bootmgfw.efi但沒有。您可以嘗試從 Windows 10 安裝媒體啟動並使用“修復 Windows”自動修復工具，然後從實時 Linux 媒體啟動，chroot 進入您的 KDE Neon 安裝，然後將 GRUB 和安全啟動 shim 重新安裝到 ESP（
sdb2如所列通過引導修復）。