☰

重启后 GRUB 在 grub> 命令行中启动

tag-icon • tag-icon linux ubuntu grub
重启后 GRUB 在 grub> 命令行中启动

将物理 Ubuntu_18.04 机器转换为虚拟机器（vCenter 控制下的 ESXi）后，我在启动时遇到了以下窗口。

第一的

当我输入“退出”命令后，系统加载正常菜单，然后一切正常。

第二

如何让引导加载程序立即加载菜单，而无需进入命令行并键入“exit”？

PS我尝试了启动救援实用程序，它说它成功了，但没有帮助。

须藤 efibootmgr -v 启动管理器

UPD。 在此输入图像描述

如果我将 Bootorder 更改为 0003 sudo efibootmgr -o 0003,000A,0000,0001,0002,0004,0009,0005,0006,0007,0008 BootCurrent: 0003 BootOrder: 0003,000A,0000,0001,0002,0004,0 009 ,0005,0006,0007,0008 在此输入图像描述 根本不会加载

这没有帮助。

答案1

请lsblk -o +HCTL,PARTUUID在宽终端窗口中运行。

您的efibootmgr -v输出表明以下内容：

  • BootCurrent: 0003表明系统使用该Boot0003线路成功启动。
  • BootOrder表示成功Boot0003在整个启动顺序中排名第 5
  • 该Boot0003行将磁盘标识为.../SCSI(3,0)，因此要识别具有 GRUB 工作版本的磁盘，请查看HCTL上述lsblk命令的字段并查看哪个磁盘的 HCTL 字段中包含数字 3。
  • BootOrder 中的第一个条目Boot000A指定要从其引导的分区，使用 PARTUUID 值75d67bdc-e92a-47f3-6816-e6f03bed26e9：查看输出PARTUUID的字段lsblk以识别磁盘。

似乎0003引导顺序中之前的引导条目之一包含错误的 GRUB 安装。也许它是早期安装的残余，或者它用于查找/boot/grub目录的文件系统 UUID 在克隆过程中已更改。一旦退出该 GRUB 实例，固件就会在引导顺序列表中继续前进，直到在Boot0003条目中找到有效的引导加载程序。这可能位于后备/可移动媒体路径，即位EFI/BOOT/BOOTx64.efi于其所在的任何分区。

一个“完美”的修复可能是识别包含 ESP 分区的磁盘的 Linux 设备名称（应安装在/boot/efi/），然后运行：

sudo grub-install --target=x86_64-efi /dev/sdX

其中/dev/sdX应替换为包含 ESP 分区的整个磁盘设备的名称。这应该会自动将 GRUB 重新写入 ESP 分区，并更新列表efibootmgr -v以正确指向活动的 GRUB 实例。

如果无法识别磁盘，可以使用以下命令作为解决方法：

sudo efibootmgr --bootorder 0003,000A,0000,0001,0002,0004,0005,0006,0007,0008,0009

这将告诉固件将工作启动项放置为启动顺序中的第一个启动项，从而避免需要退出非工作启动项。它应该可以解决眼前的问题，但稍后在安装内核或 GRUB 更新或使其生效时可能会出现问题，因为无法确定成功引导系统的 GRUB 实例是否与软件包将更新的实例相同管理系统。

答案2

更改引导顺序没有帮助。但从 efi 中完全删除 Ubuntu 菜单项会有所帮助。

在此输入图像描述

为了以防万一，我在成功下载后运行了 update-grub2 命令。

现在“efibootmgr -v”命令的输出如下所示 在此输入图像描述

我该如何确保引导加载程序在进一步的工作中不会被损坏？

相关内容