虚拟机扩展根分区后系统无法启动，多半是分区表或引导配置没有同步更新，不用着急重装系统，通过救援模式重新挂载分区并重建引导即可恢复。
虚拟机根分区扩容后无法引导，常见原因是什么？
虚拟机扩容根分区,听起来只是多加几GB空间，但实际操作中很容易踩坑，导致开机失败的原因主要有三种：分区表变化、根分区UUID改变、引导加载器配置失效。
扩展分区时操作中断或顺序错误
有相当一部分朋友是在VMware或KVM管理界面把硬盘容量调大,然后直接在运行中的系统里用fdisk去扩展根分区，如果执行顺序不对，比如先删除了原有分区再创建新分区，分区起始位置一旦改变，GRUB就找不到原来的/boot分区，系统自然起不来，更糟的是，如果resize过程意外断电，文件系统元数据损坏，也会直接卡在启动界面。
根分区UUID变化导致挂载失败
Linux系统通过UUID识别分区,/etc/fstab里写的是旧UUID，扩容时如果用parted等工具改动了分区表，分区的UUID会重新生成，系统引导阶段挂载根分区时发现对不上，就会报错，这类故障的特征是启动信息里出现“Failed to mount /”或“UUID=xxx does not exist”之类的提示。
GRUB引导配置仍指向旧分区
即使分区没有重建,只是单纯扩大了容量，有些发行版的GRUB配置也可能固化了旧的根分区路径，特别是手动安装的双系统或多系统环境，/boot/grub2/grub.cfg里的root=参数还指向老分区，扩容后则因为分区表偏移而失效。
虚拟机根分区扩容后启动不了的修复步骤
不管是什么原因,修复思路是固定的：进入救援环境，找到真实系统所在分区，挂载并chroot进去，然后更新fstab和GRUB，下面分步操作。
第一步：挂载系统镜像，进入救援模式
以CentOS/RHEL系列为例，把安装光盘ISO挂载到虚拟光驱，开机从光盘启动，在引导菜单选择Troubleshooting，再选Rescue a CentOS system，提示是否检测并挂载Linux分区时，选择continue，系统会尝试把根分区挂载到/mnt/sysimage，如果检测不到，先手动分区，进入shell后再操作。
第二步：检查当前分区表和系统分区位置
在救援模式shell里,运行fdisk -l /dev/sda查看分区情况，确认新扩展的分区是否存在，以及原来的根分区是哪个，再用blkid查看分区的UUID，对比系统内/etc/fstab里的记录，这一步能快速定位是不是UUID问题。
实际操作中,你可能看到类似这样的输出：
- /dev/sda1：200MB，类型为Linux的文件系统，挂载在/boot
- /dev/sda2：200GB，类型为LVM或ext4，这就是根分区所在
注意分区的起始柱面是否和扩容前一致,如果fdisk里显示的起止扇区和之前不一样，说明分区表已经被破坏，修复起来会更麻烦。
第三步：挂载原系统并写入正确配置
如果系统没有自动挂载到/mnt/sysimage，可以手动挂载，先挂载根分区，比如mount /dev/sda2 /mnt/sysimage，再挂载/boot、/proc、/dev等必要目录，然后使用chroot /mnt/sysimage进入原系统。
进入后执行vi /etc/fstab，把根分区和/boot分区的UUID改成blkid里看到的实际值，或者直接改成/dev/设备路径（不推荐但临时可用），如果GRUB配置里的root参数还是旧的，一并修改。
挂载顺序有讲究：必须先挂好根分区，再挂载/boot，否则chroot后看不到引导文件，对于LVM结构的系统，还要先激活逻辑卷，vgchange -ay。
第四步：重建GRUB引导和initramfs
在chroot环境中,重新生成GRUB配置：
- CentOS/RHEL：grub2-mkconfig -o /boot/grub2/grub.cfg
- Ubuntu/Debian：update-grub
然后把引导信息安装到磁盘：
- grub2-install /dev/sda（CentOS系）
- grub-install /dev/sda（Debian系）
接着重建initramfs,CentOS 7以上可以用dracut命令：
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
Ubuntu可以写：
update-initramfs -u
完成后退出chroot,重启虚拟机，系统应该就能正常起来了，如果重启后仍无法进入，多半是文件系统本身有损坏，需要执行fsck检查。
不同虚拟化平台的扩容操作差异
虚拟机底层磁盘格式不同,扩容手法也有区别，如果物理机扩容，可能还要调整BIOS里的磁盘顺序，虚拟机相对简单，但依然有平台差异。
VMware vSphere环境下的扩容
VMware的虚拟磁盘可以热扩容,但扩容后系统内看到的还是旧分区大小，推荐使用growpart命令自动扩容分区，而不是手动删分区，在vSphere里，先编辑虚拟机设置，把硬盘大小增加，然后到系统里运行growpart /dev/sda 2，再resize2fs /dev/sda2（xfs用xfs_growfs），这样分区起始位置不变，引导不会失效，行业共识认为VMware vSphere的SCSI磁盘兼容性最好，基本不会出现平台导致的引导问题。
KVM/QEMU环境下的扩容
KVM通常用qcow2镜像,扩容命令为qemu-img resize example.qcow2 +50G，注意扩容前虚拟机必须关机，否则镜像格式可能崩溃，扩容后启动虚拟机，你会发现磁盘大小变了，但分区没变，同样用growpart和文件系统扩容命令操作，KVM下要注意磁盘总线类型，virtio和IDE的引导方式略有差异，修复时先确认驱动是否加载成功。
Hyper-V环境下的扩容
Hyper-V支持VHDX固定或动态磁盘，扩容路径在虚拟机设置里选择硬盘编辑，如果虚拟机内用的是标准MBR分区，Hyper-V扩容后可能无法在系统里直接扩展超过2TB的根分区，需要转换成GPT，这个转换过程很容易破坏引导，建议先备份再操作。
对比来看,虚拟机扩容比物理机灵活，但根分区扩容后的引导修复逻辑完全相同，虚拟机扩展磁盘后开机黑屏怎么解决？黑屏通常意味着GRUB没加载显卡驱动，或DMRAID之类模块出问题，排查思路还是从救援模式入手，检查显示输出和日志。
如何避免虚拟机扩容后启动失败？预防胜于修复
每一次扩容都是一次手术,不做检查就重启绝对不推荐，预防措施能省掉大量救火时间。
扩容前先打快照或备份关键文件
大多数虚拟机平台都支持在线快照,扩容前制作一个快照，失败了rollback就回来了，堪称后悔药，没有快照的话，至少把/boot、/etc/fstab、/etc/default/grub这几个文件备份到外部存储。
用growpart自动扩展分区，不要手动删除重建
growpart是cloud-utils里的工具，会自动计算分区安全边界，避免因分区偏移导致引导失效，操作顺序：在管理界面扩容磁盘，启动进入系统，先growpart，再resize文件系统，这个顺序不能颠倒。
扩容后先检查再重启
在重启之前,运行blkid查看所有分区UUID，与/etc/fstab做对比；运行grub2-mkconfig重新生成引导配置，这些步骤做足，才能保证重启万无一失。
还可以顺带检查一下磁盘的剩余空间和inode数量,有些时候扩容后的文件系统虽然能挂载，但因为ext4保留了5%的reserved blocks，用户看到的可用容量比预期小，这属于正常现象。
关于成本问题,虚拟机扩容要花多少钱？在私有云环境下，扩容只是本机磁盘操作，没有额外费用；公有云平台则按存储GB/月计费，比如华北区通用型云主机增加100GB数据盘，月费用大约几十元不等，但这部分费用和修复操作本身没有关系，不需要额外付费找人处理。
常见问题：虚拟机扩容后无法启动相关解答
虚拟机扩容后卡在grub rescue界面怎么办？
grub rescue表明GRUB加载了主引导记录，但找不到配置文件或/boot分区，在grub rescue输入ls，列出所有分区，逐个ls查看哪个有boot/grub，假设分区为(hd0,msdos2)，依次执行set root=(hd0,msdos2)、set prefix=(hd0,msdos2)/boot/grub、insmod normal、normal，就能进入系统，进入后必须重新安装GRUB，否则下次重启还会卡住。
根分区扩展后系统无法启动，数据还在吗？
只要没有执行格式化或删除分区,数据都在，修复引导时要注意，救援模式默认把根分区挂载为只读，需要手动以rw方式重新挂载，避免写入操作失败，挂载命令示例：mount -o remount,rw /mnt/sysimage，数据安全恢复后，再考虑引导修复。
虚拟机扩容失败可以回滚吗？
如果扩容前创建了快照,可以直接使用快照回滚，恢复到扩容前的状态，这是最快的方案，没有快照时，用前面讲的救援模式修复，成功率也相当高，业内专家指出，快照并非万能，如果虚拟机和快照文件存放在同一存储上，存储损坏会导致快照一起失效，因此关键业务还应额外保留离线备份。
无论你是虚拟化新手还是老运维,碰到虚拟机扩展根分区后无法启动，先别慌，先分区、后文件系统、再引导”的流程，利用救援模式修复，就能把损失降到最低。