Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
ステータスチェックに失敗した Amazon EC2 Linux インスタンスをトラブルシューティングする - Amazon Elastic Compute Cloud
ステータスチェック情報の確認システムログの取得Linux インスタンスに対するシステムログエラーのトラブルシューティングメモリ不足: プロセスの終了エラー: mmu_update failed (メモリ管理の更新に失敗しました)I/O エラー (ブロックデバイス障害)I/O エラー: ローカルでもリモートディスクでもありません (破損した分散ブロックデバイス)request_module: runaway loop modprobe (古い Linux バージョンでレガシーカーネル modprobe がループしている)「FATAL: kernel too old」および「fsck: No such file or directory while trying to open /dev」 (カーネルと AMI の不一致) 「FATAL: Could not load /lib/modules」または「BusyBox」 (カーネルモジュールの欠如)エラー: 無効のカーネル (EC2 と互換性のないカーネル)fsck: No such file or directory while trying to open..。(ファイルシステムが見つからない。)General error mounting filesystems (マウント失敗)VFS: Unable to mount root fs on unknown-block (ルートファイルシステム不一致)Error: Unable to determine major/minor number of root device..。(ルートファイルシステム/デバイス不一致)XENBUS: Device with no driver..。... days without being checked, check forced (ファイルシステムのチェックが必要です)fsck died with exit status..。(デバイスが見つからない)GRUB プロンプト (grubdom>)Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring。(ハードコードされた MAC アドレス) SELinux ポリシーを読み込めません。Machine is in enforcing mode。Halting now。(SELinux の誤設定)XENBUS: Timeout connecting to devices (Xenbus タイムアウト)

ステータスチェックに失敗した Amazon EC2 Linux インスタンスをトラブルシューティングする

以下の情報は、Linux インスタンスでステータスチェックに失敗した場合の問題のトラブルシューティングに役立ちます。まず、アプリケーションで問題が発生しているかどうかを確認します。インスタンスでアプリケーションが正常に実行されていないことを確認した場合は、ステータスチェック情報とシステムログを確認します。

ステータスチェックの失敗の原因となる問題の例については、「Amazon EC2 インスタンスのステータスチェック」を参照してください。

コンテンツ

ステータスチェック情報の確認

Amazon EC2 コンソールを使用して、問題のあるインスタンスを調査するには

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

  2. ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択します。

  3. [ステータスとアラーム] タブを選択すると、すべての [システムステータスのチェック]、[インスタンスステータスのチェック]、および [アタッチされた EBS ステータスのチェック] の個別の結果が表示されます。

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

  • 失敗したステータスチェックに応じてインスタンスを復旧するアラームを作成します。詳細については、「インスタンスを停止、終了、再起動、または復旧するアラームを作成する」を参照してください。

  • (インスタンスステータスチェック) インスタンスタイプを Nitro ベースのインスタンスに変更した場合、必要な ENA と NVMe ドライバーがないインスタンスから移行するとステータスチェックが失敗します。詳細については、「インスタンスタイプ変更の互換性」を参照してください。

  • EBS-backed インスタンスの場合、いったんインスタンスを停止してから再開します。詳細については、「Amazon EC2 インスタンスの停止と起動」を参照してください。

  • instance-store backed インスタンスの場合、インスタンスを終了し、代わりのインスタンスを起動します。詳細については、「Amazon EC2 インスタンスを終了する」を参照してください。

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

  • AWS Support に問い合わせるか、問題を AWS re:Post に投稿してください。

  • インスタンスが Auto Scaling グループに属している場合:

    • (システムステータスのチェックとインスタンスステータスのチェック) デフォルトでは、Amazon EC2 Auto Scaling は代替インスタンスを自動的に起動します。詳細については、『Amazon EC2 Auto Scaling ユーザーガイド』の「Auto Scaling インスタンスのヘルスチェック」を参照してください。

    • (アタッチ済みの EBS ステータスチェック) 代替インスタンスを自動的に起動するように Amazon EC2 Auto Scaling を設定する必要があります。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Monitor and replace Auto Scaling instances with impaired Amazon EBS volumes」を参照してください。

  • システムログを取得し、エラーを探します。詳細については、「システムログの取得」を参照してください。

システムログの取得

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

インスタンスを再起動してシステムログを取得するには

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

  2. ナビゲーションペインで [Instances] を選択し、インスタンスを選択します。

  3. [インスタンスの状態]、[インスタンスの再起動] の順に選択します。インスタンスが再起動するまでには数分かかることがあります。

  4. 問題がまだ存在することを確認します。再起動によって、問題が解決することがあります。

  5. インスタンスが running 状態になったら、[アクション]、[モニタリングとトラブルシューティング]、[システムログの取得] の順に選択します。

  6. 画面に表示されるログを確認し、下記の既知のシステムログエラー文のリストを使用して、問題のトラブルシューティングを行います。

  7. 問題が解決されない場合は、問題を AWS re:Post に投稿できます。

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 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-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 にお問い合わせください。

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 ボリュームがデタッチされているか、ボリュームにエラーがあります。

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

  • ラムディスクと 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 を使用します。

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

  • 既知の更新バグを確認するには、Linux ディストリビューションのドキュメントを参照してください。カーネルを変更または再インストールします。

Instance store-Backed

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

Error: 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)
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-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 Support にお問い合わせください。

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 ファイルで SELINUX=disabled と設定することで SELinux を無効にできます。mount_point、 は、リカバリインスタンス上の、ボリュームをマウントした場所です。

  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 を使用して新しいインスタンスを起動します。