GRUB2 BLS 設定ファイルの問題が原因で起動に失敗した Red Hat 8 または CentOS 8 インスタンスを復旧する方法を教えてください。

簡単な説明

RHEL 8 と Centos 8 の GRUB2 は、以前とは違って grub.cfg 形式ではなく、ブート設定に blscfg ファイルと /boot/loader 内のエントリを使用します。blscfg ファイルを管理し、/boot/loader/entries/ から情報を取得するには、grubby ツールを使用するのがベストプラクティスです。blscfg ファイルが破損しているか、この場所で見つからない場合、grubby は結果を表示しません。機能を回復するには、これらのファイルを再生成する必要があります。blscfg を再生成するには、一時的なレスキューインスタンスを作成し、Amazon Elastic Block Store (Amazon EBS) ボリュームをレスキューインスタンスに再マウントします。レスキューインスタンスから、インストールされているカーネル用に blscfg を再生成します。
重要: インスタンスストアでバックアップされるインスタンスではこの手順を実行しないでください。この復旧手順では、インスタンスの停止と起動が必要です。つまり、インスタンスのデータは失われます。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。

解決策

ルートボリュームをレスキュー EC2 インスタンスにアタッチする

1. ルートボリュームの EBS スナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。
2. Amazon EC2 コンソールを開きます。
   注: 正しいリージョンが選択されていることを確認してください。リージョンは、Amazon EC2 コンソールのアカウント情報の右側に表示されます。必要に応じて、ドロップダウンメニューから別のリージョンを選択できます。
3. ナビゲーションペインから [インスタンス] を選択し、障害が発生したインスタンスを選択します。
4. [アクション] を選択し、[インスタンスの状態] を選択して、[停止] を選択します。
5. [説明] タブの [ルートデバイス] で、[/dev/sda1] を選択し、次に EBS ID を選択します。
6. [アクション]、[ボリュームのデタッチ]、[デタッチする] の順に選択します。アベイラビリティーゾーンを書き留めます。
7. 同じアベイラビリティーゾーンで、類似のレスキュー EC2 インスタンスを起動します。このインスタンスがレスキューインスタンスになります。
8. レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] を選択してから、障害が発生したインスタンスのデタッチ済みルートボリュームを選択します。
9. [アクション] を選択し、[ボリュームのアタッチ] を選択します。
10. レスキューインスタンスの ID (id-xxxxx) を選択し、未使用のデバイスを設定します。この例では、未使用のデバイスは /dev/sdf です。

障害が発生したインスタンスのボリュームをマウントする

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

2. lsblk コマンドを実行して使用可能なディスクデバイスを表示します。

   [ec2-user@ip-10-10-1-111 /]s lsblkNAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
   xvda    202:0    0  10G  0 disk
   ├─xvda1 202:1    0   1M  0 part
   └─xvda2 202:2    0  10G  0 part /
   xvdf    202:80   0  10G  0 disk
   ├─xvdf1 202:81   0   1M  0 part
   └─xvdf2 202:82   0  10G  0 part

   注: Nitro ベースのインスタンスは EBS ボリュームを NVMe ブロックデバイスとして公開します。Nitro ベースのインスタンスで lsblk コマンドによって生成される出力では、ディスク名がnvme[0-26]n1 と表示されます。詳細については、「Linux インスタンスの Amazon EBS および NVMe」を参照してください。

3. マウントディレクトリを作成し、マウントしたボリュームのルートパーティションをこの新しいディレクトリにマウントします。ステップ 2 の例では、/dev/xvdf2 はマウントされたボリュームのルートパーティションです。詳細については、「Linux で Amazon EBS ボリュームを使用できるようにする」を参照してください。

   sudo mkdir /mountsudo mount /dev/xvdf2 /mount

4. レスキューインスタンスの /dev、/run、/proc、/sys を、新しくマウントしたボリュームと同じパスにマウントします。

   sudo mount -o bind /dev /mount/devsudo mount -o bind /run /mount/run
   sudo mount -o bind /proc /mount/proc
   sudo mount -o bind /sys /mount/sys

5. chroot 環境を起動します。

   sudo chroot /mount

blscfg ファイルを再生成する

1. rpm コマンドを実行します。インスタンスで使用可能なカーネルを書き留めます。

   [root@ip-10-10-1-111 ~]# rpm -q --last kernelkernel-4.18.0-147.3.1.el8_1.x86_64 Tue 21 Jan 2020 05:11:16 PM UTC
   kernel-4.18.0-80.4.2.el8_0.x86_64 Tue 18 Jun 2019 05:06:11 PM UTC

2. blscfg ファイルを再作成するには、kernel-install コマンドを実行します。
   注:** kernel-install バイナリ**は systemd-udev rpm インストールパッケージで提供されます。

   sudo kernel-install add 4.18.0-147.3.1.el8_1.x86_64 /lib/modules/4.18.0-147.3.1.el8_1.x86_64/vmlinuz

   4.18.0-147.3.1.el8_0.x86_64 をカーネルのバージョン番号に置き換えます。指定されたカーネルの blscfg は /boot/loader/entries/ の下に再生成されます。

   [root@ip-10-10-1-111 ~]# ls /boot/loader/entries/2bb67fbca2394ed494dc348993fb9b94-4.18.0-147.3.1.el8_1.x86_64.conf

3. 必要に応じて、インスタンスにインストールされている他のカーネルについてもステップ 2 を繰り返します。設定した最新のカーネルがデフォルトのカーネルになります。

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

   sudo grubby --default-kernel

5. chroot を終了し、/dev、/run、/proc、および /sys のマウントをアンマウントします。

   Exitsudo umount /mount/dev
   sudo umount /mount/run
   sudo umount /mount/proc
   sudo umount /mount/sys
   sudo umount /mount

6. 正しいブロックデバイスマッピングを使用して、デバイスを元のインスタンスにマウントし直します。これでデバイスはデフォルトのカーネルで起動するようになります。

関連情報

更新のせいで Amazon EC2 インスタンスが正常に再起動できなくなった後に、既知の安定したカーネルに戻すにはどうすればよいですか?