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

最終更新日: 2020 年 5 月 28 日

カーネルまたはシステムのアップグレードを完了した後、または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでシステムを再起動した後、インスタンスが起動に失敗し、次のメッセージが表示されます。

"VFS: ルートデバイス XXX または不明なブロックを開けません (0,0)
正しい「root=」ブートオプションを追加してください。使用可能なパーティションは次のとおりです。
カーネルパニック - 同期しない: 不明なブロックにルートファイルシステムをマウントできません (0,0)"

簡単な説明

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

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

解決方法

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

警告:

  • この手順では、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.    [アクション]、[インスタンス状態]、[停止] の順に選択します。

4.    [説明] タブで [ルートデバイス] を選択し、[EBS ID] をクリックします。

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

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

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 /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_64initramfs-4.14.138-114.102.amzn2.x86_64.img です。

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

$ exit
$ for i in dev proc sys run; do sudo umount /mnt/$i; done

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~14 通りに実行します。起動していないインスタンスのルートボリュームに chroot 環境を作成するための /boot/grub/grub.conf または /boot ディレクトリセクションに initramfs または initrd イメージがありません

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

オプション 1: /boot ディレクトリで dracut -f -v コマンドを実行して、initrd イメージまたは initramfs イメージの再構築が失敗したかどうかを判断し、不足しているモジュールを一覧表示します。
注意: 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 ディストリビューション固有のドキュメントをご参照ください。


この記事はお役に立ちましたか?

改善できることはありますか?


さらにサポートが必要な場合