執行個體狀態檢查未通過的故障診斷 - Amazon Elastic Compute Cloud

執行個體狀態檢查未通過的故障診斷

如果您的執行個體無法進行狀態檢查,則以下資訊有助於排解疑難問題。首先判斷應用程式是否出現任何問題。如果確認執行個體並未如預期執行應用程式,請檢閱狀態檢查資訊和系統日誌。

檢閱狀態檢查資訊

使用 Amazon EC2 主控台來調查狀態不健全的執行個體

  1. https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。

  2. 在導覽窗格中,選擇 Instances (執行個體),然後選取您的執行個體。

  3. 在詳細資訊窗格中,請選擇 Status Checks (狀態檢查),以檢視所有 System Status Checks (系統狀態檢查)Instance Status Checks (執行個體狀態檢查) 的個別結果。

如果未通過系統狀態檢查,您可以嘗試下列其中一個選項:

  • 建立執行個體復原警示。如需更多詳細資訊,請參閱 建立警示以停止、終止、重新啟動或復原執行個體

  • 如果您已將執行個體類型變更為在 Nitro 系統上建置的執行個體,則從沒有必要 ENA 和 NVMe 驅動程式的執行個體遷移時,狀態檢查會失敗。如需詳細資訊,請參閱調整執行個體大小的相容性

  • 如果是使用 Amazon EBS 後端 AMI 的執行個體,請停止和重新啟動執行個體。

  • 如果是使用執行個體存放區後端 AMI 的執行個體,請終止執行個體,並啟動替代用的執行個體。

  • 請等候 Amazon EC2 解決問題。

  • Amazon EC2 forum 中發表您的問題。

  • 如果您的執行個體在 Auto Scaling 群組中,則 Amazon EC2 Auto Scaling 服務會自動啟動替換的執行個體。如需詳細資訊,請參閱 Amazon EC2 Auto Scaling 使用者指南中的 Auto Scaling 執行個體的運作狀態檢查

  • 擷取系統日誌並尋找錯誤。

擷取系統日誌

如果執行個體狀態檢查未通過,您可以重新啟動執行個體和擷取系統日誌。日誌可能會顯示錯誤,有助於對發生的問題進行故障診斷。重新啟動作業會清除日誌中不必要的資訊。

重新啟動執行個體和擷取系統日誌

  1. https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。

  2. 在導覽窗格中,選擇 Instances (執行個體),然後選取您的執行個體。

  3. 依序選擇 Actions (動作)Instance State (執行個體狀態)Reboot (重新啟動)。執行個體重新啟動需要幾分鐘的時間來完成。

  4. 確認問題是否仍持續存在;在某些情況中,重新啟動也許可以解決問題。

  5. 在執行個體處於 running 狀態時,依序選擇 Actions (動作)Instance Settings (執行個體設定)Get System Log (取得系統日誌)

  6. 檢閱畫面上所顯示的日誌,然後使用下列的已知系統日誌錯誤陳述清單,來進行問題的故障診斷。

  7. 如果您遇到的情況和我們的檢查結果不同,或是有我們的檢查未偵測到的執行個體問題,請在 Status Checks (狀態檢查) 索引標籤中選取 Submit feedback (提交意見反映),以協助我們改善偵測檢查。

  8. 如果問題無法解決,您可以在 Amazon EC2 forum 中發表您的問題。

針對 Linux 架構的執行個體,進行系統日誌錯誤的故障診斷

如果 Linux 架構的執行個體未通過執行個體的狀態檢查 (例如執行個體可達性檢查),請確認是否已按照上述的步驟來擷取系統日誌。下列清單包含了一些常見的系統日誌錯誤和建議的動作,您可以針對每項錯誤採取這些動作,來解決問題。

Memory Errors (記憶體錯誤)

Device Errors (裝置錯誤)

Kernel Errors (核心錯誤)

File System Errors (檔案系統錯誤)

Operating System Errors (作業系統錯誤)

記憶體不足:終止程序

系統日誌記錄項目會顯示記憶體不足的錯誤,類似於下列所示記錄。

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child [115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon- rss:101196kB, file-rss:204kB

可能的原因

記憶體用盡

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列其中一項:

  • 請停止執行個體,並修改執行個體以使用不同的執行個體類型,然後再次啟動該執行個體。例如,較大容量或記憶體最佳化的執行個體類型。

  • 重新啟動執行個體,以讓執行個體回到健全狀態。除非您變更執行個體類型,否則問題可能會再次發生。

執行個體存放區後端

請執行下列其中一項:

  • 終止執行個體並啟動新的執行個體,指定不同的執行個體類型。例如,較大容量或記憶體最佳化的執行個體類型。

  • 重新啟動執行個體,以讓執行個體回到健全狀態。除非您變更執行個體類型,否則問題可能會再次發生。

錯誤:mmu_update 失敗 (記憶體管理更新作業失敗)

系統日誌記錄項目會顯示記憶體管理更新作業的失敗,類似於下列所示記錄:

... Press `ESC' to enter the menu... 0 [H[J Booting 'Amazon Linux 2011.09 (2.6.35.14-95.38.amzn1.i686)' root (hd0) Filesystem type is ext2fs, using whole disk kernel /boot/vmlinuz-2.6.35.14-95.38.amzn1.i686 root=LABEL=/ console=hvc0 LANG= en_US.UTF-8 KEYTABLE=us initrd /boot/initramfs-2.6.35.14-95.38.amzn1.i686.img ERROR: mmu_update failed with rc=-22

可能的原因

Amazon Linux 的問題

建議動作

請在開發人員論壇上發表您的問題,或是聯絡 AWS Support

I/O 錯誤 (區塊型儲存設備故障)

系統日誌記錄項目會顯示輸入/輸出錯誤,類似於下列的範例:

[9943662.053217] end_request: I/O error, dev sde, sector 52428288 [9943664.191262] end_request: I/O error, dev sde, sector 52428168 [9943664.191285] Buffer I/O error on device md0, logical block 209713024 [9943664.191297] Buffer I/O error on device md0, logical block 209713025 [9943664.191304] Buffer I/O error on device md0, logical block 209713026 [9943664.191310] Buffer I/O error on device md0, logical block 209713027 [9943664.191317] Buffer I/O error on device md0, logical block 209713028 [9943664.191324] Buffer I/O error on device md0, logical block 209713029 [9943664.191332] Buffer I/O error on device md0, logical block 209713030 [9943664.191339] Buffer I/O error on device md0, logical block 209713031 [9943664.191581] end_request: I/O error, dev sde, sector 52428280 [9943664.191590] Buffer I/O error on device md0, logical block 209713136 [9943664.191597] Buffer I/O error on device md0, logical block 209713137 [9943664.191767] end_request: I/O error, dev sde, sector 52428288 [9943664.191970] end_request: I/O error, dev sde, sector 52428288 [9943664.192143] end_request: I/O error, dev sde, sector 52428288 [9943664.192949] end_request: I/O error, dev sde, sector 52428288 [9943664.193112] end_request: I/O error, dev sde, sector 52428288 [9943664.193266] end_request: I/O error, dev sde, sector 52428288 ...

可能的原因

執行個體類型 可能的原因

Amazon EBS 後端

故障的 Amazon EBS 磁碟區

執行個體存放區後端

故障的實體磁碟機

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 分離磁碟區。

  3. 試著將磁碟區復原。

    注意

    經常性地建立 Amazon EBS 磁碟區快照,是建議的理想做法。這可以大幅降低因為故障而造成資料遺失的風險。

  4. 將磁碟區重新連結到執行個體。

  5. 啟動實例。

執行個體存放區後端

終止執行個體並啟動新的執行個體。

注意

資料無法復原。請從備份資料復原。

注意

理想的做法是使用 Amazon S3 或 Amazon EBS 來進行備份。執行個體存放磁碟區會與單一主機或單一磁碟的故障直接連動。

I/O 錯誤:非本機也非遠端磁碟 (故障的分散式區塊型儲存設備)

系統日誌記錄項目會顯示裝置上的輸入/輸出錯誤,類似於下列的範例:

... block drbd1: Local IO failed in request_timer_fn. Detaching... Aborting journal on device drbd1-8. block drbd1: IO ERROR: neither local nor remote disk Buffer I/O error on device drbd1, logical block 557056 lost page write due to I/O error on drbd1 JBD2: I/O error detected when updating journal superblock for drbd1-8.

可能的原因

執行個體類型 可能的原因

Amazon EBS 後端

故障的 Amazon EBS 磁碟區

執行個體存放區後端

故障的實體磁碟機

建議動作

終止執行個體並啟動新的執行個體。

如果是 Amazon EBS 後端執行個體,您可以藉由從最近的快照建立映像,來回復資料。在快照建立後所新增的任何資料,皆無法復原。

request_module:失控迴圈 modprobe (在舊版 Linux 上建立舊核心 modprobe 的迴圈)

系統日誌記錄項目會顯示此狀況,類似於下列所示。使用不穩定的或舊版的 Linux 核心 (例如 2.6.16-xenU),可能會在啟動時造成無止盡的循環狀況。

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000026700000 (usable) 0MB HIGHMEM available. ... request_module: runaway loop modprobe binfmt-464c request_module: runaway loop modprobe binfmt-464c request_module: runaway loop modprobe binfmt-464c request_module: runaway loop modprobe binfmt-464c request_module: runaway loop modprobe binfmt-464c

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請使用下列其中一個選項,來使用較新版的核心 (採用 GRUB 或靜態的核心):

選項 1:終止執行個體並啟動新的執行個體,指定 –kernel–ramdisk 參數。

選項 2:

  1. 停止執行個體。

  2. 修改核心和記憶體虛擬磁碟 (ramdisk) 的屬性,以使用較新版的核心。

  3. 啟動實例。

執行個體存放區後端

終止執行個體並啟動新的執行個體,指定 –kernel–ramdisk 參數。

「嚴重:核心版本太舊」和「fsck:嘗試開啟 /dev 時,找不到此等檔案或目錄」(核心與 AMI 不符)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Linux version 2.6.16.33-xenU (root@dom0-0-50-45-1-a4-ee.z-2.aes0.internal) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007 ... FATAL: kernel too old Kernel panic - not syncing: Attempted to kill init!

可能的原因

不相容的核心和使用者空間

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 修改組態,以使用較新版的核心。

  3. 啟動實例。

執行個體存放區後端

請執行下列步驟:

  1. 建立 AMI,此 AMI 會使用較新版的核心。

  2. 終止執行個體。

  3. 從您所建立的 AMI 啟動新的執行個體。

「嚴重:無法載入 /lib/modules」或「BusyBox」(缺少核心模組)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

[ 0.370415] Freeing unused kernel memory: 1716k freed Loading, please wait... WARNING: Couldn't open directory /lib/modules/2.6.34-4-virtual: No such file or directory FATAL: Could not open /lib/modules/2.6.34-4-virtual/modules.dep.temp for writing: No such file or directory FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory Couldn't get a file descriptor referring to the console Begin: Loading essential drivers... ... FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory Done. Begin: Running /scripts/init-premount ... Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system... ... Done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory ALERT! /dev/sda1 does not exist. Dropping to a shell! BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu5) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs)

可能的原因

這項問題可能是下列一種或多種狀況所造成:

  • 缺少記憶體虛擬磁碟 (ramdisk)

  • 記憶體虛擬磁碟 (ramdisk) 缺少正確的模組

  • Amazon EBS 根磁碟區未正確地連結為 /dev/sda1

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 為 Amazon EBS 磁碟區選擇修正過的記憶體虛擬磁碟 (ramdisk)。

  2. 停止執行個體。

  3. 先分離然後修復磁碟區。

  4. 將磁碟區連結到執行個體。

  5. 啟動實例。

  6. 修改 AMI 以使用修正過的記憶體虛擬磁碟 (ramdisk)。

執行個體存放區後端

請執行下列步驟:

  1. 終止執行個體,並使用正確的記憶體虛擬磁碟 (ramdisk) 來啟動新的執行個體。

  2. 使用正確的記憶體虛擬磁碟 (ramdisk) 來建立新的 AMI。

錯誤:無效的核心 (與 EC2 不相容的核心)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

... root (hd0) Filesystem type is ext2fs, using whole disk kernel /vmlinuz root=/dev/sda1 ro initrd /initrd.img ERROR Invalid kernel: elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images xc_dom_parse_image returned -1 Error 9: Unknown boot failure Booting 'Fallback' root (hd0) Filesystem type is ext2fs, using whole disk kernel /vmlinuz.old root=/dev/sda1 ro Error 15: File not found

可能的原因

這項問題可能是下列狀況中的其中一種或兩種同時造成:

  • GRUB 不支援隨附的核心

  • 備用核心不存在

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 換成可正常運作的核心。

  3. 安裝備用核心。

  4. 透過修正核心來修改 AMI。

執行個體存放區後端

請執行下列步驟:

  1. 終止執行個體,並使用正確的核心來啟動新的執行個體。

  2. 使用正確的核心來建立 AMI。

  3. (選用) 透過 AWS Support 來尋求資料復原的技術協助。

fsck:嘗試開啟時找不到此等檔案或目錄…(找不到檔案系統)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Welcome to Fedora Press 'I' to enter interactive startup. Setting clock : Wed Oct 26 05:52:05 EDT 2011 [ OK ] Starting udev: [ OK ] Setting hostname localhost: [ OK ] No devices found Setting up Logical Volume Management: File descriptor 7 left open No volume groups found [ OK ] Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 /dev/sda1: clean, 82081/1310720 files, 2141116/2621440 blocks [/sbin/fsck.ext3 (1) -- /mnt/dbbackups] fsck.ext3 -a /dev/sdh fsck.ext3: No such file or directory while trying to open /dev/sdh /dev/sdh: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> [FAILED] *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance (or type Control-D to continue):

可能的原因

  • ramdisk 檔案系統定義 /etc/fstab 中存在錯誤

  • /etc/fstab 中設定錯誤的檔案系統定義

  • 找不到磁碟機/磁碟機故障

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體、分離根磁碟區、修復/修改 /etc/fstab 磁碟區、將磁碟區連結到執行個體,以及啟動執行個體。

  2. 修正 ramdisk,以納入修改過的 /etc/fstab (如有適用)。

  3. 修改 AMI,以使用較新版的 ramdisk。

fstab 中的第 6 個欄位定義了掛載的可用性要求 – 非 0 值暗示 fsck 將在該磁碟區上完成,而且必須成功。在 Amazon EC2 中使用此欄位可能會出現問題,因為故障通常會產生互動式主控台提示,而 Amazon EC2 中目前並未提供此提示功能。使用此功能時請特別注意,並閱讀 fstab 的 Linux 手冊頁。

執行個體存放區後端

請執行下列步驟:

  1. 終止執行個體並啟動新的執行個體。

  2. 分離所有錯誤的 Amazon EBS 磁碟區,並重新啟動執行個體。

  3. (選用) 透過 AWS Support 來尋求資料復原的技術協助。

掛載檔案作業系統的一般錯誤 (掛載失敗)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Loading xenblk.ko module xen-vbd: registered block device major 8 Loading ehci-hcd.ko module Loading ohci-hcd.ko module Loading uhci-hcd.ko module USB Universal Host Controller Interface driver v3.0 Loading mbcache.ko module Loading jbd.ko module Loading ext3.ko module Creating root device. Mounting root filesystem. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Setting up other filesystems. Setting up new root fs no fstab.sys, mounting internal defaults Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys mountall:/proc: unable to mount: Device or resource busy mountall:/proc/self/mountinfo: No such file or directory mountall: root filesystem isn't mounted init: mountall main process (221) terminated with status 1 General error mounting filesystems. A maintenance shell will now be started. CONTROL-D will terminate this shell and re-try. Press enter for maintenance (or type Control-D to continue):

可能的原因

執行個體類型 可能的原因

Amazon EBS 後端

  • 已分離或故障的 Amazon EBS 磁碟區。

  • 已毀損的檔案系統。

  • 不匹配的 ramdisk 和 AMI 組合 (例如 Debian ramdisk 搭配 SUSE AMI)。

執行個體存放區後端

  • 故障的磁碟機。

  • 已毀損的檔案系統。

  • 不匹配的 ramdisk 和組合 (例如 Debian ramdisk 搭配 SUSE AMI)。

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 分離根 磁碟區。

  3. 將根磁碟區連結到已知可正常運作的執行個體。

  4. 執行檔案系統檢查 (fsck –a /dev/...)。

  5. 修正所有錯誤。

  6. 將磁碟區從已知可正常運作的執行個體分離。

  7. 將磁碟區連結到已停止的執行個體。

  8. 啟動實例。

  9. 重新檢查執行個體的狀態。

執行個體存放區後端

請嘗試執行下列其中一項操作:

  • 啟動新的執行個體。

  • (選用) 透過 AWS Support 來尋求資料復原的技術協助。

VFS:無法在未知的區塊上掛載根 fs (根檔案系統不符)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007 ... Kernel command line: root=/dev/sda1 ro 4 ... Registering block device major 8 ... Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

可能的原因

執行個體類型 可能的原因

Amazon EBS 後端

  • 未正確地連結裝置。

  • 根設備未連結到正確的裝置點。

  • 檔案系統未採用預期的格式。

  • 使用舊版的核心 (例如 2.6.16-XenU)。

  • 在執行個體上最近更新了核心 (更新作業失敗或出現錯誤)

執行個體存放區後端

硬體裝置故障。

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列其中一項:

  • 停止並重新啟動執行個體。

  • 修改根磁碟區,以掛載於正確的裝置點 (可能是 /dev/sda1 而非 /dev/sda)。

  • 停止並進行修改,以使用現代化的核心。

  • 請參考您 Linux 版本的文件,以查看已知的更新錯誤。變更或重新安裝核心。

執行個體存放區後端

終止執行個體,並使用現代化的核心來啟動新的執行個體。

錯誤:無法判定根設備的主/次編號…(根檔案系統/裝置不相符)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

... XENBUS: Device with no driver: device/vif/0 XENBUS: Device with no driver: device/vbd/2048 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Initializing network drop monitor service Freeing unused kernel memory: 508k freed :: Starting udevd... done. :: Running Hook [udev] :: Triggering uevents...<30>udevd[65]: starting version 173 done. Waiting 10 seconds for device /dev/xvda1 ... Root device '/dev/xvda1' doesn't exist. Attempting to create it. ERROR: Unable to determine major/minor number of root device '/dev/xvda1'. You are being dropped to a recovery shell Type 'exit' to try and continue booting sh: can't access tty; job control turned off [ramfs /]#

可能的原因

  • 找不到虛擬區塊型儲存設備驅動程式,或是該驅動程式設定不正確

  • 裝置列舉衝突 (sda 對 xvda 或 sda 而非 sda1)

  • 所選的執行個體核心不正確

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 分離磁碟區。

  3. 修正裝置映射問題。

  4. 啟動實例。

  5. 修正 AMI 以解決裝置映射問題。

執行個體存放區後端

請執行下列步驟:

  1. 透過適當的修正來建立新的 AMI (正確地對應區塊型儲存設備)。

  2. 終止執行個體,並從您所建立的 AMI 來啟動新的執行個體。

XENBUS:裝置缺少驅動程式…

系統日誌記錄項目會顯示此狀況,類似於下列所示。

XENBUS: Device with no driver: device/vbd/2048 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Initalizing network drop monitor service Freeing unused kernel memory: 508k freed :: Starting udevd... done. :: Running Hook [udev] :: Triggering uevents...<30>udevd[65]: starting version 173 done. Waiting 10 seconds for device /dev/xvda1 ... Root device '/dev/xvda1' doesn't exist. Attempting to create it. ERROR: Unable to determine major/minor number of root device '/dev/xvda1'. You are being dropped to a recovery shell Type 'exit' to try and continue booting sh: can't access tty; job control turned off [ramfs /]#

可能的原因

  • 找不到虛擬區塊型儲存設備驅動程式,或是該驅動程式設定不正確

  • 裝置列舉衝突 (sda 對 xvda)

  • 所選的執行個體核心不正確

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止執行個體。

  2. 分離磁碟區。

  3. 修正裝置映射問題。

  4. 啟動實例。

  5. 修正 AMI 以解決裝置映射問題。

執行個體存放區後端

請執行下列步驟:

  1. 透過適當的修正來建立 AMI (正確地對應區塊型儲存設備)。

  2. 終止執行個體,並使用您所建立的 AMI 來啟動新的執行個體。

…未進行檢查的天數,強制進行檢查 (需要進行檔案系統檢查)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

... Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 /dev/sda1 has gone 361 days without being checked, check forced

可能的原因

已超過檔案系統檢查時間;強制進行檔案系統檢查。

建議動作

  • 請等候檔案系統檢查完成。視根檔案系統的大小而定,檔案系統檢查可能需要一段長時間才會完成。

  • 使用 tune2fs 或檔案系統適用的工具,來修改檔案系統,以移除強制進行檔案系統檢查 (fsck) 的功能。

fsck 凍結於結束狀態…(缺少裝置)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Cleaning up ifupdown.... Loading kernel modules...done. ... Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.16.2 /sbin/fsck.xfs: /dev/sdh does not exist fsck died with exit status 8 [31mfailed (code 8).[39;49m

可能的原因

  • Ramdisk 尋找缺少的磁碟機

  • 強制進行檔案系統一致性檢查

  • 磁碟機故障或已分離

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請嘗試執行下列其中一項或多項動作來解決問題:

  • 停止執行個體、將磁碟區連結到執行中的現有執行個體。

  • 手動執行一致性檢查。

  • 修正 ramdisk,以加入相關的公用程式。

  • 修改檔案系統調校參數,以移除一致性要求 (不建議)。

執行個體存放區後端

請嘗試執行下列其中一項或多項動作來解決問題:

  • 將 ramdisk 與正確的工具重新綁定為套件。

  • 修改檔案系統調校參數,以移除一致性要求 (不建議)。

  • 終止執行個體並啟動新的執行個體。

  • (選用) 透過 AWS Support 來尋求資料復原的技術協助。

GRUB 提示 (grubdom>)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

GNU GRUB version 0.97 (629760K lower / 0K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grubdom>

可能的原因

執行個體類型 可能的原因

Amazon EBS 後端

  • 找不到 GRUB 組態檔案。

  • 使用了不正確的 GRUB 映像,預期 GRUB 組態檔案儲存於不同的位置。

  • 使用了不支援的檔案系統來存放 GRUB 組態檔案 (例如,將根檔案系統轉換為 GRUB 先前版本不支援的類型)。

執行個體存放區後端

  • 找不到 GRUB 組態檔案。

  • 使用了不正確的 GRUB 映像,預期 GRUB 組態檔案儲存於不同的位置。

  • 使用了不支援的檔案系統來存放 GRUB 組態檔案 (例如,將根檔案系統轉換為 GRUB 先前版本不支援的類型)。

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

選項 1:修改 AMI 並重新啟動執行個體:

  1. 修改來源 AMI,以在標準位置建立 GRUB 組態檔案 (/boot/grub/menu.lst)。

  2. 確認您的 GRUB 版本支援底層檔案系統的類型,必要時請更新 GRUB。

  3. 選擇適合的 GRUB 映像 (hd0-第 1 個磁碟機或 hd00 – 第 1 個磁碟機,第 1 個分割區)。

  4. 終止執行個體,並使用您所建立的 AMI 來啟動新的執行個體。

選項 2:修改現有的執行個體:

  1. 停止執行個體。

  2. 分離根檔案系統。

  3. 將根檔案系統連結到已知可正常運作的執行個體。

  4. 掛載檔案系統。

  5. 建立 GRUB 組態檔案。

  6. 確認您的 GRUB 版本支援底層檔案系統的類型,必要時請更新 GRUB。

  7. 分離檔案系統。

  8. 連結到原始執行個體。

  9. 修改核心屬性,以使用適合的 GRUB 映像 (第 1 個磁碟機或第 1 個磁碟機上的第 1 個分割區)。

  10. 啟動實例。

執行個體存放區後端

選項 1:修改 AMI 並重新啟動執行個體:

  1. 使用儲存於標準位置的 GRUB 組態檔案 (/boot/grub/menu.lst),來建立新的 AMI。

  2. 選擇適合的 GRUB 映像 (hd0-第 1 個磁碟機或 hd00 – 第 1 個磁碟機,第 1 個分割區)。

  3. 確認您的 GRUB 版本支援底層檔案系統的類型,必要時請更新 GRUB。

  4. 終止執行個體,並使用您所建立的 AMI 來啟動新的執行個體。

選項 2:終止執行個體,並啟動新的執行個體 (指定正確的核心)。

注意

若要從現有的執行個體復原資料,請聯絡 AWS Support

帶出界面 eth0:裝置 eth0 的 MAC 地址和預期的不同,略過。(將 MAC 地址直接寫入程式)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

... Bringing up loopback interface: [ OK ] Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring. [FAILED] Starting auditd: [ OK ]

可能的原因

在 AMI 組態中有直接寫入程式的界面 MAC

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列其中一項:

  • 修改 AMI,以移除直接寫入程式的項目,並重新啟動執行個體。

  • 修改執行個體,以移除直接寫入程式的 MAC 位址。

或是

請執行下列步驟:

  1. 停止執行個體。

  2. 分離根 磁碟區。

  3. 將磁碟區連結到另一個執行個體,並修改該磁碟區,以移除直接寫入程式的 MAC 位址。

  4. 將磁碟區連結到原始執行個體。

  5. 啟動實例。

執行個體存放區後端

請執行下列其中一項:

  • 修改執行個體,以移除直接寫入程式的 MAC 位址。

  • 終止執行個體並啟動新的執行個體。

無法載入 SELinux 政策。機器正處於強制執行模式。現在停止中。(SELinux 組態設定不當)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

audit(1313445102.626:2): enforcing=1 old_enforcing=0 auid=4294967295 Unable to load SELinux Policy. Machine is in enforcing mode. Halting now. Kernel panic - not syncing: Attempted to kill init!

可能的原因

SELinux 已在啟用時發生錯誤:

  • GRUB 不支援隨附的核心

  • 備用核心不存在

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列步驟:

  1. 停止已故障的執行個體。

  2. 分離已故障執行個體的根磁碟區。

  3. 將根磁碟區連結到另一個執行中的 Linux 執行個體 (之後稱為復原執行個體)。

  4. 連線到復原執行個體,並掛載已故障執行個體的根磁碟區。

  5. 將已掛載根磁碟區上的 SELinux 停用。不同 Linux 版本的此項程序也會有所差異,如需詳細資訊,請參閱特定作業系統的文件。

    注意

    在某些系統上,您可以透過設定 SELINUX=disabled 檔案中的 /mount_point/etc/sysconfig/selinux,來停用 SELinux,其中 mount_point 是您在復原執行個體上掛載磁碟區的位置。

  6. 取消掛載根磁碟區、將該磁碟區從復原執行個體分離,然後再重新連結到原始執行個體。

  7. 啟動實例。

執行個體存放區後端

請執行下列步驟:

  1. 終止執行個體並啟動新的執行個體。

  2. (選用) 透過 AWS Support 來尋求資料復原的技術協助。

XENBUS:連線到裝置的作業逾時 (Xenbus 逾時)

系統日誌記錄項目會顯示此狀況,類似於下列所示。

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007 ... XENBUS: Timeout connecting to devices! ... Kernel panic - not syncing: No init found. Try passing init= option to kernel.

可能的原因

  • 區塊型儲存設備未連線到執行個體

  • 執行個體使用舊版的執行個體核心

建議動作

如果是此種執行個體類型 執行此作業

Amazon EBS 後端

請執行下列其中一項:

  • 修改 AMI 和執行個體,以使用現代化的核心並重新啟動執行個體。

  • 重新啟動執行個體。

執行個體存放區後端

請執行下列其中一項:

  • 終止執行個體。

  • 修改 AMI,以使用現代化的核心,並使用此 AMI 來啟動新的執行個體。