オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決するにはどうすればいいですか?
Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスが、オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗しました。正常に起動しなくなりました。
短い説明
EC2 Linux インスタンスは、以下の理由によりインスタンスのステータスチェックに失敗する場合があります。
- カーネルを更新し、新しいカーネルが起動しません。
- /etc/fstab のファイルシステムエントリが正しくないか、ファイルシステムが壊れています。
- ネットワーク構成が正しくないインスタンスがあります。
決議
OS の問題のトラブルシューティングをするための 3 つの方法があります。
**重要事項:**次の一部の手順では、インスタンスを停止する必要があります。インスタンスストアボリュームに格納されているデータは、インスタンスが停止されると失われます。インスタンスを停止する前に、データのバックアップを必ず保存してください。Amazon Elastic Block Store (Amazon EBS) バックアップボリュームとは異なり、インスタンスストアボリュームは一時的なもので、データの永続性をサポートしていません。
Amazon EC2 が起動時または開始時にインスタンスに自動的に割り当てた静的パブリック IPv4 アドレスは、停止して開始すると変更されます。インスタンスの停止時に変わらないパブリック IPv4 アドレスを保持するには、Elastic IP アドレスを使用します。
詳細については、「インスタンスを停止するとどうなるか」をご参照ください。
Linux インスタンス用 EC2 シリアルコンソールを使用します
Linux インスタンス用 EC2 シリアルコンソールを有効にする場合は、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。シリアルコンソールは、起動の問題、ネットワークや SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、稼働中のネットワーク接続を必要とせずに、インスタンスに接続します。シリアルコンソールにアクセスするには、Amazon EC2 コンソール、または AWS コマンドラインインターフェイス (AWS CLI) を使用します。
EC2 シリアルコンソールを初めて使用する場合は、接続を試みる前に、必要条件を確認してからアクセスを設定してください。
インスタンスにアクセスできず、シリアルコンソールへのアクセスを設定していない場合は、「EC2Rescue for Linux ツールの実行」または「レスキューインスタンスの使用」の指示に従ってください。Linux 用 EC2 シリアルコンソールの設定の詳細については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。
注記: AWS CLI コマンドを実行する際にエラーが発生する場合は、AWS CLI の最新バージョンを使用していることを確認してください。
EC2Rescue for Linus ツールを実行します
EC2Rescue for Linux は、接続できないインスタンス上のオペレーティングシステムを自動的に診断してトラブルシューティングします。詳細については、「Linux 用 EC2Rescue for Linux を使用してオペレーティングシステムレベルの問題のトラブルシューティングを行うにはどうすればよいですか?」を参照してください。
レスキューインスタンスを使用して手動でエラーを修正します
1.仮想プライベートクラウド (VPC) で、新しい EC2 インスタンスを起動します。障害のあるインスタンスと同じ Amazon マシンイメージ (AMI) および同じアベイラビリティーゾーンを使用します。新しいインスタンスはレスキューインスタンスになります。
または、既存のインスタンスを使用します。既存のインスタンスは障害のあるインスタンスと同じ AMI を使用し、同じアベイラビリティーゾーンにある必要があります。
3.障害のあるインスタンスから Amazon Elastic Block Store (Amazon EBS) のルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めます。
4.レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として ボリュームをアタッチします。
6.レスキューインスタンスにアタッチした新しいボリュームの、マウントポイントディレクトリ (/rescue) を作成します。
$ sudo mkdir /rescue
7.新しいディレクトリにボリュームをマウントします:
$ sudo mount /dev/xvdf1 /rescue
間違った Fs タイプまたは UUID が重複している、スーパーブロックがない、または不正ブロックが見つかったなどのエラーが表示される場合は、「Amazon EBS ボリュームをマウントできないのはなぜですか?」を参照してください。
注記:デバイス (/dev/xvdf1) が別のデバイス名でレスキューインスタンスにアタッチされている可能性があります。lsblk コマンドを使用して使用可能なディスクデバイスとそのマウントポイントを表示し、正しいデバイス名を特定します。
8.まだ行っていない場合は、インスタンスのシステムログを取得してエラーを確認してください。次の手順は、システムログにリストされるエラーメッセージによって異なります。以下のものは、インスタンスのステータスチェックが失敗する原因となる一般的なエラーのリストです。その他のエラーについては、「Linux ベースのインスタンスのシステムログエラーのトラブルシューティング」を参照してください。
カーネルパニック
カーネルパニックエラーメッセージがシステムログに記録されている場合、カーネルには vmlinuz ファイルまたは initramfsファイルがない可能性があります。正常に起動するには、vmlinuz ファイルと initramfs ファイルが必要です。
1.次のコマンドを実行してください。
cd /rescue/boot ls -l
2.出力を確認して、起動するカーネルバージョンに対応する 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
3.initramfs または vmlinuz ファイルが存在しない場合は、両方のファイルを含む以前のカーネルを使用してインスタンスを起動してみてください。以前のカーネルを使用してインスタンスを起動する方法の手順については、「更新のせいで Amazon EC2 インスタンスが正常に再起動しなくなった後に、既知の安定したカーネルに戻すにはどうすればよいですか?」を参照してください。
4.unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをアンマウントします。
$ sudo umount /rescue
アンマウント操作が成功しなかい場合は、クリーンなアンマウントを行うためにレスキューインスタンスを停止または再起動する必要がある場合があります。
5.レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、そのボリュームを元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
6.インスタンスを起動し、インスタンスが応答するかどうかを確認してください。
カーネルパニックエラーの解決に関する追加情報については、「カーネルのアップグレードまたは EC2 Linux インスタンスの再起動後に「カーネルパニック」エラーが表示されるのはなぜですか?を参照してください。
マウントに失敗、または依存関係失敗
システムログの「マウントに失敗」や「依存関係失敗」などのエラーは、/etc/fstab ファイルのマウントポイントエントリが正しくないことを示しています。
1./etc/fstab のマウントポイントエントリが正しいことを確認してください。/etc/fstab ファイルエントリの修正方法については、「EC2 Linux インスタンスを起動しようとすると緊急モードになるのはなぜですか?」の /etc/fstab ファイル内のエントリが正しくないため自動的にマウントに失敗する」を参照してください。
2.fsck ツールまたは xfs_repair ツールを実行してファイルシステムのエラーを修正するのがベスト・プラクティスです。ファイルシステムに不整合がある場合、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
3.レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、そのボリュームを元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
4.インスタンスを起動し、インスタンスが応答するかどうかを確認してください。
インターフェイス eth0 の起動に失敗しました
ifcfg-eth0 ファイルに正しいネットワークエントリがあることを確認してください。プライマリインターフェイス eth0 に対応するネットワーク設定ファイルは /etc/sysconfig/network-scripts/ifcfg-eth0 にあります。プライマリインターフェースのデバイス名が eth0 でない場合は、ifcfg で始まりその後にデバイス名が続くファイルがあります。このファイルは、インスタンスの /etc/sysconfig/network-scripts ディレクトリにあります。
1.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
2.前の例のように、ONBOOT が yes に設定されていることを確認します。ONBOOT が yes に設定されていない場合、eth0 (またはプライマリネットワークインターフェイス) は起動時に開始するように設定されていません。
ONBOOT 値を変更するには:
ファイルをエディターで開きます。この例では、vi エディターを使用しています。
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
I を押して挿入します。
ONBOOT エントリまでカーソルをスクロールして、値を yes に変更します。
:wq! を押してファイルを保存し終了します。
3.unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをアンマウントします。
$ sudo umount /rescue
アンマウント操作が成功しない場合は、クリーンなアンマウントを行うためにレスキューインスタンスを停止または再起動する必要がある場合があります。
4.レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチしてから、そのボリュームを元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。
5.インスタンスを起動してから、インスタンスが応答するかどうかを確認してください。
関連情報
EC2 Linux インスタンスにアクセスできず、ステータスチェックの一方または両方が失敗するのはなぜですか?
ステータスチェックに失敗したインスタンスのトラブルシューティング
Linux インスタンスのタイプを Nitro ベースのインスタンスタイプに変更した後に Linux インスタンスが起動しないのはなぜですか?
関連するコンテンツ
- AWS公式更新しました 2ヶ月前
- AWS公式更新しました 5ヶ月前
