使用失敗的狀態檢查進行 Amazon EC2 Linux 執行個體 - Amazon Elastic Compute Cloud
檢閱狀態檢查資訊擷取系統日誌解決 Linux 執行個體的系統記錄錯誤記憶體不足：終止程序ERROR: mmu_update 失敗 (記憶體管理更新失敗)I/O 錯誤 (區塊型儲存設備故障)I/OERROR：既不是本地磁盤也不是遠程磁盤（破碎的分佈式塊設備）request_module：失控迴圈 modprobe (在舊版 Linux 上建立舊核心 modprobe 的迴圈)「FATAL: 內核太舊了」和「fsck：嘗試打開 /dev 時沒有這樣的文件或目錄」（內核和不匹配）AMI 「FATAL: 無法載入 /lib/ 模組" 或 "BusyBox" (遺失核心模組)ERROR無效的內核（EC2不兼容的內核）fsck：嘗試開啟時找不到此等檔案或目錄… (找不到檔案系統)掛載檔案作業系統的一般錯誤 (掛載失敗)VFS: 無法在未知的區塊上掛載根 fs (根檔案系統不符)錯誤：無法判定根設備的主/次編號… (根檔案系統/裝置不相符)XENBUS：沒有驅動程序的設備...…未進行檢查的天數，強制進行檢查 (需要進行檔案系統檢查)fsck 凍結於結束狀態… (缺少裝置)GRUB提示符（灰塵 >）啟動介面 eth0：裝置 eth0 具有與預期不同的MAC位址，而忽略。(硬式編碼MAC位址) 無法載入SELinux策略。機器正處於強制執行模式。現在停止中。（SELinux配置錯誤）XENBUS：連接到設備的超時（Xenbus 超時）

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用失敗的狀態檢查進行 Amazon EC2 Linux 執行個體

下列資訊可協助您排解 Linux 執行個體無法進行狀態檢查時的問題。首先判斷應用程式是否出現任何問題。如果確認執行個體並未如預期執行應用程式，請檢閱狀態檢查資訊和系統日誌。

關於導致狀態檢查失敗的問題範例，請參閱 Amazon EC2 執行個體的狀態檢查。

檢閱狀態檢查資訊

使用 Amazon EC2 主控台調查受損的執行個體

  1. 在打開 Amazon EC2 控制台https://console.aws.amazon.com/ec2/。

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

  3. 選取 [狀態和警示] 索引標籤，以查看所有系統狀態檢查、執行個體狀態檢查和附加EBS狀態檢查的個別結果。

如果狀態檢查失敗，您可以嘗試下列其中一個選項：

擷取系統日誌

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

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

  1. 在打開 Amazon EC2 控制台https://console.aws.amazon.com/ec2/。

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

  3. 選擇 Instance state (執行個體狀態)、Reboot intance (重新啟動執行個體)。執行個體重新啟動可能需要幾分鐘的時間。

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

  5. 當執行個體處於 running 狀態時，選擇 Actions (動作)、Monitor and troubleshoot (監視和疑難排解)、Get system log (取得系統日誌檔)。

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

  7. 如果問題無法解決，您可以在 AWS re:Post 中發佈您的問題。

解決 Linux 執行個體的系統記錄錯誤

對於執行個體狀態檢查失敗的 Linux 執行個體 (例如執行個體可連接性檢查)，請確認您是否遵循上述步驟擷取系統記錄。下列清單包含了一些常見的系統日誌錯誤和建議的動作，您可以針對每項錯誤採取這些動作，來解決問題。

Memory Errors (記憶體錯誤)

Device Errors (裝置錯誤)

Kernel Errors (核心錯誤)

File System Errors (檔案系統錯誤)

Operating System Errors (作業系統錯誤)

記憶體不足：終止程序

系統記錄項目會指出 out-of-memory 錯誤，類似如下所示。

[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持

執行以下任意一項：

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

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

執行個體存放區後端

請執行下列其中一項：

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

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

ERROR: 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/OERROR：既不是本地磁盤也不是遠程磁盤（破碎的分佈式塊設備）

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

...
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 參數。

「FATAL: 內核太舊了」和「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個使用更新內核的。

  2. 終止執行個體。

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

「FATAL: 無法載入 /lib/ 模組" 或 "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區選取更正的磁碟機磁碟。

  2. 停止執行個體。

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

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

  5. 啟動實例。

  6. 修改AMI以使用更正的磁碟機磁碟。

執行個體存放區後端

請執行下列步驟：

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

  2. AMI使用正確的磁盤創建一個新的。

ERROR無效的內核（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以使用較新的磁碟機磁碟。

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 卷。

  • 已毀損的檔案系統。

  • 不匹配的磁盤和AMI組合（例如 Debian 磁盤與 a）。SUSE AMI

執行個體存放區後端

  • 故障的磁碟機。

  • 已毀損的檔案系統。

  • 一個不匹配的磁盤和組合（例如，一個 Debian 磁盤與 a）。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)
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)

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

建議動作

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

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提示符（灰塵 >）

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

    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以在標準位置（/boot/grub/menu.lst）創建一個GRUB配置文件。

  2. 確認您的版本GRUB支援基礎檔案系統類型，並視需GRUB要進行升級。

  3. 選擇適當的GRUB圖像，（HD0-1 驅動器或 HD00-第一個驅動器，第一個分區）。

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

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

  1. 停止執行個體。

  2. 分離根檔案系統。

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

  4. 掛載檔案系統。

  5. 建立GRUB組態檔案。

  6. 確認您的版本GRUB支援基礎檔案系統類型，並視需GRUB要進行升級。

  7. 分離檔案系統。

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

  9. 修改內核屬性以使用適當的GRUB映像（第一個磁盤或第一個磁盤上的第一個分區）。

  10. 啟動實例。

執行個體存放區後端

選項 1：修改AMI並重新啟動實例：

  1. 在標準位置（/boot/grub/menu.lst）AMI使用GRUB配置文件創建新的文件。

  2. 選擇適當的GRUB圖像，（HD0-1 驅動器或 HD00-第一個驅動器，第一個分區）。

  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  ]

可能的原因

配置中有一個硬編碼MAC的AMI接口

建議動作

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

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 版本的此項程序也會有所差異，如需詳細資訊，請參閱特定作業系統的文件。

    注意

    在某些系統上，您可以在/mount_point/etc/sysconfig/selinux檔案SELINUX=disabled中設定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。