メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

ステータスチェックに失敗したインスタンスのトラブルシューティング

トピック

最初の手順

インスタンスのステータスチェックが失敗した場合は、最初にアプリケーションで問題が発生しているかどうかを確認します。インスタンスでアプリケーションを正常に実行していないことを確認した場合、次の手順に従います。

To investigate impaired instances using the Amazon EC2 console

  1. https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。

  2. In the navigation pane, choose Instances, and then select your instance.

  3. In the details pane, choose Status Checks to see the individual results for all System Status Checks and Instance Status Checks.

システムのステータスチェックに失敗した場合、次のいずれかの方法を試すことができます。

  • インスタンスの復旧アラームを作成します。詳細については、Amazon CloudWatch ユーザーガイド の「インスタンスを停止、終了、復旧するアラームの作成」を参照してください。

  • Amazon EBS-Backed AMI を使用するインスタンスの場合、いったんインスタンスを停止してから再開します。

  • instance-store backed AMI を使用するインスタンスの場合、インスタンスを終了し、代わりのインスタンスを起動します。

  • Amazon EC2 が問題を解決するのを待ちます。

  • 問題を Amazon EC2 forum に投稿します。

  • システムログを取得し、エラーを探します。

システムログの取得

インスタンスのステータスチェックに失敗した場合は、インスタンスを再起動してシステムログを取得できます。ログから判明したエラーが問題のトラブルシューティングに役立つ場合があります。再起動すると、ログから不要な情報が消去されます。

To reboot an instance and retrieve the system log

  1. https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。

  2. In the navigation pane, choose Instances, and select your instance.

  3. Choose Actions, Instance State, Reboot. It may take a few minutes for your instance to reboot.

  4. Verify that the problem still exists; in some cases, rebooting may resolve the problem.

  5. When the instance is in the running state, choose Actions, Instance Settings, Get System Log.

  6. Review the log that appears on the screen, and use the list of known system log error statements below to troubleshoot your issue.

  7. If your experience differs from our check results, or if you are having an issue with your instance that our checks did not detect, choose Submit feedback on the Status Checks tab to help us improve our detection tests.

  8. If your issue is not resolved, you can post your issue to the Amazon EC2 forum.

Linux ベースのインスタンスに関するシステムログエラーのトラブルシューティング

インスタンスの接続性チェックなど、インスタンスのステータスチェックに失敗した Linux ベースのインスタンスの場合、上記の手順に従ってシステムログを取得したことを確認します。次のリストは、一般的なシステムログエラー、および各エラーの問題解決に対して推奨する対処を示しています。

メモリエラー

デバイスエラー

カーネルエラー

ファイルシステムエラー

オペレーティングシステムエラー

メモリ不足: プロセスの終了

メモリ不足エラーは、下記のようなシステムログで示されます。

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

次のいずれかを行ってください。

  • インスタンスを停止し、異なるインスタンスタイプを使用するようにインスタンスを変更した後、インスタンスを再び起動します。たとえば、大きいインスタンスタイプやメモリ最適化インスタンスタイプです。

  • インスタンスを再起動して、障害のないステータスに戻します。インスタンスタイプを変更しない限り、問題が再び発生する可能性があります。

Instance store-Backed

以下のいずれかを行ってください。

  • インスタンスを終了し、別のインスタンスタイプを指定して、新しいインスタンスを起動します。たとえば、大きいインスタンスタイプやメモリ最適化インスタンスタイプです。

  • インスタンスを再起動して、障害のないステータスに戻します。インスタンスタイプを変更しない限り、問題が再び発生する可能性があります。

エラー: mmu_update failed (メモリ管理の更新に失敗しました)

メモリ管理更新失敗は、下記のようなシステムログで示されます。

...
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 サポートにご連絡ください。

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-Backed

障害が発生した Amazon EBS ボリューム

Instance store-Backed

障害が発生した物理ドライブ

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. ボリュームをデタッチします。

  3. ボリュームの回復を試みます。

    注記

    Amazon EBS ボリュームのスナップショットを頻繁に作成することをお勧めします。これによって、エラーのためにデータを損失する危険性が大幅に減少します。

  4. ボリュームをインスタンスに再アタッチします。

  5. ボリュームをデタッチします。

Instance store-Backed

インスタンスを終了し、新しいインスタンスを起動します。

注記

データを復旧できない。バックアップから復旧します。

注記

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-Backed

障害が発生した Amazon EBS ボリューム

Instance store-Backed

障害が発生した物理ドライブ

推奨する対処

インスタンスを終了し、新しいインスタンスを起動します。

Amazon EBS-Backed インスタンスの場合、最新スナップショットからイメージを作成して、データを回復できます。スナップショットを作成した後に追加されたデータは回復できません。

request_module: runaway loop 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-Backed

次のいずれかのオプションを使用して、GRUB ベースまたは静的な新しいカーネルを使用します。

オプション 1: インスタンスを終了し、–kernel および –ramdisk パラメータを指定して新しいインスタンスを起動します。

オプション 2:

  1. インスタンスを停止します。

  2. 新しいカーネルを使用するようカーネルとラムディスク属性を変更します。

  3. インスタンスを起動します。

Instance store-Backed

インスタンスを終了し、–kernel および –ramdisk パラメータを指定して新しいインスタンスを起動します。

「FATAL: kernel too old」および「fsck: No such file or directory while trying to open /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-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. 新しいカーネルを使用するよう設定を変更します。

  3. インスタンスを起動します。

Instance store-Backed

次の手順に従ってください。

  1. より新しいカーネルを使用する AMI を作成します。

  2. インスタンスを終了します。

  3. 作成した AMI から新しいインスタンスを起動します。

「FATAL: Could not load /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)

可能性のある原因

次の 1 つ以上の条件によって、この問題が発生する可能性があります。

  • ラムディスクが見つからない

  • ラムディスクに正しいモジュールが見つからない

  • Amazon EBS ルートボリュームが /dev/sda1 として正しくアタッチされていない

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次の手順に従ってください。

  1. Amazon EBS ボリュームに対して正しいラムディスクを選択します。

  2. インスタンスを停止します。

  3. ボリュームをデタッチし、修復します。

  4. ボリュームをインスタンスにアタッチします。

  5. インスタンスを起動します。

  6. 正しいラムディスクを使用するよう AMI を変更します。

Instance store-Backed

次の手順に従ってください。

  1. インスタンスを終了してから、正しいラムディスクを使って新たなインスタンスを起動します。

  2. 正しいラムディスクを使って新たな 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-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. 機能するカーネルに変更します。

  3. フォールバックカーネルをインストールします。

  4. カーネルを訂正して AMI を変更します。

Instance store-Backed

次の手順に従ってください。

  1. インスタンスを終了してから、正しいカーネルを使って新たなインスタンスを起動します。

  2. 正しいカーネルを使って AMI を作成します。

  3. (オプション) AWS Support を使用してデータ回復の技術サポートを求めます。

request_module: runaway loop 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-Backed

次のいずれかのオプションを使用して、GRUB ベースまたは静的な新しいカーネルを使用します。

オプション 1: インスタンスを終了し、–kernel および –ramdisk パラメータを指定して新しいインスタンスを起動します。

オプション 2:

  1. インスタンスを停止します。

  2. 新しいカーネルを使用するようカーネルとラムディスク属性を変更します。

  3. インスタンスを起動します。

Instance store-Backed

インスタンスを終了し、–kernel および –ramdisk パラメータを指定して新しいインスタンスを起動します。

fsck: No such file or directory while trying to open... (ファイルシステムが見つからない)

下記のようなシステムログで、この状態が示されます。

		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):

可能性のある原因

  • ラムディスクファイルシステム定義 /etc/fstab にバグがある

  • /etc/fstab のファイルシステム定義の設定が不適切

  • ドライブが見つからないかドライブにエラーがある

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次の手順に従ってください。

  1. インスタンスを停止し、ルートボリュームをデタッチし、/etc/fstab を修復または変更し、ボリュームをインスタンスにアタッチし、インスタンスを起動します。

  2. ラムディスクを修正して、変更した /etc/fstab を含めます (適用可能な場合)。

  3. 新しいラムディスクを使用するよう AMI を変更します。

fstab の 6 番目のフィールドではマウントの可用性要件を定義します。0 以外の値を指定した場合、そのボリュームに対して fsck を実行して成功しなければならないことを意味します。Amazon EC2 でこのフィールドを使用すると、問題が発生することがあります。これは、実行に失敗すると通常は対話的なコンソールプロンプトが表示されますが、このコンソールプロンプトは現在 Amazon EC2 で使用できないためです。この機能は慎重に使用してください。また、fstab の Linux マニュアルページを参照してください。

Instance store-Backed

次の手順に従ってください。

  1. インスタンスを終了し、新しいインスタンスを起動します。

  2. 障害のある Amazon EBS ボリュームをデタッチし、インスタンスを再起動します。

  3. (オプション) AWS Support を使用してデータ回復の技術サポートを求めます。

General error mounting filesystems (マウント失敗)

下記のようなシステムログで、この状態が示されます。

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-Backed

  • Amazon EBS ボリュームがデタッチされているか、Amazon EBS ボリュームにエラーがあります。

  • ファイルシステムが破損している。

  • ラムディスクと AMI の組み合わせが一致していません (例: Debian ラムディスクと SUSE AMI)。

Instance store-Backed

  • ドライブにエラーがあります。

  • ファイルシステムが破損しています。

  • ラムディスクと AMI の組み合わせが一致していません (例: Debian ラムディスクと SUSE AMI)。

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. ルートボリュームをデタッチする.

  3. ルートボリュームを既知の動作しているインスタンスにアタッチします。

  4. ファイルシステムチェックを実行します (fsck –a /dev/...)。

  5. エラーを修正します。

  6. ボリュームを既知の動作しているインスタンスからデタッチします。

  7. 停止したインスタンスにボリュームをアタッチします。

  8. インスタンスを起動します。

  9. インスタンスのステータスを再確認します。

Instance store-Backed

以下のいずれかを行ってください。

  • 新しいインスタンスを起動します。

  • (オプション) AWS Support を使用してデータ回復の技術サポートを求めます。

VFS: Unable to mount root fs on unknown-block (ルートファイルシステム不一致)

下記のようなシステムログで、この状態が示されます。

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-Backed

  • デバイスが正しくアタッチされていない。

  • ルートデバイスが正しいデバイスポイントにアタッチされていない。

  • ファイルシステムのフォーマットが正しくありません。

  • レガシーカーネルを使用している (たとえば、2.6.16-XenU)。

Instance store-Backed

ハードウェアデバイスのエラー。

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次のいずれかを行ってください。

  • インスタンスを停止し、再起動します。

  • 正しいデバイスポイントでアタッチするようルートボリュームを変更します。たとえば、/dev/sda の代わりに /dev/sda1 を使用します。

  • 停止し、新しいカーネルを使用するように変更します。

Instance store-Backed

インスタンスを終了し、新しいカーネルを使用して、新しいインスタンスを起動します。

エラー: Unable to determine major/minor number of root device... (ルートファイルシステム/デバイス不一致)

下記のようなシステムログで、この状態が示されます。

...
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 または sda1 の代わりに sda)

  • インスタンスカーネルが正しく選択されていない

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. ボリュームをデタッチします。

  3. デバイスのマッピングの問題を解決します。

  4. インスタンスを起動します。

  5. AMI を変更して、デバイスのマッピングの問題に対処します。

Instance store-Backed

次の手順に従ってください。

  1. 適切な修正を使用して新しい AMI を作成します (ブロックデバイスを正しくマッピングします)。

  2. インスタンスを終了し、作成した AMI から新しいインスタンスを起動します。

XENBUS: Device with no driver...

下記のようなシステムログで、この状態が示されます。

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-Backed

次の手順に従ってください。

  1. インスタンスを停止します。

  2. ボリュームをデタッチします。

  3. デバイスのマッピングの問題を解決します。

  4. インスタンスを起動します。

  5. AMI を変更して、デバイスのマッピングの問題に対処します。

Instance store-Backed

次の手順に従ってください。

  1. 適切な修正を使用して AMI を作成します (ブロックデバイスを正しくマッピングします)。

  2. インスタンスを終了し、作成した AMI を使用して新しいインスタンスを起動します。

... days without being checked, check forced (ファイルシステムのチェックが必要です)

下記のようなシステムログで、この状態が示されます。

...
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 died with exit status... (デバイスが見つかりません)

下記のようなシステムログで、この状態が示されます。

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

可能性のある原因

  • 存在しないドライブをラムディスクが検索している

  • ファイルシステムの整合性チェックが強制実行されている

  • ドライブにエラーがあるか、デタッチされている

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

問題を解決するため、次のいずれかを試します。

  • インスタンスを停止し、ボリュームを既存の実行中インスタンスにアタッチします。

  • 整合性チェックを手動で実行します。

  • ラムディスクを修正して、関連するユーティリティを含めます。

  • ファイルシステム調整パラメータを変更して、整合性要件を削除します (お勧めしません)。

Instance store-Backed

問題を解決するため、次のいずれかを試します。

  • ラムディスクに正しいツールをリバンドリングします。

  • ファイルシステム調整パラメータを変更して、整合性要件を削除します (お勧めしません)。

  • インスタンスを終了し、新しいインスタンスを起動します。

  • (オプション) 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-Backed

  • GRUB 設定ファイルがありません。

  • 正しくない GRUB イメージが使用されています。別の場所に GRUB 設定ファイルが必要です。

  • GRUB 設定ファイルを保存するために使用されているファイルシステムがサポートされていません (たとえば、ルートファイルシステムを GRUB の以前のバージョンでサポートされていないタイプに変換した)

Instance store-Backed

  • GRUB 設定ファイルがありません。

  • 正しくない GRUB イメージが使用されています。別の場所に GRUB 設定ファイルが必要です。

  • GRUB 設定ファイルを保存するために使用されているファイルシステムがサポートされていません (たとえば、ルートファイルシステムを GRUB の以前のバージョンでサポートされていないタイプに変換した)

推奨する対処

インスタンスタイプ 操作

Amazon EBS-Backed

オプション 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. インスタンスを起動します。

Instance store-Backed

オプション 1: AMI を変更しインスタンスを再作成します。

  1. GRUB 設定ファイルを使用して、標準の場所に新しい AMI を作成します (/boot/grub/menu.lst)。

  2. 適切な GRUB イメージを選択します (hd0 – 第 1 ドライブまたは hd00 – 第 1 ドライブ、第 1 パーティション)。

  3. GRUB のバージョンが、基になるファイルシステムのタイプをサポートしていることを確認し、必要に応じて GRUB をアップグレードします。

  4. インスタンスを終了し、作成した AMI を使用して新しいインスタンスを起動します。

オプション 2: インスタンスを終了し、正しいカーネルを指定して新しいインスタンスを起動します。

注記

既存のインスタンスからデータを回復するには、AWS サポートにお問い合わせください。

Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring. (ハードコードされた 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-Backed

次のいずれかを行ってください。

  • AMI を変更してハードコードを削除し、インスタンスを再作成します。

  • インスタンスを変更して、ハードコードされた MAC アドレスを削除します。

または

次の手順に従ってください。

  1. インスタンスを停止します。

  2. ルートボリュームをデタッチする.

  3. ボリュームを別のインスタンスにアタッチし、ボリュームを変更してハードコードされた MAC アドレスを削除します。

  4. 初期インスタンスにボリュームをアタッチします。

  5. インスタンスを起動します。

Instance store-Backed

次のいずれかを行ってください。

  • インスタンスを変更して、ハードコードされた MAC アドレスを削除します。

  • インスタンスを終了し、新しいインスタンスを起動します。

SELinux ポリシーを読み込めません。Machine is in enforcing mode. Halting now. (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-Backed

次の手順に従ってください。

  1. 障害のあるインスタンスを停止します。

  2. 障害の起きたインスタンスのルートボリュームをデタッチします。

  3. 別の実行中の Linux インスタンスにルートボリュームをアタッチします (リカバリインスタンスとして扱われます)。

  4. リカバリインスタンスを接続し、障害の起きたインスタンスのルートボリュームをマウントします。

  5. マウントしたルートボリュームの SELinux を無効にします。 このプロセスは Linux ディストリビューションによって異なります。詳細については各 OS のドキュメントを参照してください。

    注記

    一部のシステムでは、/mount_point/etc/sysconfig/selinux ファイル (mount_point はリカバリインスタンスにマウントとしたボリュームの場所) で SELINUX=disabled と設定して SELinux を無効にします。

  6. リカバリインスタンスからルートボリュームをアンマウントしてデタッチし、元のインスタンスに再アタッチします。

  7. インスタンスを起動します。

Instance store-Backed

次の手順に従ってください。

  1. インスタンスを終了し、新しいインスタンスを起動します。

  2. (オプション) AWS Support を使用してデータ回復の技術サポートを求めます。

XENBUS: Timeout connecting to devices (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-Backed

次のいずれかを行ってください。

  • AMI とインスタンスを変更して新しいカーネルを使用し、インスタンスを再作成します。

  • インスタンスを再起動します。

Instance store-Backed

次のいずれかを行ってください。

  • インスタンスを終了します。

  • AMI を変更して新しいカーネルを使用し、その AMI を使用して新しいインスタンスを起動します。

このページの内容: