虚拟机开机卡在GRUB界面，系统无法自动引导时，不用重装系统，多数情况下通过GRUB命令行手动指定内核启动参数，进入系统后重装引导配置就能彻底修复。
按排查顺序展开，从应急进系统到根治问题，每一步都可以直接照着操作。
GRUB界面卡住无法引导系统？先分清是哪种状态
GRUB引导界面出现“卡住”的现象，通常分两种，处理方式完全不同。
停留在GRUB菜单，选择内核后黑屏或跳回菜单
这是最常见的场景,开机后能看到一个蓝色或黑底白字的菜单，上面有Ubuntu、Advanced options等选项，但按回车确认后，要么黑屏卡死，要么闪一下又回到菜单。
多数情况下这是GRUB配置文件里的分区UUID和实际分区信息不匹配造成的。 尤其是给虚拟机迁移过磁盘、调整过分区大小、或者从其他平台导入了镜相文件之后，UUID发生了变化，引导器找不到根分区，就只能反复回到菜单。
直接进入GRUB命令行或GRUB Rescue
这种情况比上面更直接屏幕左上角出现 grub> 或者 grub rescue> 提示符，没有任何菜单。
grub>表示引导加载器本身还能工作，只是引导配置失效了，需要手动输入指令引导内核。grub rescue>表示连GRUB的核心模块都没加载完，通常和启动分区被移动或损坏、BIOS/UEFI启动顺序错乱有关。
不管哪种状态,核心思路是手工完成“指定内核位置 + 指定根分区 + 启动”这三步。
虚拟机进入GRUB手动命令行，教你用手敲命令应急启动
如果机器停在 grub> 提示符下，先不要慌，手动引导系统需要四个步骤，每一步都验证后再往下走。
第一步：用ls命令查看当前磁盘和分区布局
在 grub> 提示符下输入：
ls屏幕会输出类似 (hd0) (hd0,msdos1) (hd0,msdos2) (hd1,gpt1) 这样的设备列表。
请你重点关注哪个分区可能放有内核文件 /boot/vmlinuz- 和 /boot/initrd.img-，逐个查看分区内容，可以使用：
ls (hd0,msdos1)/如果输出一堆 System Volume Information 或者Windows文件，说明这是Windows分区，跳过去继续看下一个。
第二步：设置根分区变量
找到存放 /boot 文件的分区后，把它的设备号设置给GRUB，
set root=(hd0,msdos2)这一步的作用是告诉GRUB内核文件在哪里,必须先执行，否则后续的linux命令会报“file not found”错误。
第三步：指定内核文件和initrd镜像文件路径
先看看到底有哪些内核文件可用：
ls /boot假设看到 /boot/vmlinuz-5.15.0-91-generic 和 /boot/initrd.img-5.15.0-91-generic，那么输入：
linux /boot/vmlinuz-5.15.0-91-generic root=/dev/sda2
initrd /boot/initrd.img-5.15.0-91-generic
boot注意两个细节：
- root=/dev/sda2需要按实际分区修正，如果刚才
set root设置的是(hd0,msdos2)，那么对应的设备名一般是/dev/sda2，如果有多个磁盘或NVMe设备，需要按顺序推理hd0对应sda，hd1对应sdb；GPT分区表的第一个分区对应sda1。 - boot是独立分区，则
set root指向那个独立boot分区，linux指令的路径要写成/vmlinuz-5.15.0-91-generic，不是/boot/vmlinuz-...，这一点是新手最容易困惑的地方。
第四步：如果提示找不到根目录怎么办
执行完 boot 后，如果报错 error: no such partition 或者内核启动过程中卡在 Gave up waiting for root device，说明 linux命令里的 root= 参数和刚才set root指定的是两个不同的分区。
set root控制的是内核文件的位置。root=控制的是系统根目录挂载位置。
这两个不一定要指向同一分区,如果GRUB的 ls 能看到多个分区，建议把根分区逐个试一遍，每次修改 root= 参数后重新执行 boot，系统根目录的典型特征是包含 /bin /etc /home 这类目录，用 ls (hd0,msdos3)/ 检查确认一下即可。
GRUB Rescue模式下的修复，从Rescue到正常启动
如果看到的是 grub rescue>，一条命令即可回到手动命令行模式：
set prefix=(hd0,msdos2)/boot/grub
insmod normal
normalset prefix指定的是GRUB模块和配置文件所在目录。insmod normal加载normal模块，使普通GRUB命令行可用。normal尝试读取/boot/grub/grub.cfg并显示启动菜单。
如果执行到 normal 后菜单正常出现，但选择内核仍然无法启动，则回到上一节的手动引导步骤来验证问题出在内核参数还是分区识别上。
normal 提示文件找不到
说明 prefix 设置错误，需要自行排查分区布局：
ls
ls (hd0,msdos1)/
ls (hd0,msdos2)/找到含 /grub 目录的分区后重新执行，部分新版Linux镜像文件存放在 /boot/efi 而非 /boot/grub，这时要设置 set prefix=(hd0,msdos1)/efi/grub 或者使用 set prefix=(hd0,msdos1)/boot/grub 逐个尝试。
Linux虚拟机grub无法引导的根治办法，进系统后做三件事
应急启动只是让你能进入系统,如果不做固化处理，下一次开机仍然会卡在同样位置，进入系统后按顺序完成以下三项：
第一项：重建GRUB配置
在终端执行以下命令：
- Ubuntu/Debian系的虚拟机：
sudo update-grub- CentOS/RHEL/Fedora系的虚拟机：
sudo grub2-mkconfig -o /boot/grub2/grub.cfg第二项：重装GRUB到磁盘引导区
这一步的目标是让引导记录重新覆盖硬盘的前446字节（传统BIOS模式）或者更新EFI引导项（UEFI模式）。
传统BIOS模式：
sudo grub-install /dev/sdaUEFI模式：
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi注意这里的 /dev/sda 是磁盘设备名，不要在这个参数里加分区编号（例如sda2）。
第三项：确认内核参数是否包含UUID
执行完以下命令查看当前内核启动参数：
cat /proc/cmdline如果输出里没有 root=UUID=... 这种格式而是 root=/dev/sda2，建议手动编辑 /etc/default/grub 中的 GRUB_CMDLINE_LINUX_DEFAULT 行，加入正确的UUID参数后重新运行update-grub，避免后续磁盘变更再次引发同样故障。
虚拟机grub引导修复过程中常遇到的另外两个坑
坑一：磁盘顺序被打乱
插入虚拟磁盘或调整启动顺序之后,原来sda变成sdb是常有的事，如果手动引导过程中 root=/dev/sda2 怎么都不生效，
最直接的办法是在GRUB命令行用search命令代替固定设备号：
search --no-floppy --set=root --fs-uuid 你的分区UUID这个命令可以不去关心sda还是sdb,直接按UUID定位分区，获取UUID的方法是在系统正常启动时执行 lsblk -f，把记得的UUID提前记录在手机或便签上。
坑二：VMware虚拟硬盘的PID/ID冲突
VMware场景下,如果复制过虚拟机或者把虚拟磁盘从一个虚拟机拖到另一个虚拟机，磁盘的SCSI号改变会直接导致GRUB卡在引导头阶段连菜单都显示不出来，处理方式是在.vmx文件中手动编辑添加一行：
scsi0:0.deviceType = "lsilogic"或者尝试把虚拟机的固件类型从UEFI切换为BIOS重启一次（在VMware设置的“虚拟机选项”中找到“引导选项”），切换固件类型的操作需要先备份快照，如果切换后发现无法启动再改回来。
GRUB修复相关场景问答
Q1：虚拟机误入GRUB命令行，试了很多次linux命令总是提示file not found怎么办？
检查两条：一是 /boot 是否独立分区，如果是独立分区，linux指令不要写 /boot/vmlinuz-...，直接写 /vmlinuz-... 试试看，二是确认你用 ls /boot 看到的文件列表里是否真的有带generic后缀的内核文件，有些精简镜像只保留了一个不受支持的内核版本，两条都不能解决问题时，建议在宿主机上挂载虚拟磁盘的vmdk，利用宿主机上的mount操作直接查看根目录文件结构，判断boot文件是否确实存在。
Q2：Linux虚拟机grub引导修复完成后，为什么下一次重启又卡在GRUB？
大概率是刚才手动引导时没有重装grub到磁盘头或者UEFI引导区,确认是否已执行过 grub-install，还有些情况是虚拟机的NVRAM里保存了多个启动项，而GRUB对应的启动项排在后面，进入BIOS设置界面把硬盘类启动项调整到第一位即可。
Q3：双系统或多系统虚拟机的grub修复会更复杂吗？
复杂度差异不大,核心是分清楚哪个分区是 /boot、哪个分区是 ，以及Windows分区里是否保留了EFI引导文件，Linux为主系统的机型建议直接重装GRUB并覆盖引导配置，让GRUB通过 os-prober 自动识别Windows分区生成启动菜单，前提是efi分区里已有Windows的bootmgfw.efi文件，若缺少该文件则需要用Windows安装镜像的修复模式补齐引导文件。