RHEL EC2 启动失败与实例状态检查异常排查

EC2 Linux 实例无法启动或实例状态检查失败时，问题可能同时存在于 AWS 控制面和操作系统内部。这个案例里，一部分是 KMS 权限导致加密 EBS 无法解密，另一部分是 /etc/fstab 使用不稳定设备名导致系统进入维护模式。

现象

故障分成两类：

1. 实例启动失败，CloudTrail 中能看到 KMS CreateGrant 或 Decrypt 权限不足。
2. 实例可以尝试启动，但系统日志卡在：

Give root password for maintenance
(or press Control-D to continue):

第二种情况会导致 OS 无法完整启动，实例无法响应底层健康检查，最终表现为实例状态检查异常。

问题一：KMS 权限不足

如果 EBS 卷使用 KMS CMK 加密，启动实例的 IAM 角色必须具备使用该 KMS key 的权限。至少需要：

{
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:CreateGrant"
  ],
  "Resource": "arn:aws-cn:kms:<region>:<account-id>:key/<key-id>"
}

如果角色没有权限，EC2 在启动阶段无法解密系统盘或数据盘，实例就会启动失败。

问题二：fstab 阻塞启动

Linux 上 NVMe 设备名可能随重启或底层变化改变。如果 /etc/fstab 中写死了类似：

/dev/nvme2n1p1 /data ext4 defaults 1 2

当设备名变化或卷不存在时，系统会在启动阶段等待挂载，最终进入 emergency / maintenance 模式。

更稳的写法是用 UUID 并加 nofail：

UUID=<volume-uuid> /data ext4 defaults,nofail 1 2

网络文件系统还应加 _netdev：

server:/share /mnt/share nfs defaults,_netdev,nofail 0 0

通过救援实例修复 fstab

1. 准备救援实例

在同可用区启动一台 Linux 救援实例。停止原实例后，分离原根卷并挂载到救援实例。

2. 挂载原系统根分区

如果原系统使用 LVM，先安装工具并激活卷组：

sudo dnf install lvm2 -y
sudo vgscan
sudo vgchange -ay
sudo lvs

挂载原根分区：

sudo mkdir -p /mnt/rescue
sudo mount -o nouuid /dev/<vg-name>/<root-lv> /mnt/rescue

3. 修改 fstab

sudo vi /mnt/rescue/etc/fstab

先把有风险的数据盘挂载项注释掉，让系统能启动。启动后再用 lsblk -f 获取 UUID，改成稳定配置。

4. 卸载并挂回原实例

sudo umount /mnt/rescue
sudo vgchange -an

然后在控制台把根卷挂回原实例，启动并验证。

验证

实例启动后执行：

lsblk -f
sudo systemctl daemon-reload
sudo mount -a
df -h

mount -a 无报错，说明 fstab 配置基本正常。

总结

EC2 Linux 启动失败要区分两层：

• AWS 控制面：KMS、IAM、EBS 状态、卷挂载关系。
• OS 内部：fstab、LVM、文件系统、网络挂载。

加密卷启动失败优先查 CloudTrail 和 KMS 权限；系统卡维护模式优先查控制台系统日志和 /etc/fstab。数据盘挂载建议统一使用 UUID + nofail，避免设备名变化把系统启动卡死。