在我嘗試啟動 EC2 Linux 執行個體時，為什麼它會進入緊急模式？

簡短描述

執行個體可能因下列原因而以緊急模式啟動：

• 執行個體上有損壞的核心。
• 由於 /etc/fstab 檔案中的項目不正確而導致自動掛載失敗。

若要驗證錯誤類型，請檢視執行個體的主控台輸出。如果核心受損，您可能會在主控台輸出中看到核心危急錯誤訊息。如果發生自動掛載失敗，則主控台輸出中會出現相依性失敗訊息。

解決方法

核心危急錯誤

當 grub 組態或 initramfs 檔案受損時，就會發生核心危急錯誤訊息。如果核心存在問題，您可能會在主控台輸出中看到錯誤「Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)」。

若要解決核心危急錯誤：

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 序列主控台

如果您已開啟適用於 Linux 的 EC2 序列主控台，則可以使用它來對支援的 Nitro 型執行個體類型和裸機執行個體進行疑難排解。您可以從 Amazon EC2 主控台或 AWS Command Line Interface (AWS CLI) 存取序列主控台。使用 EC2 序列主控台時，您不需要有效連線即可連線至執行個體。

**注意：**如果您之前尚未使用過 EC2 序列主控台，請務必先檢閱先決條件並設定存取權，然後再嘗試連線。如果您的執行個體無法連線，而且您並未設定序列主控台的存取權，則依照方法 2 或方法 3 中的說明操作。

1.    開啟 Amazon EC2 主控台。

2.    選擇執行個體。

3.    選取執行個體，然後選擇動作、監視和疑難排解、EC2 序列主控台、連線。

-或-

選取執行個體，然後選擇連線、EC2 序列主控台、連線。

瀏覽器內的終端視窗即會開啟。

4.    按 Enter 鍵。如果您已連線至序列主控台，則會出現登入提示。如果畫面仍然是黑色的，則使用下列資訊來協助解決連線至序列主控台的問題：

• **確認您已設定序列主控台的存取權。**如需詳細資訊，請參閱設定 EC2 序列主控台的存取權。

• **使用 SysRq 以連線至序列主控台。**SysRq 不需要透過基於瀏覽器的用戶端連線。如需詳細資訊，請參閱使用 SysRq 對 Linux 執行個體進行疑難排解。

• **重新啟動 getty。**如果您擁有執行個體的 SSH 存取權，則使用 SSH 連線至執行個體，然後使用下列命令重新啟動 getty。

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• **重新啟動執行個體。**您可以使用 SysRq、EC2 主控台或 AWS CLI 重新啟動執行個體。如需詳細資訊，請參閱使用 SysRq 對 Linux 執行個體進行疑難排解或重新啟動執行個體。

5.    在登入提示中，輸入您先前設定之密碼型使用者的使用者名稱，然後按 Enter 鍵。

6.    在密碼提示中，輸入密碼，然後按 Enter 鍵。

您現在已登入執行個體，並可使用 EC2 序列主控台進行疑難排解。

您也可以使用自己的金鑰和 SSH 用戶端進行連線。

如需有關使用 EC2 序列主控台的詳細資訊，請參閱連線至 EC2 序列主控台。

方法 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.    將磁碟區連接至原始執行個體，然後啟動執行個體以確認其已成功啟動。