Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 EC2 Linux 執行個體進行疑難排解？
由於作業系統出現問題，我的 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) 附加至救援執行個體。
-
為附加至救援執行個體的新磁碟區建立一個掛接點目錄 (/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 (根磁碟區) 附加至原始執行個體。
-
啟動執行個體，然後確認執行個體是否有回應。
相關資訊
相關內容
- 已提問 2 年前
- 已提問 2 年前
- 已提問 3 年前
- 已提問 2 年前
- AWS 官方已更新 10 個月前
