EC2 Linux インスタンスを起動しようとすると緊急モードになるのはなぜですか?

所要時間2分

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスを起動すると、インスタンスが緊急モードになり、ブートプロセスが失敗します。その後、インスタンスにアクセスできなくなります。

簡単な説明

次のような原因で、インスタンスが緊急モードで起動することがあります。

インスタンスに破損したカーネルがある。
/etc/fstab ファイルのエントリが誤っているため、自動マウントが失敗する。

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

解決策

カーネルパニックエラー

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

カーネルパニックエラーを解決するには、次の手順を実行します。

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 ファイルに次の記述を追加します。

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

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

重要:

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

インスタンスを停止すると、インスタンスストアボリュームに保存されているデータは失われます。インスタンスを停止する前に、データのバックアップを保存しておいてください。EBS-backed ボリュームと異なり、インスタンスストアボリュームはエフェメラルなので、データ永続性はサポートされていません。
Amazon EC2 の起動時または開始時にインスタンスへ自動的に割り当てた静的パブリック IPv4 アドレスは、いったん停止してから起動すると変更されます。インスタンスが停止しても変更されないパブリック IPv4 アドレスを保持するには、Elastic IP アドレスを使用してください。

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

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

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

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

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 キーを押します。

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

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

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

方法 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 のエントリを編集します。次に示す出力例では、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 コマンドを実行してボリュームをアンマウントします。