多重引导系统 grub 问题 - 编辑 - 修改

Question

1. 这怎么可能？

GRUB 引导菜单项中的任何文本都只是文本。它与任何 Linux 设备没有直接关系 - 因为当 GRUB 运行时，Linux 设备尚不存在。将磁盘/分区/可启动操作系统列表从固件/引导加载程序传递到内核也不一定有帮助：不能普遍保证 Linux 内核会按照与固件相同的顺序检测磁盘。

在像您这样的 UEFI 系统上（由于存在文件系统/boot/efi），固件会根据 UEFI NVRAM 变量中的信息加载引导加载程序。您可以使用来查看它们sudo efibootmgr -v。这些变量可以通过多种方式识别 EFI 系统分区（简称 ESP）及其中的文件以进行引导，但最常见的可能是使用 PARTUUID 和 Windows 样式的路径名。

一旦固件加载了引导加载程序，引导加载程序基本上就可以做任何它想做的事情了。通常 GRUB 会读取一个配置文件，该文件会告诉它要做什么以及要显示什么样的菜单。该配置文件的位置可以 a) 嵌入在文件中，或 b) 由位于文件所在同一目录中的grubx64.efi迷你文件间接指定。grub.cfggrubx64.efi

在内部，GRUB 使用磁盘和分区标识符，例如(hd0,gpt1).任何对的引用/dev/sd*在引导时对 GRUB 来说都是毫无意义的。如果启动菜单项包含任何 Linux 设备名称，则它们是历史信息充其量，并且直接的猜测最坏的情况是。由于 GRUB 仅具有 Linux 内核和 initramfs 功能的一小部分，因此它最多只能记录创建 GRUB 配置时 Linux 设备名称的存在方式，仅此而已。

如果您已执行 Boot_repair 建议的修复操作，则它可能添加了一个新的 UEFI 引导变量，该变量使用 Boot_repair 创建的配置文件来调用 Boot_repair 安装的 GRUB 版本。由于这有效地覆盖了所有发行版的 GRUB 实例，因此当您需要再次启动系统时它可能会有所帮助...但由于 Boot_repair 生成的菜单不一定会随着您安装的操作系统接收内核更新而更新，例如Boot_repair 生成的 GRUB 配置不应被视为永久解决方案，而应被视为临时解决方法允许您决定哪个多重引导操作系统应管理主引导加载程序以及其他操作系统/引导加载程序应如何与主引导加载程序耦合。

话虽如此，“grub从一个分区加载并且操作系统实际上从另一个分区运行”实际上可能是一种完全正常的情况：

在 UEFI 系统上，固件（或安全启动垫片）从 ESP 加载 GRUB（在 Debian/Ubuntu 上，通常安装在处的单独文件系统/boot/efi）
GRUB 从一个或多个文件系统位置读取其配置（通常/boot/grub可能是 Linux 根文件系统或单独/boot文件系统的一部分，但当然也可能有更深奥的配置）
GRUB 配置指示 GRUB 在何处读取内核和 initramfs 文件，以及它向内核提供哪些内核引导参数（通常内核和 initramfs 文件位于/boot，但使用自定义 GRUB 配置时，它们可以位于 GRUB 支持的任何文件系统上） GRUB 和/或系统固件）。
最终，initramfs 的内容将决定哪个文件系统被挂载为 Linux 根文件系统（大多数发行版的 initramfs 实现都遵循内核引导选项root=，但可以完全忽略它并执行 initramfs 配置为执行的任何操作）

2. 我可以编辑什么文件来手动从“grub”菜单中删除此项？

我们不可能知道这一点，因为您没有向我们提供必要的信息来弄清楚这一点。不过，我可以给你一些指导，告诉你如何自己解决这个问题。

首先，既然您显然拥有 UEFI 系统，那么您很幸运。在 BIOS 引导系统上，这会比较棘手。

从...开始sudo efibootmgr -v。该BootCurrent: NNNN行将标识BootNNNN系统用于达到当前状态的相应引导变量。该BootNNNN行可以有多种形式，但它可能包含加载引导加载程序文件的 ESP 的 PARTUUID，以及引导加载程序文件的路径名（相对于 ESP 文件系统的根），Microsoft 风格。您可以使用来查看分区的 PARTUUID lsblk -o +partuuid，无需sudo。

如果引导加载程序文件是shimx64.efi，它将grubx64.efi从填充程序所在的同一目录加载。如果引导加载程序文件是grubx64.efi，它将直接加载，而不需要安全引导填充程序。如果grub.cfgESP 的同一目录中有一个文件，请读取它：在大多数情况下，它要么是实际的 GRUB 配置，要么是一个迷你配置，它只是告诉 GRUB 真正的配置文件在哪里，可能使用文件系统 UUID 和一个路径名。用于lsblk -o +uuid查看文件系统的文件系统 UUID。

但是，您的 GRUB 可能会将配置文件路径名嵌入到grubx64.efi二进制文件中并指向某个不明显的位置。在这种情况下，strings grubx64.efi | grep -B 1 '^sbat,1,SBAT Version' | head -1也许可以提供一个线索；但是，这不能保证有效，因为从 GRUB 二进制文件中可靠地找到初始配置文件路径需要解析二进制数据结构。

3、从`efibootmgr -v`输出来看

根据efibootmgr -v输出，您的系统当前可能拥有（或可能已经拥有）三个独立的 GRUB 实例，并且所有实例都被命名为ubuntu，因此可能无法在 BIOS 引导顺序菜单中区分它们。

指示BootCurrent: 0005系统当前正在使用以下Boot0005条目启动：

Boot0005* ubuntu    HD(1,GPT,0621e243-4a24-4e6d-bdbb-cd02425977f8,0x800,0x100000)/File(\EFI\ubuntu\grubx64.efi)..BO

从这里，我们可以看到包含引导加载程序的 EFI 系统分区的唯一 PARTUUID 是0621e243-4a24-4e6d-bdbb-cd02425977f8，并且它可能是其 GPT 分区磁盘上的第一个分区 ( HD(1,GPT...)。运行lsblk -o +partuuid | grep -i 0621e243-4a24-4e6d-bdbb-cd02425977f8，您将识别包含活动引导加载程序的磁盘。

如果那是不是在当前正在运行的 Ubuntu 实例中安装的磁盘/boot/efi，那么我的理论是正确的，您当前正在使用其他某个 Ubuntu 实例的 GRUB 进行引导，使用sudo update-grub上次执行时生成的 GRUB 配置文件那操作系统实例。启动到该操作系统实例，sudo update-grub在那里运行，然后启动回当前操作系统很可能会导致os-prober识别当前运行的 Ubuntu 实例现在具有 5.15.0-50 内核，并相应地更新启动菜单。

但是，如果当前运行的 Ubuntu 实例是您的“主要”实例，您可能希望将其引导加载程序设为主要实例。为此，您必须检查当前/boot/efi文件系统的 PARTUUID：

lsblk -o +partuuid |grep /boot/efi

查找输出BootNNNN中sudo efibootmgr -v包含该 PARTUUID 的行。然后使用sudo efibootmgr --bootorder NNNN,0005,0000,006,0009,000C,000D,000E,000F,000B,0002其中 NNNN 与包含BootNNNN当前/boot/efi.

这是一次性操作，如果成功，sudo update-grub在此 Ubuntu 实例中应正常更新活动引导加载程序，并且任何内核更新应自动再次在 GRUB 引导菜单中可见。但是，那其他Ubuntu 实例将失去其作为“启动菜单的主要维护者”的角色，并且任何内核更新那sudo update-grubUbuntu 实例只有在运行后才能启动当前的Ubuntu 实例。

进行此更改后，您可能会发现 GRUB 引导菜单现在可能有很大不同，因为它将sudo update-grub运行os-prober以重建其他可引导操作系统实例的列表。这可能会很好地解决您在 GRUB 菜单中看到不存在的分区的问题；但是，如果“幽灵”实例仍然存在，则应该可以在/boot/grub/grub.cfg您当前的 Ubuntu 实例中找到它们，并且您可以选择自定义它或脚本/etc/grub.d/30_os-prober以减少列出的操作系统实例的数量。

一旦您成功创建与您的主操作系统匹配的 GRUB 实例作为您的主引导加载程序（使用上面的说明）并已测试其效果令您满意BootNNNN，那么您可以考虑使用从固件启动变量中删除额外的条目sudo efibootmgr --delete-bootnum -b NNNN。这至少可以最大限度地减少固件启动顺序菜单（“BIOS 设置”）中的混乱。

Answer 1

1. 这怎么可能？

GRUB 引导菜单项中的任何文本都只是文本。它与任何 Linux 设备没有直接关系 - 因为当 GRUB 运行时，Linux 设备尚不存在。将磁盘/分区/可启动操作系统列表从固件/引导加载程序传递到内核也不一定有帮助：不能普遍保证 Linux 内核会按照与固件相同的顺序检测磁盘。

在像您这样的 UEFI 系统上（由于存在文件系统/boot/efi），固件会根据 UEFI NVRAM 变量中的信息加载引导加载程序。您可以使用来查看它们sudo efibootmgr -v。这些变量可以通过多种方式识别 EFI 系统分区（简称 ESP）及其中的文件以进行引导，但最常见的可能是使用 PARTUUID 和 Windows 样式的路径名。

一旦固件加载了引导加载程序，引导加载程序基本上就可以做任何它想做的事情了。通常 GRUB 会读取一个配置文件，该文件会告诉它要做什么以及要显示什么样的菜单。该配置文件的位置可以 a) 嵌入在文件中，或 b) 由位于文件所在同一目录中的grubx64.efi迷你文件间接指定。grub.cfggrubx64.efi

在内部，GRUB 使用磁盘和分区标识符，例如(hd0,gpt1).任何对的引用/dev/sd*在引导时对 GRUB 来说都是毫无意义的。如果启动菜单项包含任何 Linux 设备名称，则它们是历史信息充其量，并且直接的猜测最坏的情况是。由于 GRUB 仅具有 Linux 内核和 initramfs 功能的一小部分，因此它最多只能记录创建 GRUB 配置时 Linux 设备名称的存在方式，仅此而已。

如果您已执行 Boot_repair 建议的修复操作，则它可能添加了一个新的 UEFI 引导变量，该变量使用 Boot_repair 创建的配置文件来调用 Boot_repair 安装的 GRUB 版本。由于这有效地覆盖了所有发行版的 GRUB 实例，因此当您需要再次启动系统时它可能会有所帮助...但由于 Boot_repair 生成的菜单不一定会随着您安装的操作系统接收内核更新而更新，例如Boot_repair 生成的 GRUB 配置不应被视为永久解决方案，而应被视为临时解决方法允许您决定哪个多重引导操作系统应管理主引导加载程序以及其他操作系统/引导加载程序应如何与主引导加载程序耦合。

话虽如此，“grub从一个分区加载并且操作系统实际上从另一个分区运行”实际上可能是一种完全正常的情况：

在 UEFI 系统上，固件（或安全启动垫片）从 ESP 加载 GRUB（在 Debian/Ubuntu 上，通常安装在处的单独文件系统/boot/efi）
GRUB 从一个或多个文件系统位置读取其配置（通常/boot/grub可能是 Linux 根文件系统或单独/boot文件系统的一部分，但当然也可能有更深奥的配置）
GRUB 配置指示 GRUB 在何处读取内核和 initramfs 文件，以及它向内核提供哪些内核引导参数（通常内核和 initramfs 文件位于/boot，但使用自定义 GRUB 配置时，它们可以位于 GRUB 支持的任何文件系统上） GRUB 和/或系统固件）。
最终，initramfs 的内容将决定哪个文件系统被挂载为 Linux 根文件系统（大多数发行版的 initramfs 实现都遵循内核引导选项root=，但可以完全忽略它并执行 initramfs 配置为执行的任何操作）

2. 我可以编辑什么文件来手动从“grub”菜单中删除此项？

我们不可能知道这一点，因为您没有向我们提供必要的信息来弄清楚这一点。不过，我可以给你一些指导，告诉你如何自己解决这个问题。

首先，既然您显然拥有 UEFI 系统，那么您很幸运。在 BIOS 引导系统上，这会比较棘手。

从...开始sudo efibootmgr -v。该BootCurrent: NNNN行将标识BootNNNN系统用于达到当前状态的相应引导变量。该BootNNNN行可以有多种形式，但它可能包含加载引导加载程序文件的 ESP 的 PARTUUID，以及引导加载程序文件的路径名（相对于 ESP 文件系统的根），Microsoft 风格。您可以使用来查看分区的 PARTUUID lsblk -o +partuuid，无需sudo。

如果引导加载程序文件是shimx64.efi，它将grubx64.efi从填充程序所在的同一目录加载。如果引导加载程序文件是grubx64.efi，它将直接加载，而不需要安全引导填充程序。如果grub.cfgESP 的同一目录中有一个文件，请读取它：在大多数情况下，它要么是实际的 GRUB 配置，要么是一个迷你配置，它只是告诉 GRUB 真正的配置文件在哪里，可能使用文件系统 UUID 和一个路径名。用于lsblk -o +uuid查看文件系统的文件系统 UUID。

但是，您的 GRUB 可能会将配置文件路径名嵌入到grubx64.efi二进制文件中并指向某个不明显的位置。在这种情况下，strings grubx64.efi | grep -B 1 '^sbat,1,SBAT Version' | head -1也许可以提供一个线索；但是，这不能保证有效，因为从 GRUB 二进制文件中可靠地找到初始配置文件路径需要解析二进制数据结构。

3、从`efibootmgr -v`输出来看

根据efibootmgr -v输出，您的系统当前可能拥有（或可能已经拥有）三个独立的 GRUB 实例，并且所有实例都被命名为ubuntu，因此可能无法在 BIOS 引导顺序菜单中区分它们。

指示BootCurrent: 0005系统当前正在使用以下Boot0005条目启动：

Boot0005* ubuntu    HD(1,GPT,0621e243-4a24-4e6d-bdbb-cd02425977f8,0x800,0x100000)/File(\EFI\ubuntu\grubx64.efi)..BO

从这里，我们可以看到包含引导加载程序的 EFI 系统分区的唯一 PARTUUID 是0621e243-4a24-4e6d-bdbb-cd02425977f8，并且它可能是其 GPT 分区磁盘上的第一个分区 ( HD(1,GPT...)。运行lsblk -o +partuuid | grep -i 0621e243-4a24-4e6d-bdbb-cd02425977f8，您将识别包含活动引导加载程序的磁盘。

如果那是不是在当前正在运行的 Ubuntu 实例中安装的磁盘/boot/efi，那么我的理论是正确的，您当前正在使用其他某个 Ubuntu 实例的 GRUB 进行引导，使用sudo update-grub上次执行时生成的 GRUB 配置文件那操作系统实例。启动到该操作系统实例，sudo update-grub在那里运行，然后启动回当前操作系统很可能会导致os-prober识别当前运行的 Ubuntu 实例现在具有 5.15.0-50 内核，并相应地更新启动菜单。

但是，如果当前运行的 Ubuntu 实例是您的“主要”实例，您可能希望将其引导加载程序设为主要实例。为此，您必须检查当前/boot/efi文件系统的 PARTUUID：

lsblk -o +partuuid |grep /boot/efi

查找输出BootNNNN中sudo efibootmgr -v包含该 PARTUUID 的行。然后使用sudo efibootmgr --bootorder NNNN,0005,0000,006,0009,000C,000D,000E,000F,000B,0002其中 NNNN 与包含BootNNNN当前/boot/efi.

这是一次性操作，如果成功，sudo update-grub在此 Ubuntu 实例中应正常更新活动引导加载程序，并且任何内核更新应自动再次在 GRUB 引导菜单中可见。但是，那其他Ubuntu 实例将失去其作为“启动菜单的主要维护者”的角色，并且任何内核更新那sudo update-grubUbuntu 实例只有在运行后才能启动当前的Ubuntu 实例。

进行此更改后，您可能会发现 GRUB 引导菜单现在可能有很大不同，因为它将sudo update-grub运行os-prober以重建其他可引导操作系统实例的列表。这可能会很好地解决您在 GRUB 菜单中看到不存在的分区的问题；但是，如果“幽灵”实例仍然存在，则应该可以在/boot/grub/grub.cfg您当前的 Ubuntu 实例中找到它们，并且您可以选择自定义它或脚本/etc/grub.d/30_os-prober以减少列出的操作系统实例的数量。

一旦您成功创建与您的主操作系统匹配的 GRUB 实例作为您的主引导加载程序（使用上面的说明）并已测试其效果令您满意BootNNNN，那么您可以考虑使用从固件启动变量中删除额外的条目sudo efibootmgr --delete-bootnum -b NNNN。这至少可以最大限度地减少固件启动顺序菜单（“BIOS 设置”）中的混乱。

多重引导系统 grub 问题 - 编辑 - 修改

答案1

1. 这怎么可能？

2. 我可以编辑什么文件来手动从“grub”菜单中删除此项？

3、从`efibootmgr -v`输出来看

相关内容

答案1

1. 这怎么可能？

2. 我可以编辑什么文件来手动从“grub”菜单中删除此项？

3、从efibootmgr -v输出来看

相关内容

3、从`efibootmgr -v`输出来看