更新が原因で EC2 インスタンスの再起動がブロックされた後に、既知の安定したカーネルに戻す方法を教えてください。

簡単な説明

EC2 Linux インスタンスでカーネルを更新したものの、カーネルが壊れている場合、インスタンスを再起動することはできません。また、SSH を使用して問題が発生したインスタンスに接続することもできません。

この問題をトラブルシューティングするには、EC2 シリアルコンソールを使用してルートボリュームにアクセスします。または、一時的なレスキューインスタンスを作成し、そのレスキューインスタンスに Amazon Elastic Block Store (Amazon EBS) ボリュームを再マウントします。GNU GRUB で以前のカーネルを使用するように設定を行い、インスタンスを再起動します。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

インスタンスのルートボリュームにアクセスします。

ルートボリュームにアクセスするには、EC2 シリアルコンソールまたはレスキューインスタンスを使用します。

EC2 シリアルコンソールを使用する

前提条件: EC2 シリアルコンソールへのアクセス設定を完了する必要があります。インスタンスにアクセスできず、アクセスをまだ設定していない場合は、レスキューインスタンスを使用してルートボリュームにアクセスする必要があります。また、シリアルコンソールの前提条件に準拠していることを確認してください。

Linux で EC2 シリアルコンソールを有効化した場合は、そのコンソールを Nitro ベースのインスタンスタイプに使用すると、ブート、ネットワーク設定、SSH 設定の問題をトラブルシューティングできます。

シリアルコンソールを使用してインスタンスに接続する場合は、動作中のネットワーク接続は必要ありません。

シリアルコンソールを使用する前に、AWS アカウントレベルでシリアルコンソールへのアクセスを許可する必要があります。次に、IAM ユーザーにアクセス許可を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。シリアルコンソールを使用するすべてのインスタンスには、パスワードベースのユーザーが少なくとも 1 人含まれている必要があります。

レスキューインスタンスを使用する

重要: インスタンスストアを使用するインスタンスでは、この手順を実行しないでください。復旧手順ではインスタンスを停止して起動する必要があるため、インスタンスのデータが失われる可能性があります。

レスキューインスタンスを使用してルートボリュームにアクセスするには、次の手順を実行します。

1. ルートボリュームの Amazon EBS スナップショットを作成します。

2. 問題が発生したインスタンスを停止します。

3. 問題が発生したインスタンスから Amazon EBS ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名を書き留めておきます。
   注: 後の手順で EBS ボリュームを識別しやすくするために、デタッチする前にボリュームにタグを付けてください。ルートデバイスは Amazon マシンイメージ (AMI) によって異なります。たとえば、Amazon Linux 2 (AL2) と Amazon Linux 2023 (AL2023) では /dev/xvda を使用します。Ubuntu 14、16、18、CentOS 7、および Red Hat Enterprise Linux (RHEL) 7.5 は /dev/sda1 を使用します。

4. スナップショットと同じアベイラビリティーゾーンで、レスキュー EC2 インスタンスを起動します。
   注: インスタンスの製品コードを確認してください。一部の製品コードでは、同じオペレーティングシステム (OS) タイプで EC2 インスタンスを起動する必要があります。たとえば、問題が発生したインスタンスが有料の RHEL AMI である場合は、同じ製品コードを使用して AMI を起動する必要があります。AL2 インスタンスを使用している場合は、エラーを避けるために AL2 レスキューインスタンスを作成する必要があります。

5. レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として ボリュームをアタッチします。

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

7. 使用可能なディスクデバイスを確認するには、次のコマンドを実行します。

   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:0     0   15G  0 disk
       └─xvdf1 202:1 0   15G  0 part

   注: Nitro ベースのインスタンスは、EBS ボリュームを NVMe ブロックデバイスとして表示します。ディスク名は nvme[0-26]n1 という形式です。Nitro ベースのインスタンスでの出力例:

   NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   nvme0n1        259:0    0    8G  0 disk
   └─nvme0n1p1    259:1    0    8G  0 part /
   └─nvme0n1p128  259:2    0    1M  0 part
   nvme1n1        259:3    0  100G  0 disk
   └─nvme1n1p1    259:4    0  100G  0 part /

8. root ユーザーになるには、以下のコマンドを実行します。

   sudo -i

9. マウントされたボリュームのルートパーティションを /mnt にマウントするには、次のコマンドを実行します。

   mount -o nouuid /dev/xvdf1 /mnt

   注: /dev/xvdf1 を実際のボリュームのルートパーティションに置き換えます。構成に /mnt が存在しない場合は、次のコマンドを実行してマウントディレクトリを作成し、ルートパーティションを新しいディレクトリにマウントします。

   mkdir /mnt
   mount -o nouuid /dev/xvdf1 /mnt

   注: 上記の mount コマンドを実行するとエラーが発生する場合は、代わりに次のコマンドを実行してください。

   mount /dev/xvdf1 /mnt

   次に、マウントディレクトリを使用して問題が発生したインスタンスのデータにアクセスします。

10. 次のコマンドを実行し、レスキューインスタンスの /dev、/run、/proc、/sys を、マウントしたボリュームと同じパスにマウントします。

for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done

11. 別の /boot パーティションがある場合は、そのパーティションを /mnt/boot にマウントします。
12. マウントディレクトリに移動するには、次のコマンドを実行します。

chroot /mnt

GRUB ブートローダーでデフォルトカーネルを更新する

壊れたカーネルはリストの位置 0 にあり、最後の安定したカーネルは位置 1 にあります。壊れたカーネルを安定したカーネルに置き換えるには、使用するディストリビューションに応じて次の手順を実行します。

GRUB1 (Legacy GRUB) (Red Hat 6)

次のコマンドを実行し、/boot/grub/grub.conf ファイル内の壊れたカーネルを安定したカーネルに置き換えます。

sed -i '/^default/ s/0/1/' /boot/grub/grub.conf

GRUB2 for Ubuntu (14 LTS、16.04、18.04)

次の手順を実行します。

1. /etc/default/grub ファイル内の壊れた GRUB_DEFAULT=0 のデフォルトメニューエントリを、安定した GRUB_DEFAULT=saved 値に置き換えるには、次のコマンドを実行します。

   sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. GRUB が変更を認識できていることを確認するには、次のコマンドを実行します。

   update-grub

   注: grub 設定ファイルの再ビルド時に、「device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed」というエラーが発生する場合があります。この問題を解決するには、/etc/default/grub ファイルに GRUB_DISABLE_OS_PROBER=true パラメータを追加し、上記のコマンドを再実行します。

3. 次回の再起動時に Amazon EC2 が安定したカーネルをロードするようにするには、次のコマンドを実行します。

   grub-set-default 1

GRUB2 (RHEL 7、AL2)

次の手順を実行します。

1. /etc/default/grub ファイル内の壊れた GRUB_DEFAULT=0 のデフォルトメニューエントリを、安定した GRUB_DEFAULT-saved 値に置き換えるには、次のコマンドを実行します。

   sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. GRUB を更新して /boot/grub2/grub.cfg ファイルを再生成するには、次のコマンドを実行します。

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

   注: grub 設定ファイルの再ビルド時に、「device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed」というエラーが発生する場合があります。この問題を解決するには、/etc/default/grub ファイルに GRUB_DISABLE_OS_PROBER=true パラメータを追加し、上記のコマンドを再実行します。

3. 次回の再起動時に Amazon EC2 が安定したカーネルをロードするようにするには、次のコマンドを実行します。

   grub2-set-default 1

GRUB2 (RHEL 8、CentOS 8、AL2023)

GRUB2 では、以前の grub.cfg 形式ではなく、blscfg ファイルおよび、/boot/loader のエントリをブート設定に使用します。blscfg ファイルを管理し、/boot/loader/entries/ から情報を取得するには、grubby ツールの使用をおすすめします。blscfg ファイルが存在しないか破損している場合、grubby には結果が表示されません。機能を回復するには、ファイルを再生成する必要があります。

GRUB2 でデフォルトカーネルを更新するには、次の手順を実行します。

1. 現在のデフォルトカーネルを確認するには、次のコマンドを実行します。

   grubby --default-kernel

2. 使用可能なすべてのカーネルとそのインデックスを表示するには、次のコマンドを実行します。

   grubby --info=ALL

   出力例:

   root@ip-172-31-29-221 /]# grubby --info=ALLindex=0
   kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
   title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
   id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"
   index=1
   kernel="/boot/vmlinuz-0-rescue-0c75beb2b6ca4d78b335e92f0002b619"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-0-rescue-0c75beb2b6ca4d78b335e92f0002b619.img"
   title="Red Hat Enterprise Linux (0-rescue-0c75beb2b6ca4d78b335e92f0002b619) 8.4 (Ootpa)"
   id="0c75beb2b6ca4d78b335e92f0002b619-0-rescue"
   index=2
   kernel="/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-4.18.0-305.3.1.el8_4.x86_64.img $tuned_initrd"
   title="Red Hat Enterprise Linux (4.18.0-305.3.1.el8_4.x86_64) 8.4 (Ootpa)"
   id="ec2fa869f66b627b3c98f33dfa6bc44d-4.18.0-305.3.1.el8_4.x86_64"

   インスタンスのデフォルトとして設定したカーネルのパスを書き留めておきます。上記の例では、インデックス 2 のカーネルパスは /boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64 です。

3. インスタンスのデフォルトカーネルを変更するには、次のコマンドを実行します。

   grubby --set-default=/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64

   注: 4.18.0-305.3.1.el8_4.x86_64 は、実際のカーネルのバージョン番号に置き換えます。

4. デフォルトカーネルが正しく設定されていることを確認するには、次のコマンドを実行します。

   grubby --default-kernel

インスタンスを再起動する

EC2 シリアルコンソールを使用した場合、Amazon EC2 は安定したカーネルをロードするようになるため、インスタンスを再起動できます。

レスキューインスタンスを使用してルートボリュームにアクセスした場合は、次の手順を実行します。

1. 次のコマンドを実行して chroot を終了し、/dev、/run、/proc、/sys をアンマウントします。

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

2. レスキューインスタンスを停止します。

3. レスキューインスタンスからルートボリュームをデタッチします。

4. ルートボリュームを /dev/xvda または /dev/sda1 というルートボリュームとして元のインスタンスにアタッチする

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

6. 完了すると、Amazon EC2 が安定したカーネルをロードするようになります。インスタンスを再起動できます。