我有一个 Intel Nuc-8i3beh，运行 Debian 10 Buster 和 Windows 10 双启动。首先安装的是Windows系统。引导加载程序是 uefi 模式下的 grub。
系统： sda -> sdb
上带有 Windows 和 debian 的主硬盘-> 用于数据 sdc 的第二个硬盘 -> 用于第二个硬盘备份的外部硬盘
我最近在 Windows 10 中安装了一些适用于英特尔系统的新驱动程序。之后我的引导加载程序不再显示。系统直接在Windows 中启动。然后，我尝试在 U 盘上运行启动修复映像，但启动修复实用程序的默认修复不起作用。以下是引导修复的漏洞摘要： http://paste.ubuntu.com/p/kgPymkWqGM/
我认为问题出在第29行：
wrong fs type, bad option, bad superblock on /dev/sda6, missing codepage or helper program, or other error
不知何故，超级块的表格不再正确：
Disk sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk identifier: EC763990-4AF7-4A4C-A3AA-355A8DC62FB8
Start End Sectors Size Type
sda1 2048 1085439 1083392 529M Windows recovery environment
sda2 1085440 1290239 204800 100M EFI System
sda3 1290240 1323007 32768 16M Microsoft reserved
sda4 1323008 117221375 115898368 55.3G Microsoft basic data
sda5 117221376 125034495 7813120 3.7G Linux swap
sda6 125034496 234437070 109402575 52.2G Linux filesystem
sda6 的结尾不再正确。
在telcoM的回答后我尝试了以下操作。我用 USB 驱动器启动了 Debian 实时系统：
efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
Could not prepare Boot variable: Permission denied
之后我用 sudo 尝试了同样的操作：
sudo efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
Could not prepare Boot variable: No space left on device
阅读评论后，我尝试运行 fsck 命令但没有成功：
sudo e2fsck -C0 -p -f -v /dev/sda6
/dev/sda6: The filesystem size (according to the superblock) is 13675776 blocks
The physical size of the device is 13675321 blocks
Either the superblock or the partition table is likely to be corrupt!
/dev/sda6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
我不知道手动运行 fsck 时必须在 fsck 上设置哪些选项。
有人知道如何解决这个问题吗？很感谢
答案1
你的sda6应该是加密的还是什么的？这也许可以解释为什么引导修复无法理解它。
efibootmgr -v引导修复摘要中的输出在这里可能很重要：
efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004,0002,0003,0001
Boot0000* Windows Boot Manager HD(2,GPT,768a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.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* debian VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002* UEFI : LAN : PXE IP4 Intel(R) Ethernet Connection (6) I219-V PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI : LAN : PXE IP6 Intel(R) Ethernet Connection (6) I219-V PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0004* UEFI : USB : SanDisk : PART 0 : OS Bootloader PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)/HD(1,MBR,0x456c7,0x800,0x3a7f800)..BO
从这里，您可以看到名为的 UEFI 启动选项debian仍然存在，但显然 Windows 已将其向后推回启动顺序，并将其设为第一个启动项。所以问题可能出在固件设置上，而不是 GRUB 本身。
（显然，至少某些版本的 Windows 10 确实需要 UEFIBoot0000插槽，但如果不一定将BootOrder其设置为 .肯定会自动将其自身恢复为 BootOrder 中的第一个操作系统，以尝试进行自我修复。当使用 UEFI 进行双引导时，明智的做法是假设 Windows 将始终占用Boot0000并相应地配置其他操作系统。）
不过，您的debian启动项看起来有点奇怪。它不像 WindowsBoot0000条目那样指常规 UEFI 引导加载程序。由于sda2似乎包含一个看起来有效的 GRUB，其路径名类似于 Debian 通常在 EFI 系统分区上使用的路径名，因此我期望正常的安全启动兼容debian条目如下所示：
Boot0001* debian HD(2,GPT,68a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\efi\debian\shimx64.efi)
但你的debian条目却VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)相反。
这可能意味着您的 Debian 曾经使用旧版 BIOS 兼容的引导方法，或者固件可能使用一些奇怪的特定于供应商的组装方法。
如果您可以efibootmgr使用 Boot-Repair 或任何其他 Linux Live USB 手动运行，您也许可以通过以下方式快速修复此问题：
efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
efibootmgr -0 0005,0001,0000,0004,0002,0003
第一个命令将为 Debian 定义一个新的 UEFI 引导条目，识别 ESP 分区上的正确磁盘和路径名（根据 UEFI 规范，系统上安装的所有 UEFI 引导加载程序可以共享该路径名）。
第二个命令将重新排列启动顺序，使新条目成为第一个，旧debian条目成为第二个，然后 Windows 作为第三个选项，然后是所有剩余的可能选项（以使固件满意）。
如果您找不到使用方法efibootmgr，您可以转到系统固件设置（通常称为“BIOS 设置”，但从技术上讲，这是一个过时的术语，因为 UEFI 不是 BIOS），然后只需更改启动顺序即可尝试名为debianfirst before 的启动项Windows Boot Manager。但这依赖于VenHwDebian 实际工作的现有奇怪启动项……这并不能完全让我充满信心。但尝试一下肯定没有坏处。