オペレーティングシステムの問題により、EC2 Linux インスタンスでインスタンスのステータスチェックが失敗しました。この解決方法を教えてください。
オペレーティングシステムの問題が原因で、Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスでインスタンスのステータスチェックが失敗しました。現在は正常に起動しません。解決方法を教えてください。
簡単な説明
EC2 Linux インスタンスは、以下の理由でインスタンスのステータスチェックに失敗することがあります。
- カーネルを更新したが、新しいカーネルが起動しなかった。
- /etc/fstab でのファイルシステムのエントリが正しくないか、ファイルシステムが破損しています。
- インスタンスに正しくないネットワーク設定があります。
解決方法
OS の問題のトラブルシューティングには、3 つの方法があります。
重要:
方法 2 と 3 では、インスタンスを停止して再起動する必要があります。以下の点に注意してください。
- インスタンスが Instance Store-Backed である場合、またはインスタンスにデータを含むインスタンスストアボリュームがある場合、インスタンスを停止するとデータが失われます。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
- インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了することがあります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用してインスタンスを起動した場合、インスタンスは AWS Auto Scaling グループの一部である可能性があります。このシナリオでのインスタンスの終了は、Auto Scaling グループのインスタンスのスケールイン保護の設定に応じて異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
- インスタンスを停止および再開すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングする際は、パブリック IP アドレスではなく Elastic IP アドレスを使用することをお勧めします。Amazon Route 53 を使用している場合は、パブリック IP が変更されたときに Route 53 DNS レコードを更新する必要がある場合があります。
方法 1: EC2 シリアルコンソールを使用する
Linux 用 EC2 シリアルコンソールを有効にした場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。シリアルコンソールには、Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してアクセスできます。
シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与します。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。また、シリアルコンソールを使用するすべてのインスタンスには、少なくとも 1 名のパスワードベースユーザーを含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスを設定していない場合は、方法 2 の手順に従います。Linux 用 EC2 シリアルコンソールの設定の詳細については、EC2 シリアルコンソールへのアクセスを設定するをご参照ください。
注意: AWS CLI コマンドの実行時にエラーが表示される場合は、AWS CLI の最新バージョンを使用していることを確認してください。
方法 2: Linux 用 EC2Rescue ツールを実行する
Linux 用 EC2Rescue は、到達不可能なインスタンスでのオペレーティングシステム問題の診断とトラブルシューティングを自動化します。詳細については、「Linux 用 EC2Rescue を使用してオペレーティングシステムレベルの問題をトラブルシューティングする方法を教えてください。」を参照してください。
方法 3: レスキューインスタンスを使用して手動でエラーを修正する
1. 同じ Amazon マシンイメージ (AMI) を使用して、Virtual Private Cloud (VPC) 内で新しい EC2 インスタンスを起動します。障害のあるインスタンスと同じアベイラビリティーゾーンで新しいインスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。
または、同じ AMI を使用しかつ障害のあるインスタンスと同じアベイラビリティーゾーンにある場合は、アクセスできる既存のインスタンスを使用します。
3. 障害のあるインスタンスから Amazon Elastic Block Store (Amazon EBS) ルートボリュームの接続解除 (/dev/xvda または /dev/sda1) を行います。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めます。
4. レスキューインスタンスにセカンダリデバイス (/dev/sdf) としてボリュームをアタッチします。
5. SSH を使用してレスキューインスタンスに接続します。
6. レスキューインスタンスにアタッチされた新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します。
$ sudo mkdir /rescue
7. ステップ 6 で作成したディレクトリにボリュームをマウントします。
$ sudo mount /dev/xvdf1 /rescue
注意: デバイス (/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 インスタンスを起動し、インスタンスが応答していることを確認します。
カーネルパニックエラーの解決については、「カーネルをアップグレードした後、または EC2 Linux インスタンスを再起動しようとすると、「カーネルパニック」エラーが表示されます。どうすれば修正できますか?
マウントに失敗したか、依存関係が失敗した
システムログに「マウントに失敗しました」や「依存関係に失敗しました」などのエラーが表示された場合、/etc/fstab ファイルのマウントポイントエントリが正しくない可能性があります。
1. /etc/fstab のマウントポイントエントリが正しいことを確認します。/etc/fstab ファイルのエントリを修正する方法については、EC2 インスタンスが起動せず、緊急モードになるのはなぜですか? にある /etc/fstab file セクションの不正なエントリによる自動マウントの失敗を参照してください。
2. ファイルシステムエラーを修正するには、fsck または xfs_repair ツールを実行することをお勧めします。ファイルシステムに不整合がある場合、fsck または xfs_repair ツールによって修正されます。
注意: fsck または xfs_repair ツールを実行する前に、ファイルシステムのバックアップを作成します。
fsck または xfs_repair ツールを実行する前に、unmount コマンドを実行してマウントポイントをマウント解除します。
$ sudo umount /rescue
ファイルシステムに応じて、fsk または 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. EC2 インスタンスを起動し、インスタンスが応答していることを確認します。
インターフェイス eth0 の起動中: 失敗
「インターフェイス 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 インスタンスが到達不能で、そのステータスチェックの一方、または両方が失敗するのはなぜですか?
関連するコンテンツ
- 質問済み 5年前
- AWS公式更新しました 9ヶ月前
- AWS公式更新しました 3年前
- AWS公式更新しました 5ヶ月前