Rya*_*Lee 6 linux dual-boot windows grub2 uefi
我知道其他类似的问题也有人问过,但我认为这种情况有点不同。
系统是带有 2 个 SSD 的 Lenovo T430(一个在光驱托架中)。
原始安装是主 SSD 中的 Win10。添加 Mint 使其双启动,一切都很好。
决定在辅助 SSD 上使用 Kali 进行三次启动 - 仍然很好(Kali 选择了 Mint 和 Win 10)。
一切都很好,直到我有了在辅助 SSD 上与 Kali 一起安装 XP(这是有原因的,别担心)的好主意。我拉出主 SSD 并将辅助 SSD 放置到位。我先对原始 Kali 进行映像,然后擦除驱动器并安装 XP。完成后,我安装了最新版本的 Kali。在此过程中,它询问我是否要强制使用 UEFI。我最初说不,然后它似乎想擦除驱动器,我显然也不想这样做。所以,我说是的,强制 UEFI。不用说,Kali 安装了,但没有看到 XP(这很好,我将它们分开进行了分区,所以它不会覆盖 XP 安装。我引导到 XP 光盘,修复了 MBR,然后它引导到了 XP 但Kali 是隐形的。好吧,我想,不管怎样,也许他们在一起玩得不好。别担心,当我需要使用一个或另一个时,我只会拍摄每个分区的图像并重新映像该驱动器。十分简单。
因此,我将主要和次要的配置恢复到原始配置(主要是 Win 10 + Mint,次要的是 XP 和无法访问的 Kali),擦除次要(分别对 XP 和 Kali 部分进行映像后),并再次安装 Kali 作为唯一的操作系统在次要。消息再次弹出,说“您要强制使用 UEFI 吗?” 我想,嘿,我现在正在使用所有现代操作系统,所以没问题,然后说是的。
只是这一次,它不会在主节点上看到 Windows。它会看到 Mint 并启动它,但不会看到 Windows。分区看起来仍然存在于 gparted 中。我尝试使用 Win 10 修复,不行。尝试重新安装 Mint,认为它可能会捡起它并恢复到原始配置,但没有 - 尝试编写 Grub 时 Mint 失败。
所以,我被困住了。我已经清除了辅助驱动器,因此它是空白的(暂时将其从等式中删除 - 不那么复杂)。
如何取回 Windows?我知道 Kali 并没有真正吃它,它只是覆盖了指向它的东西。我知道它就在那里,而且我有很多我需要的东西。
在此先感谢您的帮助。我对 Linux 的了解足以让自己陷入困境(显然),但还不足以说我精通。
编辑:添加照片。在我看来,SSD2 是 GPT,SSD1 是 MBR?此外,两者都是 2.5 英寸 SSD,这台笔记本电脑对于 NVMe 驱动器来说太旧了。谢谢!
帮助!

tel*_*coM 19
好的,先来一些背景资料:
以 UEFI 原生方式启动的操作系统将能够在操作系统作为一组 UEFI NVRAM 启动变量运行时访问启动配置;这是 UEFI 规范的一部分。在Linux中,最人性化的方式是efibootmgr命令;在 Windows 中,该bcdedit命令以管理员身份运行时可以访问 UEFI 引导变量。要查看引导变量,请efibootmgr -v在 Linux 中以 root 身份运行,或bcdedit /enum FIRMWARE在 Windows 中以管理员身份运行。
一些 UEFI 固件实现不会在“BIOS”配置菜单中提供对 UEFI 引导变量的完全访问,但坚持使用简化的类似 BIOS 的引导磁盘选择。在尝试构建高级多重引导方案时,这可能会困扰您。您需要了解 UEFI 引导变量的存在,并准备好在各种安装程序出错时对其进行编辑。
如果您有 NVMe SSD,您的系统固件需要专门支持从它启动,因为 NVMe SSD 根本不像 SATA 驱动器。某些 UEFI 固件仅支持在 UEFI 模式下从 NVMe 设备启动。如果操作系统有可用的 NVMe 驱动程序,这通常不会阻止操作系统访问 NVMe 设备。
大多数 UEFI 感知操作系统安装程序将检测操作系统安装程序的启动模式(BIOS 或 UEFI),并将安装匹配类型的引导加载程序,不会提出任何问题。Kali 显然可以提供“强制 UEFI”,即安装 UEFI 引导加载程序,即使安装程序是 BIOS 风格的引导。
使用 BIOS 式引导,磁盘的 MBR 一次只能被一个引导加载程序/管理器占用;通常,您会选择最能启动多个操作系统的操作系统(例如 GRUB)。如果其他操作系统覆盖了 MBR,您将需要能够使用外部启动媒体启动“指定的 MBR 管理器操作系统”并重写 MBR。
使用 UEFI 式引导,引导加载程序包含在标准化目录结构中的 ESP 分区(基本上是 FAT32 分区)中。多个操作系统的引导加载程序可以共存于一个 ESP 分区中就好了。但是如果没有 UEFI 引导变量将其定向到特定的引导加载程序文件,UEFI 固件将寻找一个“神奇”引导加载程序文件名:在 x86_64 硬件上,它是\EFI\BOOT\BOOTX64.efi. \EFI\Microsoft\Boot\bootmgfw.efi即使 UEFI NVRAM 引导变量丢失(例如,由于 BIOS 更新/刷新),Windows 通常也会在此位置放置其文件的第二个副本以启用引导 Windows。Kali 的“Force UEFI?” 可能意味着也可能不意味着将 UEFI GRUB 的副本写入\EFI\BOOT\BOOTX64.efiESP 分区。
不同的操作系统具有不同级别的 UEFI 支持,启动方法的选择可能与分区类型的选择有关:
与 Windows XP 不同,Windows 10 需要多个分区。启动 UEFI 风格时,它需要一个 ESP 分区(可能与其他操作系统共享)、一个主 Windows 系统分区(通常是 C: 驱动器)和一个小的恢复分区。在新安装中,通常还有一个“Microsoft 保留”分区,尽管它在技术上不是绝对必要的:从早期版本的 Windows 升级的安装可能没有它。
大多数引导加载程序/引导管理器只能使用与引导加载程序相同的引导样式来引导操作系统。如果您有一个传统操作系统和一个 UEFI 原生操作系统的双引导,则在操作系统之间切换的唯一方法可能是使用 BIOS 菜单在引导模式或“UEFI/legacy first”首选项之间切换。rEFInd 引导管理器是一个 UEFI 原生引导加载程序,在某些情况下显然可以启动 BIOS 风格的引导加载程序,但不能保证适用于所有系统;您可能需要尝试一下,看看它是否适合您。
如果您系统的 BIOS 菜单提供了大量的引导方法选项,这将非常有用:
某些笔记本电脑或名牌台式机可能提供简化的 BIOS 菜单,但可配置性非常有限。在这些情况下,您可能需要弄清楚系统是更喜欢 UEFI 还是 BIOS,在最坏的情况下,您可能必须创建操作系统安装介质,故意禁用“错误”类型的引导加载程序(对于 U 盘,删除\EFI\boot\bootx64.efi以使其成为 BIOS -only,或用有效的非启动 MBR 替换 MBR 启动代码,使其仅用于 UEFI)。
听起来您的主磁盘是 GPT 分区的,其上的操作系统可能使用 UEFI。要确认这一点,请运行fdisk -l并将输出编辑为您的原始问题。
如果是这样,则您的 UEFI 引导变量当前可能配置错误和/或 Windows UEFI 引导加载程序(位于/boot/efi/EFI/Microsoft/Boot/bootmgfw.efiMint 中)可能已损坏。请sudo efibootmgr -v在 Linux 中运行以检查您的 UEFI 引导变量的当前状态并将输出编辑为您的原始问题,或者如果它很长,例如将其放入 pastebin 站点并将其链接到您的问题。
可视化 ESP 分区状态的最便捷方法可能是sudo tree --charset ASCII /boot/efi从 Linux运行。请将其添加到您的原始问题中。为了使其更短,您可以省略目录的/boot/efi/EFI/Microsoft/Boot子目录,因为有多个特定于语言的目录。
有了这些信息,我(或此 StackExchange 中的其他人)可能能够帮助您,而无需盲目猜测。
从图片中可以看出,您的sda磁盘分区是 MBR 样式的,但efibootmgr -v输出中包含Windows Boot Manager一行,表示系统在过去的某个时间点以 UEFI 样式启动 Windows。UEFI 变量通过 GPT 分区唯一 GUID(PARTUUID在 Linux 中)标识它们引用的 ESP 分区,并且 Windows 引导管理器行上的 GUID 与kali's 行上的GUID 不匹配。
另一方面,该ubuntu行指的是 MBR 分区,并且该行包含0xd1e9685与 的磁盘标识符完全匹配的值sda。
基于此,看起来发生了这样的事情:
无论是sda磁盘从GPT在某个时候转化为MBR,或在安装Windows时两个磁盘已经存在,并且sda已经分区MBR风格。但是 Windows 安装程序是以 GPT 样式启动的,因此它寻找一个地方将 ESP 分区添加到 GPT 分区的磁盘上,以进行正确的 UEFI 样式启动。因此,它以 GPT 样式格式化辅助 SSD,并将 ESP 分区和 Windows 引导加载程序放在其中,因为当时它可能完全未初始化。
(如果有机会,这种将 ESP 放在与 Windows 其余部分不同的磁盘上的趋势是 Windows 10 安装程序的一个已知问题。标准建议是在运行 Windows 10 安装程序之前暂时拔下或禁用任何其他磁盘,如果您的系统有超过 1 个磁盘。)
安装 Mint 时,安装程序再次启动 UEFI 样式,但与 Windows 安装程序不同,除非明确告知,否则它不会接触磁盘,因此它创建了自己的 ESP 分区到 MBR 分区磁盘(sda5分区类型 0xef)。
第一个 Kali 显然也在辅助 SSD 上创建了自己的 ESP 分区,但是在 GPT 分区中,每个分区都有一个唯一的 GUID,UEFI 使用它来识别每个操作系统使用哪个 ESP 分区来启动,因此这不会导致任何混淆.
当您断开主 SSD 的连接并将辅助 SSD 放置在其安装 XP 的位置时,您可能已经看到了一个类型为 0xee 的分区。这是一个虚拟的 MBR 分区表,它是 GPT 分区标准的一部分,用于向任何不支持 GPT 的操作系统指示该磁盘正在使用中。但是您假设磁盘未使用,并忽略了它 - 因此,Windows 引导加载程序在您不知道的情况下被覆盖。
你第二次安装的 Kali 也必须是 UEFI 风格的,它在 MBR 上创建了一个 ESP 分区 - 就像 Mint 一样。Kali 的“Force UEFI”大概意味着两件事:
\EFI\BOOT\BOOTx64.efiESP 分区。结果,您现在在同一个磁盘上有两个具有不同引导方法的操作系统。Kali 的 UEFI GRUB 无法启动 Windows XP,因为这需要在从 GRUB 跳转到 XP 引导加载程序时重新打开 BIOS 兼容性,而 GRUB 不知道如何做到这一点。您的系统似乎更喜欢引导传统风格而不是 UEFI,因为在修复 XP 的 MBR 后,固件直接回到引导 BIOS 风格......这使得切换到 Kali 的 UEFI GRUB 变得不可能,因为 16 位 BIOS 兼容模式没有希望有意义地使用 UEFI GRUB 的 64 位代码。
当您将磁盘移回其原始位置并再次擦除辅助磁盘时,Windows 引导加载程序现在被擦除了两次。Windows 10 启动恢复很困惑,因为它看到 MBR 分区磁盘上的大多数 Windows(配置为启动 UEFI 风格),而 GPT 分区磁盘上的任何地方都没有 ESP 分区。Mint 安装程序也可能以某种方式感到困惑,但这可能不是最重要的事情。
摆脱这种情况并进入合理配置的最佳方法可能是使用 Mint 访问 Windowssda2磁盘,并将所有重要的内容从那里复制到可移动媒体或其他安全位置:
sudo mkdir /windows_c
sudo mount -t ntfs-3g /dev/sda2 /windows_c
cd /windows_c
cp <whatever> </some/where/safe>
Run Code Online (Sandbox Code Playgroud)
然后断开辅助 SSD,擦除主要 SSD 并从安装 Windows 10 UEFI 样式开始。如果可能,您可能需要更改 BIOS 设置以为此关闭传统 BIOS 样式的兼容性,以确保一切都以 UEFI 样式进行。然后在它旁边安装 Mint。
然后,您可以卸下主 SSD,将辅助 SSD 安装到位,重新打开 BIOS 样式的兼容性并安装 XP。现在将两个磁盘移回原来的位置,并可能在 UEFI 模式下将 Kali 安装到第二个磁盘上(不选择“强制 UEFI”)。然后启动到 Mint,确保os-prober安装了这个包,然后运行sudo update-grubKali 进入 Mint 的启动菜单。
现在无论你使用 Kali 还是 Mint 的 GRUB,都应该给你三个选项:Kali、Mint 和 Windows 10。要进入 XP,不幸的是,你需要进入 BIOS 设置并明确选择从辅助磁盘启动传统风格.