如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 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 序列主控台

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

如果您第一次使用 EC2 序列主控台，請確保先檢閱先決條件並設定存取權，然後再嘗試連線。

如果您的執行個體無法連線，而且您並未設定序列主控台的存取權，請遵循執行適用於 Linux 的 EC2Rescue 工具或使用救援執行個體中的指示進行操作。如需有關設定適用於 Linux 執行個體的 EC2 序列主控台的資訊，請參閱設定 EC2 序列主控台的存取權。

注意： 如果您在執行 AWS CLI 命令時收到錯誤訊息，請確保您使用的是最新版本的 AWS CLI。

執行適用於 Linux 的 EC2Rescue 工具

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

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

1. 在您的虛擬私有雲端 (VPC) 中啟動新的 EC2 執行個體。使用與受損執行個體相同的 Amazon Machine Image (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 重複、Superblock 遺失或找到錯誤區塊，請參閱為什麼我無法掛載 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 工具之前，先執行 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

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 設定為 yes，如上一個範例所示。如果 ONBOOT 未設定為 yes，則 eth0 (或您的主要網路介面) 未組態為在啟動時出現。

若要變更 ONBOOT 值，請執行以下操作：

在編輯器中開啟檔案。在此範例中，會使用 vi 編輯器。

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

按 I 鍵以插入。

將游標捲動至 ONBOOT 項目，然後將值變更為 yes。

儲存並按 :wq! 結束檔案。

3. 執行 umount 指令，從救援執行個體取消掛載次要裝置：

$ sudo umount /rescue

如果取消掛接作業不成功，您可能必須停止或重新啟動救援執行個體，以啟用全新取消掛接。

4. 將次要磁碟區 (/dev/sdf) 從救援執行個體分離，然後將該磁碟區作為 /dev/xvda (根磁碟區) 連接至原始執行個體。

5. 啟動執行個體，然後確認執行個體是否有回應