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

簡単な説明

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

• 破損したカーネル。
• /etc/fstab のエントリが間違っているため、自動マウントに失敗しました。

発生しているエラーの種類を確認するには、インスタンスのコンソール出力を表示します。カーネルが破損している場合、コンソール出力にカーネルパニックエラーメッセージが表示されることがあります。自動マウントに失敗した場合、依存関係の失敗 メッセージがコンソール出力に表示されます。

解決策

カーネルパニックエラー

カーネルパニックエラーメッセージは、grub 設定または initramfs ファイルが破損している場合に発生します。カーネルに問題がある場合は、「Kernel panic - not syncing」というエラーが表示されることがあります。 VFS: コンソール出力の「unknown-block (8,1)」に root fs をマウントできません。

カーネルパニックエラーの解決方法

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** マウントポイントマウントに失敗したことを示しています。

マウントの失敗が原因でブートシーケンスが緊急モードになるのを防ぐには:

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

/etc/fstab ファイルを修正するには 3 つの方法があります。

重要:

方法 2 と 3 では、インスタンスを停止して起動する必要があります。次の点に注意してください。

• インスタンスがインスタンスストアベースの場合や、データを含むインスタンスストアボリュームがある場合、インスタンスを停止するとデータは失われます。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
• インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了する可能性があります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用して起動するインスタンスは、AWS Auto Scaling グループの一部である可能性があります。このシナリオでのインスタンスの終了は、Auto Scaling グループのインスタンススケールイン保護設定によって異なります。インスタンスが Auto Scaling グループの一部である場合は、](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-enter-exit-standby.html)解決手順を開始する前に Auto Scaling[ グループから一時的にインスタンスを削除します。
• インスタンスを停止および再開すると、インスタンスのパブリック IP アドレスが変更されます。外部トラフィックをインスタンスにルーティングする場合は、パブリック IP アドレスの代わりに Elastic IP アドレス を使用するのがベストプラクティスです。

詳細については、「インスタンスを停止するとどうなるか」を参照してください。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールをオンにした場合、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) にアクセスできます。EC2 シリアルコンソールを使用する際、インスタンスに接続するための有効な接続は必要ありません。

**注:**EC2 シリアルコンソールをこれまで使用したことがない場合は、接続を試みる前に前提条件を確認し、アクセス権を設定してください。インスタンスにアクセスできず、シリアルコンソールへのアクセス権を設定していない場合は、方法 2 の指示に従ってください。

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

2.    [インスタンス] を選択します。

3.    インスタンスを選択し、[アクション]、[監視とトラブルシューティング]、[EC2 シリアルコンソール]、[接続] を選択します。

または

インスタンスを選択し、[接続]、[EC2 シリアルコンソール]、[接続] を選択します。

ブラウザ内にターミナルウィンドウが開きます。

4.    Enter キーを押します。シリアルコンソールに接続している場合は、ログインプロンプトに戻ります。画面が黒いままの場合は、次の情報を参考にシリアルコンソールへの接続に関する問題を解決できます。

• **シリアルコンソールへのアクセス権を設定していることを確認してください。**詳細については、「EC2 シリアルコンソールへのアクセス権を設定する」を参照してください。

• **SysRq を使用してシリアルコンソールに接続します。**SysRq では、ブラウザベースのクライアントを使用して接続する必要はありません。詳細については、「SysRq を使用した Linux インスタンスのトラブルシューティング」を参照してください。

• **getty を再起動します。**インスタンスに SSH でアクセスできる場合は、SSH を使用してインスタンスに接続し、次のコマンドを使用して getty を再起動します。

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• **インスタンスを再起動します。**SysRq、EC2 コンソール、または AWS CLI を使用してインスタンスを再起動できます。詳細については、「SysRQ を使用した Linux インスタンスのトラブルシューティング」または「インスタンスの再起動」を参照してください。

5.    ログインプロンプトで、以前に設定したパスワードベースのユーザーのユーザー名を入力し、Enter キーを押します。

6.    パスワードプロンプトで、パスワードを入力し、Enter キーを押します。

これでインスタンスにログインし、シリアルコンソールを使用してトラブルシューティングを行うことができます。

独自のキーと SSH クライアントを使用して接続することもできます。

EC2 シリアルコンソールの使用方法の詳細については、「EC2シリアルコンソールに接続する」を参照してください。

方法 2: AWSSupport-ExecuteEC2Rescue automation ドキュメントの実行

インスタンスが 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 のエントリを編集します。次の出力例では、3 つの EBS ボリュームが UUID で定義され、両方のセカンダリボリュームに 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.    ボリュームを元のインスタンスにアタッチし、インスタンスを起動して正常に起動することを確認します。