カーネルをアップグレードした後、または EC2 Linux インスタンスを再起動しようとすると、「カーネルパニック」エラーが表示されます。これを修正するにはどうすればよいですか?

簡単な説明

以下の理由により、インスタンスが起動に失敗し、カーネルパニックエラーメッセージが表示されることがあります。

• /boot/grub/grub.conf の新しく更新されたカーネル設定に initramfs または initrd イメージがありません。または、initrd ファイルまたは initramfs ファイル自体が /boot ディレクトリに存在しません。
• カーネルまたはシステムパッケージは、容量不足のため、アップグレードプロセス中に完全にインストールできませんでした。
• initrd または initramfs イメージにサードパーティーのモジュールがありません。例えば、NVMe、LVM、または RAID モジュールなどです。

解決方法

initramfs または initrd イメージが /boot/grub/grub.conf または /boot ディレクトリに存在しない

これを修正するには、次のいずれかの方法を使用します。

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

Windows 用 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: レスキューインスタンスを使用する

警告:

• この手順では、EC2 インスタンスを停止して起動する必要があります。インスタンスがインスタンスストアでバックアップされているか、データを含むインスタンスストアボリュームがある場合、インスタンスが停止するとデータが失われますのでご注意ください。詳細については、インスタンスのルートデバイスタイプの判別を参照してください。
• EC2 Auto Scaling を使用してインスタンスを起動する場合、インスタンスを停止するとインスタンスが終了する可能性があります。一部の AWS のサービスは、Amazon EMR、AWS CloudFormation、および AWS Elastic Beanstalk など、EC2 Auto Scaling を使用してインスタンスを起動しています。Auto Scaling グループのインスタンススケールイン保護設定を確認します。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
• インスタンスを停止して起動すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部のトラフィックをルーティングするときは、パブリック IP アドレスではなく Elastic IP アドレスを使用することがベストプラクティスです。

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

2.    ナビゲーションペインで [Instances] を選択し、障害が発生したインスタンスを選択します。

3.    [Actions] (アクション)、[Instance State] (インスタンス状態)、[Stop instance] (インスタンスを停止) の順に選択します。

4.    [Storage] (ストレージ) タブで、[Root device] (ルートデバイス) を選択し、[Volume ID] (ボリューム ID) を選択します。

注: ステップ 5 に進む前に、ルートボリュームのスナップショットをバックアップとして作成できます。

5.    [Actions] (アクション)、[Detach Volume] (ボリュームをデタッチ) (/dev/sda1 または /dev/xvda)、[Yes, Detach] (はい、デタッチします) の順に選択します。

6.    [状態] が [利用可能] であることを確認します。

7.    元のインスタンスと同じアベイラビリティーゾーンで、同じオペレーティングシステムと同じカーネルバージョンを使用して新しい EC2 インスタンスを起動します。最初の起動後に適切なカーネルバージョンをインストールし、再起動を実行できます。この新しいインスタンスはレスキューインスタンスです。

8.    レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] をクリックし、元のインスタンスの接続解除したルートボリュームを選択します。

9.    [アクション]、[ボリュームのアタッチ] の順に選択します。

10.    レスキューインスタンス ID (1-xxxx) を選択し、/dev/xvdf と入力します。

11.     次のコマンドを実行して、障害のあるインスタンスのルートボリュームがレスキューインスタンスに正常にアタッチされていることを確認します。

$ lsblk

以下に出力の例を示します。

NAME    MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0     0   15G  0  disk
└─xvda1 202:1     0   15G  0  part /
xvdf    202:80    0   15G  0  disk
└─xvdf1 202:0     0   15G  0  part

12.    マウントディレクトリを作成し、/mnt の下にマウントします。

$ mount -o nouuid /dev/xvdf1 /mnt

13.次のコマンドを実行して chroot 環境を呼び出します。

$ for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done

14.    マウントされた /mnt ファイルシステムで chroot コマンドを実行します。

$ chroot /mnt

注: 作業ディレクトリは「/」に変更されます。

15.    オペレーティングシステムに基づいて、次のコマンドを実行します。

RPM ベースのオペレーティングシステム:

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

$ sudo dracut -f -vvvvv

Debian ベースのオペレーティングシステム:

$ sudo update-grub && sudo update-grub2

$ sudo update-initramfs -u -vvvvv

16.    initrd または initramfs イメージが /boot ディレクトリにあり、そのイメージに対応するカーネルイメージがあることを確認します。例えば、vmlinuz-4.14.138-114.102.amzn2.x86_64 と initramfs-4.14.138-114.102.amzn2.x86_64.img です。

17.    最新のカーネルに対応する initrd または initramfs イメージがあることを確認したら、次のコマンドを実行して chroot 環境を終了してクリーンアップします。

$ exit

umount /mnt/{dev,proc,run,sys,}

18.    ルートボリュームをレスキューインスタンスからデタッチし、ボリュームを元のインスタンスに接続します。

19.    元のインスタンスを起動します。

更新中にカーネルまたはシステムパッケージが完全にインストールされていない

以前のカーネルバージョンに戻します。手順については、Amazon EC2 インスタンスが更新によって正常に再起動しなくなった場合に既知の安定したカーネルに戻す方法を教えてくださいを参照してください。

initrd または initramfs イメージにサードパーティーのモジュールがない

initrd または initramfs イメージに不足しているモジュールを特定するために調査します。その後、イメージにモジュールを戻すために追加できるかどうかを確認します。多くの場合、インスタンスを再構築するのは簡単です。

以下は、Nitro プラットフォームで実行されている Amazon Linux 2 インスタンスからのコンソール出力の例です。インスタンスには、initramfs イメージからの nvme.ko モジュールがありません。

dracut-initqueue[1180]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[1180]: Warning: Could not boot.
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
dracut-initqueue[1180]: Warning: /dev/disk/by-uuid/55da5202-8008-43e8-8ade-2572319d9185 does not exist
dracut-initqueue[1180]: Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line.
Starting Show Plymouth Power Off Screen...

カーネルパニックエラーの原因がサードパーティーモジュールの不足によるものかどうかを確認するには、次の操作を行います。

1.    前のセクションの方法 1: EC2 シリアルコンソールを使用するを使用して、起動しないインスタンスのルートボリュームに chroot 環境を作成します。

• または -

前のセクションの方法 2: レスキューインスタンスを使用するのステップ 1～14 を使用して、起動しないインスタンスのルートボリュームに chroot 環境を作成します。

2.    次の 3 つのオプションのいずれかを使用して、initramfs または initrd イメージから不足しているモジュールを特定します。

オプション 1: /boot ディレクトリで dracut -f -v コマンドを実行して、initrd イメージまたは initramfs イメージの再構築が失敗したかどうかを判断します。また、dracut -f -v コマンドを使用して、不足しているモジュールを一覧表示します。
注: dracut -f -v コマンドは、initrd または intramifs イメージに不足しているモジュールを追加する場合があります。コマンドでエラーが見つからない場合は、インスタンスの再起動をお試しください。インスタンスが正常に再起動した場合、コマンドはエラーを解決しました。

オプション 2: lsinitrd initramfs-4.14.138-114.102.amzn2.x86_64.img | less コマンドを実行して、initrd または initramfs ファイルの内容を表示します。initramfs-4.14.138-114.102.amzn2.x86_64.img をイメージの名前に置き換えます。

オプション 3: /usr/lib/modules ディレクトリを検査します。

3.     不足しているモジュールが見つかった場合は、カーネルに追加し直すことができます。モジュールを取得してカーネルに追加する方法については、Linux ディストリビューション固有のドキュメントを参照してください。

---