grub2 使用错误的 /boot 分区

Question

我最近从 USB 安装了 Ubuntu 18.04。我所做的一切都与从 14 升级到 16、以及从 16 升级到 17 时所做的相同，直到现在每次都有效。从 USB 映像运行 18 时，我选择了“擦除 ubuntu 17 并安装 ubuntu 18”。这是我的问题：Grub2 加载，但似乎在错误的分区中使用了错误的配置文件。为了运行 ubuntu，我必须设置根目录并设置其所在的/dev/sda8正确文件linux和文件（这也是我要使用的文件所在的位置）。我可以看到上面有一个文件指向BIOS 分区。我的问题是，如何让 grub 使用我从 ubuntu 更新的配置文件（位于）？我担心如果我更改 上的那个，我会严重破坏某些东西，但如果没有，使用 cfg 文件的内容就足够了吗？initrd/dev/sda8/bootgrub.cfggrub.cfgdev/sda1/EFI/ubuntu/grub.cfg/dev/sda5/dev/sda8/boot/dev/sda1sda8

fdisk -l这是供参考的终端输出：

Device         Start       End   Sectors   Size Type
/dev/sda1       2048    206847    204800   100M EFI System
/dev/sda2     206848    468991    262144   128M Microsoft reserved
/dev/sda3     468992 816990982 816521991 389.4G Microsoft basic data
/dev/sda4  816992256 818726911   1734656   847M Windows recovery environment
/dev/sda5  818726912 818728959      2048     1M BIOS boot
/dev/sda6  935913472 939819007   3905536   1.9G Linux swap
/dev/sda7  942651392 976773119  34121728  16.3G Microsoft basic data
/dev/sda8  818728960 935913471 117184512  55.9G Linux filesystem

该文件/dev/sda1/EFI/ubuntu/grub.cfg有以下内容，注意(hd0,5)是BIOS分区：

search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Answer 1

对于那些将来发现这个问题并在其服务器上使用cloud-init的人（例如通过 MAAS 的专用服务器，或通过任何虚拟化软件或“云”提供商的虚拟服务器 (VPS)），有一个非常简单的修复方法。

我是如何遇到这个问题的

我将其中一台虚拟机上的 rootfs 从其原始根分区迁移到新磁盘 - 我发现它将update-grub继续使用原始 rootfs 的 PARTUUID。首先，我认为这只是与在 chroot 中运行它相关的问题，因此我手动更正了 UUID 并/boot/grub/grub.cfg重新启动。

启动到新的 rootfs 分区后，我运行了update-grub，希望从新磁盘上运行的真实系统运行它，它现在可以使用正确的 UUID - 不幸的是不是。

我搜索了互联网并找到了这个 StackExchange 问题，一个答案建议检查/boot/efi是否有任何可能起作用的潜在额外配置文件。果然，我发现/boot/efi/boot/grub/grub.cfg其中似乎包含硬编码的 FS UUID：

root@host ~ # cat /boot/efi/boot/grub/grub.cfg
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
search.fs_uuid 897a358a-acba-4b07-867c-33d1ca3b28dc root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

我更正了fs_uuid，但这仍然没有完全修复update-grub在 中设置错误的 PARTUUID /boot/grub/grub.cfg。

然而，我最终在命令日志中注意到一个可疑的配置文件update-grub：

root@host ~ # update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-71-generic
Found initrd image: /boot/initrd.img-5.4.0-71-generic
Found linux image: /boot/vmlinuz-5.4.0-24-generic
Found initrd image: /boot/initrd.img-5.4.0-24-generic
done

该问题的最终修复

嗯... Sourcing file '/etc/default/grub.d/40-force-partuuid.cfg'- 强制partuuid？看起来是罪魁祸首。

root@host ~ # cat /etc/default/grub.d/40-force-partuuid.cfg
GRUB_FORCE_PARTUUID=897a358a-acba-4b07-867c-33d1ca3b28dc

果然，它包含在 GRUB 配置中不断设置的分区 UUID，尽管不正确。

更改GRUB_FORCE_PARTUUID为我的 rootfs 分区的 PARTUUID 并重新运行后update-grub，它终于在 grub.cfg 中使用了正确的 PARTUUID :)

概括

要在使用 的系统上解决此问题cloud-init，首先您需要记下根文件系统（和/或可能是启动分区，如果您有单独的分区）的文件系统 UUID UUID=( ) 和分区 UUID ( )命令：PARTUUID=blkid

root@host ~ # blkid
/dev/sda1: UUID="wcrpSm-QCZu-VN3A-I503-sQqQ-5xfw-76r5bd" TYPE="LVM2_member" PARTUUID="bec389fc-4274-5245-babb-7d90674f1662"
/dev/sdb2: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="072E-C819" TYPE="vfat" PARTUUID="78730ead-03d3-e14d-b4fe-ee0abf4f0ad5"
/dev/sdb3: UUID="6cea6786-510a-4fba-871b-7811b63b3453" TYPE="xfs" PARTUUID="530c353b-0be8-e34e-affb-bd5c2332abc7"

就我而言，/dev/sdb3是 rootfs 和 boot 分区。

现在，/boot/efi/boot/grub/grub.cfg使用您选择的编辑器（例如nano或vim）打开，并将 UUID 部分替换fs_uuid XXXX-XXXX为您的文件系统 UUID，例如，在我的例子中，它是6cea6786-510a-4fba-871b-7811b63b3453

接下来，打开/etc/default/grub.d/40-force-partuuid.cfgUUID 值并将其替换GRUB_FORCE_PARTUUID=为您的 PARTITION UUID (PARTUUID)，在我的例子中是530c353b-0be8-e34e-affb-bd5c2332abc7。

最后，运行update-grub- 然后检查/boot/grub/grub.cfg并确认它现在使用正确的 FS UUID + PARTUUID。

您现在应该能够更新 GRUB 配置并重新启动，而不会由于无效的 UUID 而陷入 initramfs 中:)

Answer 2

正如我在评论中提到的，我对“BIOS 启动”分区的用途以及为什么有多个不同的grub.cfg文件分布在不同的分区感到困惑。我认为您所需要的只是一个grub.cfg文件，它应该能够启动 Linux 和 Windows。

另一件事是绝对确保您要更新的实时 USB 是在 EFI 模式下创建和启动的，而不是传统 BIOS 启动模式。检查这一点的一个简单方法是从 USB 启动并检查文件 /sys/firmware/efi 是否存在。如果没有，则说明未在 EFI 模式下启动。

我有一个与 Windows/Linux 非常相似的双引导系统。我查了一下，只有一个grub.cfg文件，在Linux系统根分区的/boot/grub文件夹下。EFI 系统分区在引导期间挂载到 /boot/efi。

关于您关于修改grub.cfgEFI 分区的问题：这样做应该不会有任何害处。事实上，如果您grub.cfg出于某种原因确实需要多个文件，那么最好自己维护这些文件（而不是希望自动更新工具能够正确处理它）。我会先备份自动创建的文件，您还可以在修改文件之前在 grub 命令行上测试引导命令。如果您确实搞砸了某些事情，可能发生的最糟糕的情况是您将被转储到 GRUB 命令提示符中，您必须在其中手动输入引导命令。如果您不知道如何执行此操作，那么您可能必须通过实时 USB 启动并修复/恢复文件。

另一件事是，如果您手动进行更改grub.cfg，那么下次 GRUB 进行自动更新时它们可能会被覆盖（在这种情况下，我可能会update-grub command在您的 Linux 发行版中禁用它）。