Amazon EC2 インスタンスが更新によって正常に再起動しなくなった後で、既知の安定したカーネルに戻す方法を教えてください。

簡単な説明

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

解決策

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

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

ルートボリュームにアクセスするには 2 つの方法があります。ユースケースに最適なものを選択してください。

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

Linux 用の EC2 シリアルコンソールを有効にした場合は、それを使用して Nitro ベースのインスタンスタイプをトラブルシュートできます。シリアルコンソールは、起動の問題、ネットワーク設定、SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、稼働中のネットワーク接続を必要とせずにインスタンスに接続できます。シリアルコンソールには、Amazon EC2 コンソール、または AWS コマンドラインインターフェイス (AWS CLI) からアクセスできます。

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

インスタンスにアクセスできず、シリアルコンソールへのアクセスを設定していない場合は、次のセクションの指示に従ってください。

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

一時的なレスキューインスタンスを作成して、そのレスキューインスタンスに Amazon Elastic Block Store (Amazon EBS) ボリュームを再マウントします。レスキューインスタンスから、以前のカーネルを使用するように GNU GRUB を設定します。

重要: インスタンスストアでバックアップされるインスタンスでは、この手順を実行しないでください。復旧手順ではインスタンスの停止と起動が必要となり、そのインスタンス上のデータが失われるためです。詳細については、「インスタンスのルートデバイスタイプを判別する」を参照してください。

1. ルートボリュームの Amazon EBS スナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。
2. Amazon EC2 コンソールを開きます。
   注: 正しいリージョンに設定されていることを確認してください。
3. ナビゲーションペインから [インスタンス] を選択し、障害が発生したインスタンスを選択します。
4. [インスタンスの状態] を選択し、[インスタンスの停止]を選択したら、[停止] を選択します。
5. [ストレージ] タブの [ブロックデバイス] で、/dev/sda1 または /dev/xvda の [ボリューム ID] を選択します。
   注: ルートデバイスは AMI によって異なりますが、/dev/xvda または /dev/sda1 はルートデバイス用に予約されています。たとえば、Amazon Linux 1、Amazon Linux 2、Amazon Linux 2023 では /dev/xvda を使用します。Ubuntu 14、16、18、CentOS 7、RHEL 7.5 など、その他のディストリビューションは、/dev/sda1 を使用します。
6. [アクション]、[ボリュームのデタッチ]、[デタッチする] の順に選択します。
   注: 後の手順で EBS ボリュームを識別しやすくするために、デタッチする前にボリュームにタグを付けてください。
7. スナップショットと同じアベイラビリティーゾーンで、レスキュー EC2 インスタンスを起動します。
   注: 製品コードによっては、同じ OS の種類の EC2 インスタンスを起動する必要がある場合があります。例えば、障害が発生した EC2 インスタンスが有料の RHEL AMI である場合は、同じ製品コードを使用して AMI を起動する必要があります。詳細については、「インスタンスの製品コードの取得」を参照してください。
8. レスキューインスタンスが起動したら、ナビゲーションペインから [ボリューム] を選択します。次に、障害が発生したインスタンスのデタッチされたルートボリュームを選択します。
9. ** [アクション]、[ボリュームのアタッチ]** の順に選択します。
10. レスキューインスタンスの ID (id-#####) を選択し、未使用のデバイスを設定します。この例では、/dev/sdf です。
11. SSH を使用してレスキューインスタンスに接続します。
12. 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 ブロックデバイスとして発行します。Nitro ベースのインスタンスで lsblk コマンドによって生成される出力では、ディスク名が nvme[0-26]n1 と表示されます。 詳細については、「Amazon EBS と NVMe」を参照してください。 Nitro ベースのインスタンスでの lsblk コマンド出力の例を次に示します。

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 /

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

sudo -i

14. マウント済みのボリュームのルートパーティションを /mnt にマウントします。次の例においては、/dev/xvdf1 または /dev/nvme1n1p1 がマウント済みのボリュームのルートパーティションとなります。詳細については、「Amazon EBS ボリュームを使用できるようにする」を参照してください。/dev/xvdf1 は、ボリュームの正しいルートパーティションに置き換えます。

mount -o nouuid /dev/xvdf1 /mnt

注: 設定に /mnt が存在しない場合は、マウントディレクトリを作成します。次に、マウントされたボリュームのルートパーティションを新しいディレクトリにマウントします。

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

次に、マウントディレクトリを介して、障害が発生したインスタンスのデータへアクセスします。 レスキューインスタンスの /dev、/run、/proc、/sys を、新しくマウントしたボリュームと同じパスにマウントします。

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

マウントディレクトリに変更するために、chroot 関数を呼び出します。

注: 別の /boot パーティションがある場合は、次のコマンドを実行する前に、それを /mnt/boot にマウントします。

chroot /mnt

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

現在壊れているカーネルはリストの位置 0 (ゼロ) にあります。直近の安定したカーネルは位置 1 にあります。壊れたカーネルを安定したカーネルに置き換えるには、お使いのディストリビューションに応じて、次のいずれかの手順を実行してください。

GRUB1 (レガシー GRUB) (Red Hat 6 および Amazon Linux 1)

sed コマンドを使用して、/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 コマンドを実行します。

   update-grub

3. grub-set-default コマンドを実行して、次回の再起動時に安定したカーネルがロードされるようにします。次の例では、grub-set-default は位置 0 で、1 に設定されています。

   grub-set-default 1

GRUB2 (RHEL 7、Amazon Linux 2)

次の手順を実行します。

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

3. 次回の再起動時に安定したカーネルが読み込まれるようにするには、grub2-set-default コマンドを実行します。次の例では、grub2-set-default は位置 0 で、1 に設定されています。

   grub2-set-default 1

GRUB2 (RHEL 8、CentOS 8、Amazon Linux 2023)

GRUB2 では、以前の grub.cfg 形式ではなく、/boot/loader 内の blscfg ファイルおよび、/boot/loader のエントリをブート設定に使用します。blscfg ファイルを管理し、/boot/loader/entries/ から情報を取得するには、grubby ツールを使用するのがベストプラクティスです。blscfg ファイルが見つからないか破損している場合、grubby に結果が表示されません。機能を回復するには、これらのファイルを再生成する必要があります。カーネルのインデックスは、/boot/loader/entries にある.conf ファイルとカーネルのバージョンによって異なります。インデックスを作成すると、インデックスの最も低い最新のカーネルが保持されます。詳細については、「GRUB2 BLS 設定ファイルの問題が原因で起動に失敗した Red Hat 8 または CentOS 8 インスタンスを復旧する方法を教えてください」を参照してください。

次の手順を実行します。

1. grubby --default-kernel コマンドを実行して、現在のデフォルトカーネルを確認します。

   grubby --default-kernel

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

   grubby --info=ALL

   --info=ALL コマンドの出力例を次に示します。

   root@ip-172-31-29-221 /]# grubby --info=ALL
   index=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 コマンドを実行します。

   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 コマンドを実行します。

   grubby --default-kernel

   EC2 シリアルコンソールからインスタンスにアクセスすると、安定したカーネルが読み込まれ、インスタンスを再起動できるようになります。レスキューインスタンスを使用する場合は、次のセクションの手順を実行してください。

ボリュームをアンマウントし、ルートボリュームをレスキューインスタンスからデタッチしてから、障害が発生したインスタンスにボリュームをアタッチする

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

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

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

2. Amazon EC2 コンソールから、[インスタンス] を選択します。 次に、レスキューインスタンスを選択します。

3. [インスタンスの状態]、[インスタンスの停止] を順に選択してから、[停止する] を選択します。

4. ルートボリュームの障害のあるインスタンスをレスキューインスタンスからデタッチします。

5. デタッチしたルートボリュームを、障害のあるインスタンスにルートボリューム (/dev/sda1) としてアタッチします。次に、インスタンスを起動します。

注: ルートデバイスは AMI ごとに異なります。/dev/xvda や /dev/sda1 という名前はルートデバイス用に予約されています。たとえば、Amazon Linux 1、Amazon Linux 2、Amazon Linux 2023 では /dev/xvda を使用します。Ubuntu 14、16、18、CentOS 7、RHEL 7.5 など、その他のディストリビューションは、/dev/sda1 を使用します。

これで安定したカーネルが読み込まれ、インスタンスが再起動します。