如何恢复由于 GRUB2 BLS 配置文件问题无法启动的 RHEL 8 或 CentOS 8 Amazon EC2 实例？

简短描述

RHEL 8 和 Centos 8 中的 GRUB2 使用 blscfg 文件和 /boot/loader 中的条目进行启动配置，而不是之前的 grub.cfg 格式。最佳做法是使用 grubby 工具管理 blscfg 文件，并从 /boot/loader/entries/ 检索信息。

如果 blscfg 文件损坏或在 /boot/loader/entries/ 处缺失，则 grubby 不会显示任何结果。您必须重新生成文件才能恢复功能。要重新生成 blscfg，请创建一个临时救援实例，然后将您的 Amazon Elastic Block Store (Amazon EBS) 卷重新挂载到该救援实例上。在该救援实例中，为所有已安装的内核重新生成 blscfg。

**重要事项：**请勿在实例存储支持的实例上执行此过程。此恢复过程要求您停止并启动实例。当停止并启动实例时，该实例上的所有数据都将丢失。有关详细信息，请参阅 Amazon EC2 实例的根卷。

解决方法

将根卷连接到 EC2 救援实例

完成以下步骤：

1. 创建根卷的 Amazon EBS 快照。
2. 打开 Amazon EC2 控制台。
   **注意：**确保您位于正确的 AWS 区域。
3. 在导航窗格中，选择 Instances（实例），然后选择受影响的实例。
4. 选择 Actions（操作），然后选择 Instance State（实例状态）。
5. 选择 Stop（停止）。
6. 在 Description（描述）选项卡的 Root device（根设备）下，选择 /dev/sda1，然后选择 EBS ID。
7. 选择 Actions（操作），然后选择 Detach Volume（分离卷）。
8. 选择 Yes（是），然后选择 Detach（分离）。记下 Availability Zone（可用区）值。
9. 在同一可用区中启动 EC2 实例以用作救援实例。
10. 在导航窗格中，选择 Volumes（卷），然后选择受影响实例的分离根卷。
11. 选择 Actions（操作），然后选择 Attach volume（连接卷）。
12. 选择救援实例 ID，然后在 Device name（设备名称）中选择一个未使用的设备，例如 /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 块设备显示。lsblk 命令在基于 Nitro 的实例上生成的输出会将磁盘名称显示为 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 实例无法成功重启时，我如何恢复到已知的稳定内核？