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

簡単な説明

RHEL 8 および Centos 8 の GRUB2 は、以前の grub.cfg 形式ではなく、blscfg ファイルと /boot/loader のエントリをブート設定に使用します。grubby ツールは、blscfg ファイルの管理と /boot/loader/entries/ からの情報の取得に推奨されます。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.    [アクション]、[Detach Volume]、[Yes, Detach] の順に選択します。アベイラビリティーゾーンをメモしておきます。

7.    類似のレスキュー EC2 インスタンスを同じアベイラビリティーゾーンで起動します。このインスタンスはレスキューインスタンスになります。

8.    レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] を選択してから、障害が発生したインスタンスのデタッチ済みルートボリュームを選択します。

9.    [アクション] を選択し、[Attach Volume] を選択します。

10.    レスキューインスタンスの ID (id-xxxxx) を選択してから、未使用のデバイスを設定します。この例では、未使用のデバイスは /dev/sdf です。

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

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

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

[ec2-user@ip-10-10-1-111 /]s lsblk
NAME    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.    マウントディレクトリを作成し、マウントされたボリュームのルートパーティションをこの新しいディレクトリにマウントします。前の例では、/dev/xvdf2 はマウントされたボリュームのルートパーティションです。詳細については、「Linux で Amazon EBS ボリュームを使用できるようにする」を参照してください。

sudo mkdir /mount
sudo mount /dev/xvdf2 /mount

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

sudo mount -o bind /dev /mount/dev
sudo 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 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.    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.    grubby コマンド --default kernel を実行して、現在のデフォルトカーネルを表示します。

sudo grubby --default-kernel

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

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

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

---

関連情報

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