为什么当我尝试启动 EC2 Linux 实例时,它进入紧急模式?

3 分钟阅读
0

当我启动 Amazon Elastic Compute Cloud(Amazon EC2)Linux 实例时,该实例会进入紧急模式,启动过程失败。然后,该实例无法访问。

简短描述

由于以下原因,实例可能会以紧急模式启动:

  • 实例上的内核已损坏。
  • 由于 /etc/fstab 文件中的条目不正确,自动挂载失败。

如需验证错误类型,请查看实例的控制台输出。如果内核损坏,您可能会在控制台输出中看到 Kernel panic 错误消息。如果自动挂载失败,则控制台输出中会显示 Dependency failed 消息。

解决方法

Kernel panic 错误

如果 grub 配置或 initramfs 文件损坏,则会出现 Kernel panic 错误消息。如果内核存在问题,您可能会在控制台输出中看到“Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)”错误。

要解决 Kernel panic 错误,请执行下列操作:

1.将内核恢复为以前的稳定内核。有关如何恢复为之前内核的说明,请参阅当更新导致 Amazon EC2 实例无法成功重启后,如何恢复到已知的稳定内核?

2.在恢复为之前的内核后,重启实例。然后,纠正损坏的内核上的问题。

依赖项失败错误

如果由于 /etc/fstab 文件中的语法错误而导致自动挂载失败,则实例将进入紧急模式。此外,如果文件中列出的 Amazon Elastic Block Store(Amazon EBS)卷与实例分离,则实例启动过程可能会进入紧急模式。如果出现上述任一问题,则控制台输出看起来类似于以下内容:

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

前面的示例日志消息显示,/mnt 挂载点在启动序列期间未能成功挂载。

为防止启动序列因挂载失败而进入紧急模式,请将以下内容添加到 /etc/fstab 文件中。

  • 在辅助分区(上例中的 /mnt)的 /etc/fstab 文件中添加 nofail 选项。存在 nofail 选项时,即使任何卷或分区挂载失败,启动序列也不会发生中断。
  • 0 添加为相关挂载点的 /etc/fstab 文件的最后一列。0 列会关闭文件系统检查,实例成功启动。

您可以使用三种方法来更正 /etc/fstab 文件。

重要事项:

方法 2 和 3 需要停止并启动实例。请注意以下几点:

  • 当实例停止时,存储在实例存储卷中的数据会丢失。在停止实例之前,请务必保存数据备份。与 EBS 支持的卷不同,实例存储卷是临时性的,不支持数据持久化。
  • Amazon EC2 在启动或开始时自动分配给实例的静态公有 IPv4 地址在停止和开始后会发生变化。要保留在实例停止后不会更改的公有 IPv4 地址,请使用弹性 IP 地址

有关详细信息,请参阅停止实例时发生的情况

方法 1: 使用 EC2 Serial Console

如果您启用了适用于 Linux 的 EC2 Serial Console,则可以使用它来对支持的基于 Nitro 的实例类型裸机实例进行故障排除。您可以使用 Amazon EC2 控制台或 AWS 命令行界面(AWS CLI)来访问 Serial Console。使用 EC2 Serial Console 时,无需有效的连接即可连接到您的实例。

**注意:**如果您之前未使用过 EC2 Serial Console,请务必在尝试连接之前查看先决条件配置访问权限。如果您的实例无法访问,并且您尚未配置对 Serial Console 的访问权限,请按照方法 2 或方法 3 中的说明进行操作。

1.打开 Amazon EC2 控制台

2.选择实例

3.选择实例,然后依次选择操作监控和故障排除EC2 Serial Console连接

-或-

选择实例,然后依次选择连接EC2 Serial Console连接

此时将在浏览器内打开终端窗口。

4.按 Enter。如果您连接到 Serial Console,系统会返回登录提示符。如果屏幕仍然黑屏,请使用以下信息来帮助解决连接到 Serial Console 时出现的问题:

5.在登录提示符处,输入您之前设置的基于密码用户的用户名,然后按 Enter

6.在密码提示符处,输入密码,然后按 Enter

您现在已登录该实例,可以使用 EC2 Serial Console 进行故障排除。

您也可以使用自己的密钥和 SSH 客户端进行连接

有关使用 EC2 Serial Console 的详细信息,请参阅连接到 EC2 Serial Console

方法 2: 运行 AWSSupport-ExecuteEC2Rescue 自动化文档

如果您的实例配置了 AWS Systems Manager,则您可以运行 AWSSupport-ExecuteEC2Rescue 自动化文档来纠正启动问题。使用这种方法时不需要手动干预。有关使用自动化文档的信息,请参阅在无法访问的实例上运行 EC2Rescue 工具

方法 3: 使用救援实例手动编辑文件

1.打开 Amazon EC2 控制台

2.选择实例,然后选择处于紧急模式的实例。

3.停止实例

4.从已停止的实例分离 Amazon EBS 根卷/dev/xvda/dev/sda1)。

5.在受损实例所在的可用区中启动新的 EC2 实例。该新实例将成为您的救援实例。

6.将您在第 4 步中分离的根卷作为辅助设备挂载到救援实例。

**注意:**在挂载辅助卷时,您可以使用不同的设备名称。

7.使用 SSH 连接到救援实例

8.为您在第 6 步中附加到救援实例的新卷创建挂载点目录。在以下示例中,挂载点目录为 /mnt/rescue

$ sudo mkdir /mnt/rescue

9.将该卷挂载到您在第 8 步中创建的目录。

$ sudo mount /dev/xvdf /mnt/rescue

**注意:**可以用不同的设备名称将设备(上例中为 /dev/xvdf)挂载到救援实例。使用 lsblk 命令查看可用磁盘设备及其挂载点,以确定正确的设备名称。

10.挂载卷后,请运行下列命令打开 /etc/fstab 文件。

$ sudo vi /mnt/rescue/etc/fstab

11.根据需要编辑 /etc/fstab 中的条目。以下示例输出显示使用 UUID 定义的三个 EBS 卷,两个辅助卷都添加了 nofail 选项,并且每个条目的最后一列都为 0

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.保存文件,然后运行 umount 命令来卸载卷。

$ sudo umount /mnt/rescue

13.从临时实例分离该卷

14.将卷挂载到原始实例,然后启动该实例以确认其启动成功。

AWS 官方
AWS 官方已更新 8 个月前