Ubuntu 22.04.1虚拟机在ESXi集群故障演练后LVM卷无法加载导致启动失败

阿华AIGC实验室

2026-4-20

这种故障确实让人头疼，尤其是Zabbix作为核心监控服务器挂了，排查起来更急。从你描述的整个过程来看，核心问题出在系统启动时initramfs无法识别LVM卷，后续换内核出现的/boot挂载问题是衍生问题，我们一步步来梳理解决思路：

一、先解决最初的initramfs无法识别LVM卷问题

你用Live CD能正常挂载LVM卷，说明磁盘和LVM本身没问题，大概率是initramfs镜像缺失了LVM相关模块，或者镜像损坏。可以按以下步骤修复：

用Ubuntu Live CD启动虚拟机，挂载系统分区和boot分区：

# 先激活LVM卷组
vgchange -ay
# 挂载根分区
mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt
# 挂载boot分区
mount /dev/sda2 /mnt/boot
# 挂载必要的系统目录
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

进入chroot环境：
```
chroot /mnt
```
重新生成原内核（5.15.0-91-generic）的initramfs镜像，确保包含LVM模块：
```
update-initramfs -u -k 5.15.0-91-generic
# 同时更新grub配置
update-grub
```
退出chroot，重启虚拟机，试试用原内核启动。

二、解决新内核（6.2.0-26-generic）的/boot挂载问题

你换内核后出现的UUID超时，大概率是fstab里的/boot UUID和实际磁盘的UUID不匹配，或者新内核下磁盘的UUID识别有问题：

用Live CD或者应急模式登录后，执行blkid查看/dev/sda2的UUID，对比fstab里的UUID是否一致：
```
blkid /dev/sda2
cat /etc/fstab
```
如果UUID不一致，修改fstab里的/boot挂载项，替换成正确的UUID；或者直接用设备路径/dev/sda2来挂载/boot，避免UUID识别问题：
```
# 编辑fstab
nano /etc/fstab
# 把原/boot的UUID行改成：
/dev/sda2 /boot ext4 defaults 0 2
```

然后重新生成新内核的initramfs：

update-initramfs -u -k 6.2.0-26-generic
update-grub

重启后应该能正常挂载/boot，再排查网络问题：如果是用静态IP，检查/etc/netplan下的配置文件；如果是DHCP，重启NetworkManager或者systemd-networkd服务。

三、对比新旧备份的差异（关键排查点）

你有8月的正常备份，这是很好的排查资源，可以从以下几个方面对比：

对比initramfs内容：分别在两个系统里执行lsinitramfs /boot/initrd.img-5.15.0-91-generic | grep lvm，看正常系统和故障系统的initramfs里是否都包含lvm2相关模块（比如lvm2、dm_mod等）。如果故障系统缺失，说明是initramfs生成时的问题。
对比grub启动参数：查看两个系统的/boot/grub/grub.cfg，找到对应内核的启动项，对比linux行的参数，比如正常系统是否有rd.lvm.lv=ubuntu-vg/ubuntu-lv或者lvm=wait这类参数，故障系统是否缺失。
对比磁盘识别相关配置：检查/etc/udev/rules.d下的自定义规则，以及/etc/modules、/etc/initramfs-tools/modules里的模块加载配置，看故障系统是否有异常的配置。
检查ESXi虚拟机配置：对比正常备份恢复后的虚拟机和故障虚拟机的磁盘控制器类型（比如是LSI Logic SAS还是VMware Paravirtual）、磁盘的SCSI ID，故障演练后ESXi可能自动调整了这些配置，导致系统识别磁盘异常。