将物理 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”命令的输出如下所示
我该如何确保引导加载程序在进一步的工作中不会被损坏？