EC2 Linux インスタンスが起動せず、緊急モードになるのはなぜですか?

最終更新日: 2021 年 5 月 10 日

インスタンスが緊急モードで起動する最も一般的な理由は次のとおりです。

• 破損したカーネル。
• /etc/fstab の誤ったエントリによる自動マウントの失敗。

どのようなタイプのエラーが発生しているかを確認するには、インスタンスのコンソール出力を表示します。カーネルが破損している場合は、コンソール出力に Kernel panic エラーメッセージが表示される場合があります。自動マウントの失敗が発生すると、Dependency failed メッセージがコンソール出力に表示されます。

Kernel panic エラーメッセージは、GRUB 設定または initramfs ファイルが破損している場合に発生します。カーネルの問題が存在する場合、「Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)」というエラーがコンソール出力に表示されることがあります。

Kernel panic エラーを解決するには、次の手順を実行してください。

1.    カーネルを以前の安定したカーネルに戻します。以前のカーネルに戻す方法の手順については、Amazon EC2 インスタンスが正常に再起動できないように更新した後、既知の安定したカーネルに戻すにはどうすればよいですか? を参照してください。

2.    以前のカーネルに戻したら、インスタンスを再起動します。次に、破損したカーネルの問題を修正します。

/etc/fstab ファイルの構文エラーに起因する自動マウントの失敗は、インスタンスが緊急モードになる原因となる場合があります。また、このファイルにリストされている Amazon Elastic Block Store (Amazon EBS) ボリュームがインスタンスからデタッチされている場合にも、インスタンスの起動プロセスが緊急モードになることがあります。これらの問題のいずれかが発生した場合、コンソール出力は以下のようになります。

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

上記のログメッセージ例は、起動シーケンス中に /mnt マウントポイントがマウントに失敗したことを示しています。

マウントの失敗が原因で起動シーケンスが緊急モードになることを防ぐには、次の手順を実行してください。

• セカンダリパーティション (上記の例では /mnt) の /etc/fstab ファイルに nofail オプションを追加します。Nofail オプションがあると、ボリュームまたはパーティションのマウントが失敗した場合でも、起動シーケンスが中断されません。
• それぞれのマウントポイントの /etc/fstab ファイルの最後の列として 0 を追加します。0 列を追加することによって、ファイルシステムチェックが無効化され、インスタンスを正常に起動できるようになります。

/etc/fstab ファイルを修正するために使用できる方法は 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 アドレスを使用することをお勧めします。

方法 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: AWSSupport-ExecuteEC2Rescue オートメ―ションドキュメントを実行する

インスタンスが AWS Systems Manager 向けに設定されている場合は、AWSSupport-ExecuteEC2Rescue オートメーションドキュメントを実行して起動問題を修正できます。この方法を使用する場合、手動での作業は必要ありません。オートメーションドキュメントの使用に関する情報は、チュートリアル: 到達不可能なインスタンスでの EC2Rescue ツールの実行を参照してください。

方法 3: レスキューインスタンスを使用してファイルを手動で編集する

1.    Amazon EC2 コンソールを開きます。

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

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

4.    停止したインスタンスから Amazon EBS ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。

5.    障害が発生したインスタンスと同じアベイラビリティーゾーンで、新しい EC2 インスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。

6.    ステップ 4 でデタッチしたルートボリュームを、セカンダリデバイスとしてレスキューインスタンスにアタッチします。

注意: セカンダリボリュームをアタッチするときは、異なるデバイス名を使用できます。

7.    SSH を使用してレスキューインスタンスに接続します。

8.    ステップ 6 でレスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリを作成します。以下の例のマウントポイントディレクトリは /mnt/rescue です。

$ sudo mkdir /mnt/rescue

9.    ステップ 8 で作成したディレクトリにボリュームをマウントします。

$ sudo mount /dev/xvdf /mnt/rescue

注意: デバイス (上記の例の /dev/xvdf) は、異なるデバイス名でレスキューインスタンスにアタッチされている場合があります。lsblk コマンドを使って、使用可能なディスクデバイスとマウントポイントを表示し、正しいデバイス名を確認してください。

10.    ボリュームがマウントされたら、以下のコマンドを実行して /etc/fstab ファイルを開きます。

$ sudo vi /mnt/rescue/etc/fstab

11.    必要に応じて /etc/fstab の のエントリを編集します。以下の出力例では、UUID で定義された 3 つの EBS ボリューム、両方のセカンダリボリュームに追加された nofail オプション、および各エントリの最後の列として 0 が示されています。

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.    ファイルを保存してから、umount コマンドを実行してボリュームをアンマウントします。

$ sudo umount /mnt/rescue

13.    一時的なインスタンスからボリュームをデタッチします。

14.    ボリュームを元のインスタンスにアタッチしてから、インスタンスを起動してそれが正常に起動することを確認します。