オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決するにはどうすればいいですか?

所要時間4分

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスが、オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗し、正常に起動しなくなりました。

短い説明

EC2 Linux インスタンスは、以下の理由によりインスタンスのステータスチェックに失敗する場合があります。

カーネルを更新し、新しいカーネルが起動しません。
/etc/fstab のファイルシステムエントリが正しくないか、ファイルシステムが壊れています。
ネットワーク構成が正しくないインスタンスがあります。

解決策

**重要:**次の一部の手順では、インスタンスを停止する必要があります。インスタンスを停止すると、インスタンスストアボリュームに保存されているデータが失われます。インスタンスを停止する前に、データのバックアップを保存してください。Amazon Elastic Block Store (Amazon EBS) バックアップボリュームとは異なり、インスタンスストアボリュームは一時的なものであり、永続性はありません。詳細については、「Amazon EC2 インスタンスの停止と起動」を参照してください。

Amazon EC2 によって自動的にインスタンスに割り当てられた静的パブリック IPv4 アドレスは、インスタンスが停止して起動した後に変更されます。インスタンスが停止しても変わらないパブリック IPv4 アドレスを維持するには、Elastic IP アドレスを使用してください。

**注:**以下の方法では Amazon Linux 2 をベースにしたサンプルを使用していますが、これらの概念は一般的な Linux ディストリビューションに適用されます。Amazon Linux 2 以外の Linux ディストリビューションを使用している場合は、コマンド、パス、および出力が異なる場合があります。

Linux インスタンス用 EC2 シリアルコンソールを使用する

Linux インスタンス用 EC2 シリアルコンソールを有効にする場合は、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。シリアルコンソールは、起動の問題、ネットワークや SSH 設定の問題のトラブルシューティングに役立ちます。また、稼働中のネットワーク接続を必要とせずにインスタンスに接続できます。シリアルコンソールには、Amazon EC2 コンソール、または AWS コマンドラインインターフェイス (AWS CLI) からアクセスできます。

EC2 シリアルコンソールを初めて使用する際は、接続する前に前提条件とアクセスの設定方法を確認してしてください。

インスタンスにアクセスできず、シリアルコンソールへのアクセスを設定していない場合は、「Linux 用 EC2Rescue ツールを実行する」セクション、または「レスキューインスタンスを使用する」を参照してください。Linux 用 EC2 シリアルコンソールの設定については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

注: AWS CLI コマンドの実行時にエラーが発生する場合は、「Troubleshoot AWS CLI errors」を参照してください。また、必ず AWS CLI の最新バージョンを使用してください。

Linux 用 EC2Rescue ツールを実行する

EC2Rescue for Linux は、接続できないインスタンス上のオペレーティングシステムを自動的に診断してトラブルシューティングします。詳細については、「Linux 用 EC2Rescue を使用してオペレーティングシステムレベルの問題のトラブルシューティングを行うにはどうすればよいですか?」を参照してください。

レスキューインスタンスを使用してエラーを手動で修正する

仮想プライベートクラウド (VPC) で新しい EC2 インスタンスを起動します。障害が発生したインスタンスと同じ Amazon マシンイメージ (AMI) とアベイラビリティーゾーンを使用します。新しいインスタンスはレスキューインスタンスになります。

または、既存のインスタンスを使用します。既存のインスタンスは障害のあるインスタンスと同じ AMI を使用し、同じアベイラビリティーゾーンにある必要があります。
障害のあるインスタンスを停止します。
障害のあるインスタンスから Amazon EBS ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名を書き留めておきます。
レスキューインスタンスに、セカンダリデバイス (/dev/sdf) としてボリュームをアタッチします。
SSH 経由でレスキューインスタンスに接続します。
レスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します。
```
$ sudo mkdir /rescue
```
新しいディレクトリにボリュームをマウントします。
```
$ sudo mount /dev/xvdf1 /rescue
```
「Wrong Fs type or UUID duplicate, Superblock is missing or badblock found,」などのエラーが表示される場合は、「Amazon EBS ボリュームをマウントできないのはなぜですか?」を参照してください。

注:デバイス (/dev/xvdf1) が別のデバイス名でレスキューインスタンスにアタッチされている可能性があります。lsblk コマンドを実行して使用可能なディスクデバイスとそのマウントポイントを表示し、正しいデバイス名を特定してください。
まだ行っていない場合は、インスタンスのシステムログを取得してエラーを確認してください。次の手順は、システムログにリストされるエラーメッセージによって異なります。

以下は、インスタンスのステータスチェックが失敗する原因となる一般的なエラーです。その他のエラーについては、「Linux インスタンスに対するシステムログエラーのトラブルシューティング」を参照してください。

「カーネルパニック」

カーネルパニックのエラーメッセージがシステムログに記録されている場合、カーネルに vmlinuz ファイルまたは initramfsファイルがない可能性があります。正常に起動するには、vmlinuz ファイルと initramfs ファイルが必要です。

以下のコマンドを実行します。

cd /rescue/boot
ls -l

起動するカーネルバージョンに対応する vmlinuz ファイルと initramfs ファイルがあるかどうか、出力を確認してください。

以下は、カーネルバージョン 4.14.165-131.185.amzn2.x86_64 の Amazon Linux 2 インスタンスの出力例です。**/boot ** ディレクトリに initramfs-4.14.165-131.185.amzn2.x86_64.img と vmlinuz-4.14.165-131.185.amzn2.x86_64 というファイルがあるため、正常に起動します。

uname -r
4.14.165-131.185.amzn2.x86_64

cd /boot; ls -l
total 39960
-rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
drwx------ 5 root root       79 Feb 12 04:08 grub2
-rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
-rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
-rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
-rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
-rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

initramfs ファイルと vmlinuz ファイルがない場合は、両方のファイルを含む以前のカーネルを使用してインスタンスを起動してください。手順については、「更新によって Amazon EC2 インスタンスが再起動できなくなった後に、既知の安定したカーネルに戻すにはどうすればよいですか?」を参照してください。
unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをアンマウントします。
```
$ sudo umount /rescue
```
アンマウント操作が失敗する場合は、クリーンなアンマウントを行うためにレスキューインスタンスを停止または再起動する必要がある場合があります。
レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
インスタンスを起動し、インスタンスが応答するかどうかを確認します。

カーネルパニックのエラーの解決について詳しくは、「カーネルのアップグレードまたは EC2 Linux インスタンスの再起動後に「Kernel panic」エラーが表示されるのはなぜですか?を参照してください。

「Failed to mount」および「Dependency failed」

システムログの「Failed to mount」や「Dependency failed」などのエラーは、/etc/fstab ファイルのマウントポイントエントリが正しくない場合に発生します。

/etc/fstab のマウントポイントエントリが正しいかどうか確認してください。**/etc/fstab ** ファイルエントリを修正するには、「EC2 Linux インスタンスを起動しようとすると緊急モードになるのはなぜですか?」を参照してください。

ベストプラクティスは、fsck または xfs\ _repair ツールを実行してファイルシステムの不整合を修正することです。

**注:**fsck ツールまたは xfs_repair ツールを実行する前に、ファイルシステムのバックアップを作成してください。

fsck ツールまたは xfs_repair ツールを実行する前に、umount コマンドを実行してマウントポイントをアンマウントします。

$ sudo umount /rescue

ファイルシステムに応じて、fsck ツールまたは xfs_repair ツールを実行します。

ext4 ファイルシステムの場合は、次のコマンドを実行します。

$ sudo fsck /dev/sdf
fsck from util-linux 2.30.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdf: clean, 11/6553600 files,
459544/26214400 blocks

XFS ファイルシステムの場合は、次のコマンドを実行します。

$ sudo xfs_repair /dev/sdf
xfs_repair /dev/xvdf
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
インスタンスを起動し、インスタンスが応答するかどうかを確認します。

「interface eth0: failed」

ifcfg-eth0 ファイルに正しいネットワークエントリがあることを確認します。プライマリインターフェイス eth0 に対応するネットワーク設定ファイルは /etc/sysconfig/network-scripts/ifcfg-eth0 にあります。プライマリインターフェースのデバイス名が eth0 でない場合、ファイル名は ifcfg で始まり、その後にデバイス名が続きます。このファイルは、インスタンスの /etc/sysconfig/network-scripts ディレクトリにあります。

cat コマンドを実行して、プライマリインターフェイス eth0 のネットワーク設定ファイルを表示します。

/etc/sysconfig/network-scripts/ifcfg-eth0 にあるネットワーク設定ファイルの正しいエントリは次のとおりです。

**注:**以下のコマンドの eth0 は、必要に応じてご使用のプライマリインターフェースの名前に置き換えてください。

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no

[ONBOOT] が [**はい **] に設定されていることを確認します。[ONBOOT] が [はい] に設定されていない場合は、eth0 (またはプライマリネットワークインターフェイス) が起動時に開始するように設定されていません。

ONBOOT の値を変更するには、まずエディタでファイルを開きます。この例では vi エディタを使用しています。
```
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
```
I を押して挿入します。

[ONBOOT] エントリまでカーソルをスクロールして、値を [はい] に変更します。

:wq! を押し、ファイルを保存して終了します。
unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをアンマウントします。
```
$ sudo umount /rescue
```
アンマウント操作が失敗する場合は、クリーンなアンマウントを行うためにレスキューインスタンスの停止または再起動が必要な場合があります。
レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
インスタンスを起動して、インスタンスが応答するかどうかを確認します。

オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決するにはどうすればいいですか?

短い説明

解決策

Linux インスタンス用 EC2 シリアルコンソールを使用する

Linux 用 EC2Rescue ツールを実行する

レスキューインスタンスを使用してエラーを手動で修正する

関連情報

関連するコンテンツ