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

4 分钟阅读

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

简短描述

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

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

解决方法

有三种方法可以对操作系统问题进行故障排除。

**重要事项：**以下某些过程需要停止实例。实例停止时，存储在实例存储卷中的数据会丢失。停止实例之前，请务必保存数据备份。与 Amazon Elastic Block Store（Amazon EBS）支持的卷不同，实例存储卷是临时性的，不支持数据持久化。

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

有关详细信息，请参阅如果停止实例会怎么样。

使用适用于 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 的访问权限，请按照运行 EC2Rescue for Linux 工具或使用救援实例中的说明进行操作。有关配置适用于 Linux 实例的 EC2 Serial Console 的信息，请参阅配置 EC2 Serial Console 的访问权限。

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

运行 EC2Rescue for Linux 工具

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

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

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

或者，使用现有实例。现有实例必须使用相同的 AMI，并且与您的受损实例位于同一个可用区中。

2. 停止受损实例。

3. 将 Amazon Elastic Block Store (Amazon EBS) 根卷（/dev/xvda 或 /dev/sda1）从受损实例中分离出来。记下根卷的设备名称（/dev/xvda 或 /dev/sda1）。

4. 将卷作为辅助设备 (/dev/sdf) 附加到救援实例。

5. 使用 SSH 连接到救援实例。

6. 为附加到救援实例的新卷创建挂载点目录 (/rescue)：

$ sudo mkdir /rescue

7. 将卷挂载到新目录：

$ sudo mount /dev/xvdf1 /rescue

如果您收到错误，例如，Fs 类型错误或 UUID 重复、缺少超级块或发现了坏块等，请参阅为什么无法挂载 Amazon EBS 卷？

注意：设备 (/dev/xvdf1) 可能使用不同的设备名称附加到救援实例。使用 lsblk 命令查看可用磁盘设备及其挂载点，以确定正确的设备名称。

8. 如果尚未执行此操作，请检索实例的系统日志以验证错误。后续步骤取决于系统日志中列出的错误消息。下表汇总了导致实例状态检查失败的常见错误。如需了解其他错误，请参阅对基于 Linux 的实例的系统日志错误进行故障排除。

内核崩溃

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

1. 运行以下命令：

cd /rescue/boot
ls -l

2. 检查输出，验证是否存在与要启动的内核版本相对应的 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

3. 如果 initramfs 和/或 vmlinuz 文件不存在，请尝试使用包含这两个文件的旧内核启动实例。有关如何使用旧内核启动实例的说明，请参阅当更新导致 Amazon EC2 实例无法成功重启后，如何恢复到已知的稳定内核？

4. 运行 umount 命令，将辅助设备从救援实例中卸载：

$ sudo umount /rescue

如果卸载操作不成功，则可能需要停止或重启救援实例才能完全卸载。

5. 将辅助卷 (/dev/sdf) 从救援实例中分离，然后将其作为 /dev/xvda（根卷）附加到原始实例。

6. 启动实例，然后验证实例是否响应。

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

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

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

1. 验证 /etc/fstab 中的挂载点条目是否正确。有关更正 /etc/fstab 文件条目的信息，请参阅为什么当我尝试启动 EC2 Linux 实例时，它进入紧急模式？的由于 /etc/fstab 文件中包含不正确条目，导致自动挂载失败部分。

2. 最佳做法是运行 fsck 或 xfs_repair 工具来更正任何文件系统错误。如果文件系统中存在不一致之处，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

3. 将辅助卷 (/dev/sdf) 从救援实例中分离，然后将其作为 /dev/xvda（根卷）附加到原始实例。

4. 启动实例，然后验证实例是否响应。

调出接口 eth0: 失败

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

1. 运行 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

2. 如前面的示例所示，验证 ONBOOT 是否设置为是。如果 ONBOOT 没有设置为是，则 eth0（或您的主网络接口）未配置为随系统启动打开。

请执行以下操作，更改 ONBOOT 的值：

在编辑器中打开文件。本示例中使用的是 vi 编辑器。

$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

按“I”插入。

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

按 :wq! 保存并退出文件

3. 运行 umount 命令，将辅助设备从救援实例中卸载：

$ sudo umount /rescue

如果卸载操作不成功，则可能需要停止或重启救援实例才能完全卸载。

4. 将辅助卷 (/dev/sdf) 从救援实例中分离，然后将其作为 /dev/xvda（根卷）附加到原始实例。

5. 启动实例，然后验证该实例是否响应