虚拟机显示end是什么原因？
虚拟机开机卡在end界面，本质上是GRUB引导加载程序进入了受限的命令行模式，说明它没能找到启动菜单或内核文件。在很多运维和开发场景里，end并非完整报错，它只是屏幕上最后停留的几个字符，完整的背景往往是“GRUB loading”之后突然黑屏，或者直接跳进一个以“grub>”开头的命令行界面，这种状态业内专家一般称作GRUB Rescue或GRUB Shell，属于引导链断裂的典型症状。
触发end模式的三大常见原因
- 磁盘UUID发生变化：虚拟机的磁盘在克隆、迁移或扩容后，分区的UUID会变掉，但GRUB配置里还写着旧值，导致它找不到根分区。
- 内核或initrd镜像丢失：/boot目录里的vmlinuz或initramfs文件被误删、被安全软件拦截，GRUB尝试读取时直接失败。
- 分区表或启动文件损坏：异常断电、快照回滚不当、磁盘空间写满，都可能让/boot/grub/grub.cfg文件损坏。
行业共识认为,多数情况下卡在end并不是硬盘彻底报废，而是软件层面的引导参数失联，数据通常还在分区里躺着。
虚拟机开机卡在end界面怎么解决？
解决思路分两条路：轻量修复和重建引导，轻量修复适合GRUB还能敲命令的情况，重建引导适合连菜单都出不来的情况，操作前先确认你手上有虚拟机的控制台权限，如果是云平台上的实例，记得用VNC或Web终端接入。
第一步：先确认GRUB能看到哪块磁盘
在“grub>”提示符下输入以下命令，看看GRUB自己能识别出哪些设备：
ls屏幕上会返回类似“(hd0) (hd0,msdos1) (hd0,msdos2)”这样的设备列表，接着逐一查看这些分区的内容：
ls (hd0,msdos1)/如果某个分区里能看到“boot”或“vmlinuz”字样，说明GRUB有希望找到系统，如果所有分区都提示unknown filesystem，那问题就升级到分区表层面了。
第二步：手动指向正确的引导文件
当系统分区明确可见时,可以手动指定根分区和GRUB前缀：
set root=(hd0,msdos1)
set prefix=(hd0,msdos1)/boot/grub
insmod normal
normal执行完最后一行,GRUB应该会重新加载菜单，这个方法对Linux虚拟机特别有效，用完后进入系统，第一件事就是更新GRUB配置，把持久化参数写进配置文件里：
sudo update-grub第三步：使用LiveCD或救援模式重建GRUB
如果手动指定也进不去,说明GRUB核心模块本身出了问题，此时需要挂载一个救援系统，以常见的Ubuntu Server虚拟机为例，你可以在虚拟机设置里挂载一个ISO镜像，从光盘启动后进入“Try Ubuntu”或“Rescue”模式。
进入Live环境后,挂载原系统的根分区和boot分区：
sudo mount /dev/vda1 /mnt
sudo mount /dev/vda2 /mnt/boot然后逐一把系统目录绑定进去,chroot到原系统里：
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt在chroot环境里,重新安装GRUB到虚拟机的启动盘：
grub-install /dev/vda
update-grub执行完毕后,exit退出chroot，reboot重启，这个方法能解决绝大多数虚拟机卡在end界面问题。
VMware环境里的特殊操作路径
如果你用的是VMware Workstation或ESXi，在虚拟机开机时快速按Esc或F2进入BIOS，把启动顺序改回“CD/DVD优先”，再挂载救援ISO，ESXi环境下还可以通过VMware Host Client的“编辑设置”直接挂载ISO镜像，不需要物理接触服务器，这几年虚拟化平台对引导修复的集成度越来越高，但GRUB层面的报错依然依赖手动干预，这一点在简米云、酷番云的云服务器上操作逻辑完全一致，只是把ISO换成了VNC救援模式。
为什么修复后还会再次卡在end？
很多人在修复完第一次后,没过多久又掉进grub>提示符，这种情况多半和虚拟机磁盘的持续变化有关。
克隆和模板部署后遗症
在虚拟化环境中,从模板克隆出来的虚拟机往往带着模板的UUID信息，如果模板制作时没有执行过重新生成initramfs的操作，克隆后每台虚拟机的磁盘信息都是错的，修复时除了重装GRUB，还要在chroot环境里重建initramfs：
sudo update-initramfs -u这样才能把新的磁盘驱动和UUID写进引导镜像。
fstab和引导配置不一致
另一类高发场景是手工给虚拟机磁盘扩容时,fstab里写的分区名和实际分区顺序对不上，比如系统原本用/dev/vda1，扩容后新增了/dev/vda2，重启时GRUB按分区顺序扫描，结果找错了启动镜像，最稳妥的做法是改用UUID来标识分区，在fstab里替换成如下格式：
UUID=xxxxx-xxxx-xxxx / ext4 defaults 0 1快照回滚的隐性风险
VMware和KVM的快照功能偶尔会在回滚时把GRUB的元数据搞乱,比如快照创建于系统更新前，回滚后/boot目录里多出了新内核文件，但GRUB菜单还停留在旧版本，此时建议在系统正常运行状态下手动执行一次：
sudo grub2-mkconfig -o /boot/grub2/grub.cfg让菜单文件和磁盘实际状态强制对齐。
Linux虚拟机vs Windows虚拟机：end现象的区别
虚拟机显示end基本是Linux系统的专利,Windows虚拟机如果引导失败，通常显示的是“Bootmgr is missing”或“An operating system wasn't found”，两者处理路径完全不同，Windows需要进恢复环境用bootrec命令修复：
Bootrec /FixMbr
Bootrec /FixBoot
Bootrec /RebuildBcd而Linux的恢复路径就是我们前面讲的GRUB操作,多数人在网上搜索“虚拟机显示end”，其实目标系统就是CentOS、Ubuntu或Debian这一类Linux发行版，需要注意的是，国产化操作系统如麒麟、统信UOS，底层同样走GRUB引导，修复方法和Debian系一致。
如何用备份策略防止再次卡死？
不要等到屏幕停在end字样才想起数据安全,用快照是最直接的防线，但快照不能替代备份，因为它依赖物理磁盘的健康状态，比较合理的方案是给虚拟机配置独立的备份盘或对象存储，定时做整机备份，比如KVM环境里用virsh命令做计划任务镜像备份：
virsh snapshot-create-as centos7 backup1 --disk-only管理平台的自动化策略里,建议统一开启“备份前静默快照”，确保文件系统处于一致状态，对数据库类的虚拟机，重点备份/var/lib/mysql或者PG的数据目录，而不是整个磁盘，避免恢复时间过长。
| 故障场景 | 故障根因 | 推荐解决方式 |
|---|---|---|
| 克隆虚拟机后卡end | UUID冲突 | 从模板准备阶段重置grub配置 |
| 扩容磁盘后卡end | 分区顺序变化 | 改用UUID挂载分区 |
| 强制断电后卡end | grub.cfg损坏 | LiveCD重装GRUB |
| 升级内核后卡end | 引导菜单文件未更新 | 执行update-grub或grub2-mkconfig |
| 云主机重启后卡end | 热迁移导致设备名称变化 | 重建initramfs |
Q&A：虚拟机end相关问题
虚拟机显示end是硬盘坏了吗？
不是,end提示符是由GRUB程序输出的，说明BIOS固件和GRUB本体都成功加载了，硬盘至少能被识别，真正硬盘损坏的情况下，屏幕只会出现Disk not found或类似的提示，只要能看到grub>提示符，硬盘大概率还活着，优先考虑软件配置修复。
VMware虚拟机卡在end界面，里面的数据库文件还能找回来吗？
可以,GRUB引导失败不会主动格式化分区，数据仍保留在虚拟磁盘中，用救援模式启动后，先把整个虚拟磁盘以只读方式挂载到另一个系统里，用rsync或scp把数据目录拷贝出来，再重装操作系统或修复引导，如果修复过程中执行了错误的dd命令，那数据才有可能真正丢失，所以修复前务必先做磁盘级别的镜像备份。
云端虚拟机显示end，宿主机上没有控制台怎么办？
云平台一般都会提供VNC登录或救援模式入口,打开控制台看到的画面就是虚拟机的真实显示器输出，按前面步骤操作即可，如果控制台都进不去，可以在云平台的安全组配置里临时放行救援系统所需端口，再挂载一个永久数据盘来接收原有磁盘的数据。