如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 EC2 Linux 執行個體進行疑難排解？

4 分的閱讀內容

由於作業系統出現問題，我的 Amazon Elastic Compute Cloud (Amazon EC2) Linux 執行個體未能通過執行個體狀態檢查。現在無法成功啟動。

簡短描述

由於下列原因，您的 EC2 Linux 執行個體可能未通過執行個體狀態檢查：

您更新了核心程序，但新的核心程序沒有啟動。
/etc/fstab 中的檔案系統項目不正確或檔案系統已損毀。
執行個體上的網路組態不正確。

解決方法

**重要：**下列部分程序需要停止執行個體。在停止執行個體時，您會遺失儲存在執行個體存放區磁碟區中的資料。在停止執行個體之前，請儲存資料的備份。與 Amazon Elastic Block Store (Amazon EBS) 支援的磁碟區不同，執行個體儲存體磁碟區是暫時性的，不支援資料持續性。如需詳細資訊，請參閱停止並啟動 Amazon EC2 執行個體。

Amazon EC2 自動指派給執行個體的靜態公用 IPv4 地址，在停止並啟動後變更。若要保留在執行個體停止時不會變更的公用 IPv4 地址，請使用彈性 IP 地址。

**注意：**下列方法使用以 Amazon Linux 2 為基礎的範例。但是，這些概念一般適用於 Linux 發行版。如果您使用 Amazon Linux 2 以外的 Linux 發行版，則命令、路徑和輸出可能會有所不同。

使用適用於 Linux 執行個體的 EC2 序列主控台

如果您已開啟適用於 Linux 執行個體的 EC2 序列主控台，則可以將其用于對受支援的 Nitro 型執行個體類型和裸機執行個體進行疑難排解。序列主控台可協助您針對啟動問題、網路和 SSH 組態問題進行疑難排解。序列主控台無需正常運作中的網路連線即可連線至您的執行個體。若要存取序列主控台，請使用 Amazon EC2 主控台或 AWS Command Line Interface (AWS CLI)。

第一次使用 EC2 序列主控台時，請先檢閱先決條件並設定存取權，然後再連線。

如果您的執行個體無法連線，且您尚未設定序列控制台的存取權，請參閱執行適用於 Linux 的 EC2Rescue 工具一節。或者，參閱使用救援執行個體。若要設定適用於 Linux 執行個體的 EC2 序列主控台，請參閱設定 EC2 序列主控台的存取權。

**注意：**如果您在執行 AWS CLI 命令時收到錯誤，請參閱對 AWS CLI 錯誤進行疑難排解。此外，請確定您使用的是最新的 AWS CLI 版本。

執行適用於 Linux 的 EC2Rescue 工具

適用於 Linux 的 EC2Rescue 可自動診斷無法存取的執行個體上的作業系統並進行疑難排解。如需詳細資訊，請參閱如何使用適用於 Linux 的 EC2Rescue 對作業系統層級問題進行疑難排解？

使用救援執行個體手動修正錯誤

在您的虛擬私有雲端 (VPC) 中啟動新的 EC2 執行個體。使用與受損執行個體相同的 Amazon Machine Image (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 命令以檢視可用的磁碟裝置及其掛接點。
如果您尚未擷取執行個體的系統日誌，請擷取以確認錯誤。接下來的步驟取決於系統日誌中列出的錯誤訊息。

以下是導致執行個體狀態檢查失敗的常見錯誤清單。如需更多錯誤，請參閱對基於 Linux 的執行個體的系統日誌錯誤進行疑難排解。

對「核心程序危急」進行疑難排解

如果系統日誌中有核心程序危急錯誤訊息，則表示核心程序可能沒有 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 工具之前，先執行 unmount 命令來取消掛接您的掛接點：

$ 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 (根磁碟區) 附加至原始執行個體。
啟動執行個體，然後確認執行個體是否有回應。