GRUB2 BLS 設定ファイルの問題が原因で起動できない RHEL 8 または CentOS 8 の Amazon EC2 インスタンスを復旧する方法を教えてください。

簡単な説明

RHEL 8 と Centos 8 の GRUB2 は、ブート設定には以前の grub.cfg 形式ではなく blscfg ファイルと /boot/loader 内のエントリを使用します。blscfg ファイルを管理し、/boot/loader/entries/ から情報を取得するには、grubby ツールを使用するのがベストプラクティスです。

blscfg ファイルが破損しているか、/boot/loader/entries/ にない場合、grubby には結果が表示されません。機能を回復するには、ファイルを再生成する必要があります。blscfg を再生成するには、一時的なレスキューインスタンスを作成し、Amazon Elastic Block Store (Amazon EBS) ボリュームをレスキューインスタンスに再マウントします。レスキューインスタンスから、インストールされているカーネル用に blscfg を再生成します。

重要: インスタンスストアを基盤とするインスタンスには、この手順を実行しないでください。この復旧プロセスは、インスタンスの停止と起動を要します。インスタンスを停止して起動すると、インスタンス上のすべてのデータが失われます。詳細については、「Amazon EC2 インスタンスのルートボリューム」を参照してください。

解決策

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

次の手順を実行します。

1. ルートボリュームの Amazon EBS スナップショットを作成します。
2. Amazon EC2 コンソールを開きます。
   注: 正しい AWS リージョンを使用していることを確認してください。
3. ナビゲーションペインで [インスタンス] を選択し、影響を受けているインスタンスを選択します。
4. [アクション] を選択し、**[インスタンスの状態]**を選択します。
5. [停止] を選択します。
6. [説明] タブの [ルートデバイス] で /dev/sda1 を選択してから、[EBS ID] を選択します。
7. [アクション] を選択し、[ボリュームのデタッチ] を選択します。
8. [Yes] を選択し、[デタッチ] を選択します。[アベイラビリティーゾーン] の値を書き留めます。
9. 同じアベイラビリティーゾーンで EC2 インスタンスを起動し、レスキューインスタンスとして使用します。
10. ナビゲーションペインで [ボリューム] を選択し、影響を受けているインスタンスのデタッチされたルートボリュームを選択します。
11. [アクション] を選択し、[ボリュームのアタッチ] を選択します。
12. レスキューインスタンス ID を選択し、[デバイス名] で使われていないデバイス (/dev/sdf など) を選択します。

影響を受けているインスタンスのボリュームをマウントする

次の手順を実行します。

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

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

   [ec2-user@ip-10-10-1-111 ~]$ lsblk

   出力例:

   NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTxvda    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 と表示されます。詳細については、「Amazon EBS ボリュームと NVMe」を参照してください。

3. 次のコマンドを実行してマウントディレクトリを作成し、マウントされたボリュームのルートパーティションを新しいディレクトリにマウントします。

   [ec2-user@ip-10-10-1-111 ~]$ sudo -i
   [root@ip-10-10-1-111 ~]# mkdir /mount
   [root@ip-10-10-1-111 ~]#  mount /dev/xvdf2 /mount

   注: /dev/xvdf2 は、マウントされたボリュームのルートパーティションに置き換えます。詳細については、「Amazon EBS ボリュームを使用できるようにする」の「Linux インスタンス」セクションを参照してください。

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

   [root@ip-10-10-1-111 ~]# for i in dev proc sys run; do mount -o bind /$i /mount/$i; done

5. 次のコマンドを実行し、** chroot** 環境を起動します。

   [root@ip-10-10-1-111 ~]# chroot /mount

blscfg ファイルを再生成する

次の手順を実行します。

1. rpm コマンドを実行し、インスタンスで使用可能なカーネルに関する情報を確認します。

   [root@ip-10-10-1-111 ~]# rpm -q --last kernel

   出力例:

   kernel-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. インスタンスにインストールされている各カーネルに対して kernel-install コマンドを実行して blscfg ファイルを再作成します。

   [root@ip-10-10-1-111 ~]#  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 は、実際のカーネルのバージョン番号に置き換えます。systemd-udev rpm インストールパッケージから、kernel-install バイナリを取得します。
   指定されたカーネルの 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. kernell-install で設定した最後のデフォルトカーネルがデフォルトカーネルになります。grubby コマンド --default kernel を実行し、現在のデフォルトカーネルを確認します。

   [root@ip-10-10-1-111 ~]# grubby --default-kernel

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

   [root@ip-10-10-1-111 ~]# exit
   [root@ip-10-10-1-111 ~]# umount /mount/{dev,proc,run,sys,}
   [root@ip-10-10-1-111 ~]# umount /mount

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

関連情報

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