如何对因操作系统问题而未能通过实例状态检查的 EC2 Linux 实例进行故障排除？

4 分钟阅读

我的 Amazon Elastic Compute Cloud (Amazon EC2) Linux 实例由于操作系统问题未通过实例状态检查。现在无法成功启动。

简短描述

您的 EC2 Linux 实例可能由于以下原因而未能通过实例状态检查：

更新了内核，但新内核没有启动。
/etc/fstab 中的文件系统条目不正确或文件系统已损坏。
实例上的网络配置不正确。

解决方法

**重要事项：**以下某些过程需要停止实例。实例停止时，会丢失存储在实例存储卷中的数据。停止实例前请保存数据备份。与 Amazon Elastic Block Store（Amazon EBS）支持的卷不同，实例存储卷是临时性的，不支持数据持久化。有关更多信息，请参阅 Stop and start Amazon EC2 instances。

在停止和开始后，Amazon EC2 自动分配给实例的静态公有 IPv4 地址会发生变化。若要保留公有 IPv4 地址，让其在停止实例后不会发生变化，请使用弹性 IP 地址。

**注意：**以下方法使用的是基于 Amazon Linux 2 的示例。但是，这些概念通常适用于 Linux 发行版。如果您的 Linux 发行版不是 Amazon Linux 2，则命令、路径和输出可能会有所不同。

使用适用于 Linux 实例的 EC2 Serial Console

如果您启用了适用于 Linux 实例的 EC2 Serial Console，则可以使用它对支持的基于 Nitro 的实例类型和裸机实例进行故障排除。Serial Console 可帮助您排查启动问题、网络和 SSH 配置问题。Serial Console 无需有效的网络连接即可连接到您的实例。使用 Amazon EC2 控制台或 AWS 命令行界面（AWS CLI）访问 Serial Console。

首次使用 EC2 Serial Console 时，请在连接之前查看先决条件并配置访问权限。

如果实例无法访问且未配置对 Serial Console 的访问权限，请参阅 Run the EC2Rescue for Linux tool 部分。或参阅 Use a rescue instance。有关配置适用于 Linux 实例的 EC2 Serial Console 的信息，请参阅 Configure access to the EC2 serial console。

**注意：**如果在运行 AWS CLI 命令时收到错误，请参阅排查 AWS CLI 错误。此外，确保您使用的是最新版本的 AWS CLI。

运行 EC2Rescue for Linux 工具

EC2Rescue for Linux 可对无法访问的实例自动诊断并故障排除其操作系统。有关详细信息，请参阅如何使用 EC2Rescue for Linux 排查操作系统级问题？

使用救援实例手动更正错误

在虚拟私有云（VPC）中启动新的 EC2 实例。使用与受损实例相同的亚马逊机器镜像（AMI）和可用区。该新实例将成为您的救援实例。

或者，使用现有实例。现有实例必须使用相同的 AMI，并且与您的受损实例位于同一个可用区中。
停止受损实例。
从受损实例分离 Amazon EBS 根卷（/dev/xvda 或 /dev/sda1）。记下根卷的设备名称。
附加该卷，将其作为辅助设备 (/dev/sdf) 附加到救援实例。
通过 SSH 连接到救援实例。
为附加到救援实例的新卷创建挂载点目录（/rescue）：
```
$ sudo mkdir /rescue
```
将卷挂载到新目录：
```
$ sudo mount /dev/xvdf1 /rescue
```
如果收到错误，例如 “Wrong Fs type or UUID duplicate, Superblock is missing or badblock found” 等，请参阅为什么我无法挂载自己的 Amazon EBS 卷？

注意：设备 (/dev/xvdf1) 可能使用不同的设备名称附加到救援实例。允许 lsblk 命令查看可用磁盘设备及其挂载点，以确定正确的设备名称。
如果尚未执行此操作，请检索实例的系统日志以验证错误。后续步骤取决于系统日志中列出的错误消息。

以下汇总了导致实例状态检查失败的常见错误。有关更多错误，请参阅 Troubleshoot system log errors for Linux-based instances。

排查“内核崩溃”

如果系统日志中出现内核崩溃错误消息，则内核可能缺少 vmlinuz 或 initramfs 文件。成功启动必需要有 vmlinuz 和 initramfs 文件。

运行以下命令：

cd /rescue/boot
ls -l

检查输出，验证是否存在与要启动的内核版本相对应的 vmlinuz 和 initramfs 文件。

以下输出示例适用于内核版本为 4.14.165-131.185.amzn2.x86_64 的 Amazon Linux 2 实例。/boot 目录包含 initramfs-4.14.165-131.185.amzn2.x86_64.img 和 vmlinuz-4.14.165-131.185.amzn2.x86_64 文件，因此会启动成功。

uname -r
4.14.165-131.185.amzn2.x86_64

cd /boot; ls -l
total 39960
-rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
drwx------ 5 root root       79 Feb 12 04:08 grub2
-rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
-rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
-rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
-rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
-rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

如果 initramfs 和 vmlinuz 文件不存在，请尝试使用含有这两个文件的旧内核启动实例。有关说明，请参阅当因为更新导致 Amazon EC2 实例无法成功重启时，如何恢复到已知的稳定内核？
运行 umount 命令，将辅助设备从救援实例中卸载：
```
$ sudo umount /rescue
```
如果卸载操作不成功，则可能需要停止或重启救援实例才能完全卸载。
将辅助卷（/dev/sdf）与救援实例分离。然后，将其作为 /dev/xvda（根卷）挂载到原始实例。
启动实例，然后验证该实例是否响应。

有关解决内核崩溃错误的更多信息，请参阅为什么在升级内核或重启 EC2 Linux 实例后，我看到“内核崩溃”错误？

排查“挂载失败”或“依赖项失败”

系统日志中的“挂载失败”或“依赖项失败”等错误表明 /etc/fstab 文件中的挂载点条目不正确。

验证 /etc/fstab 中的挂载点条目是否正确。要更正 /etc/fstab 文件条目，请参阅为什么在尝试启动 EC2 Linux 实例时，它会进入紧急模式？

最佳做法是运行 fsck 或 xfs\ _repair 工具来纠正文件系统中的不一致之处。

**注意：**运行 fsck 或 xfs_repair 工具之前，请先创建文件系统的备份。

运行 fsck 或 xfs_repair 工具之前，请先运行 umount 命令卸载挂载点：

$ sudo umount /rescue

根据文件系统，运行 fsck 或 xfs_repair 工具。

对于 ext4 文件系统，运行以下命令：

$ sudo fsck /dev/sdf
fsck from util-linux 2.30.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdf: clean, 11/6553600 files,
459544/26214400 blocks

对于 XFS 文件系统，运行以下命令：

$ sudo xfs_repair /dev/sdf
xfs_repair /dev/xvdf
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

将辅助卷（/dev/sdf）与救援实例分离。然后，将其作为 /dev/xvda（根卷）挂载到原始实例。
启动实例，然后验证该实例是否响应。

排查“接口 eth0: 失败”

验证 ifcfg-eth0 文件的网络条目是否正确。与主接口 eth0 对应的网络配置文件位于 /etc/sysconfig/network-scripts/ifcfg-eth0。如果主接口的设备名称不是 eth0，则文件名会以 ifcfg 开头，后面才是设备名称。该文件位于实例的 /etc/sysconfig/network-scripts 目录中。

运行 cat 命令查看主接口 eth0 的网络配置文件。

以下是位于 /etc/sysconfig/network-scripts/ifcfg-eth0 的网络配置文件的正确条目。

**注意：**如有需要，请将以下命令中的 eth0 替换为主接口的名称。

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no

验证 ONBOOT 是否设置为 yes。如果 ONBOOT 未设置为 yes，则 eth0（或您的主网络接口）未配置为随系统启动打开。

要更改 ONBOOT 值，请先在编辑器中打开该文件。此示例使用的是 vi 编辑器：
```
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
```
按 I 插入。

将光标滚动到 ONBOOT 条目，然后将该值更改为 yes。

要保存并退出该文件，请按 :wq!
运行 umount 命令，将辅助设备从救援实例中卸载：
```
$ sudo umount /rescue
```
如果卸载操作不成功，则可能需要停止或重启救援实例才能完全卸载。
将辅助卷（/dev/sdf）与救援实例分离。然后，将其作为 /dev/xvda（根卷）挂载到原始实例。
启动实例，然后验证该实例是否响应。