Comment puis-je récupérer mon instance Amazon EC2 RHEL 8 ou CentOS 8 qui ne démarre pas en raison de problèmes liés au fichier de configuration GRUB2 BLS ?

Brève description

GRUB2 dans RHEL 8 et Centos 8 utilisent des fichiers blscfg et des entrées dans /boot/loader pour la configuration de démarrage à la place de l'ancien format grub.cfg. Il est recommandé d'utiliser l'outil grubby pour gérer les fichiers blscfg et récupérer des informations dans /boot/loader/entries/.

Si les fichiers blscfg sont endommagés ou absents de /boot/loader/entries/, grubby n'affiche aucun résultat. Vous devez régénérer les fichiers pour restaurer la fonctionnalité. Pour régénérer le fichier blscfg, créez une instance de secours temporaire, puis remontez votre volume Amazon Elastic Block Store (Amazon EBS) sur celle-ci. À partir de l'instance de secours, régénérez le fichier blscfg pour tous les noyaux installés.

Important : N'exécutez pas la procédure sur une instance qui est soutenue par un stockage d'instance. Ce processus de restauration nécessite que vous arrêtiez puis redémarriez votre instance. Lorsque vous arrêtez et démarrez votre instance, vous perdez toutes les données qu'elle contient. Pour plus d'informations, consultez la section Volumes racine pour vos instances Amazon EC2.

Résolution

Associer le volume racine à une instance EC2 de secours

Procédez comme suit :

1. Créez un instantané Amazon EBS du volume racine.
2. Ouvrez la console Amazon EC2.
   Remarque : Vérifiez que vous vous trouvez dans la bonne région AWS.
3. Dans le volet de navigation, sélectionnez Instances, puis choisissez l’instance concernée.
4. Sélectionnez Actions, puis État de l’instance.
5. Sélectionnez Arrêter.
6. Dans l'onglet Description, sous Périphérique racine, choisissez /dev/sda1, puis l'ID EBS.
7. Sélectionnez Actions, puis Détacher le volume.
8. Sélectionnez Oui, puis Détacher. Notez la valeur de Zone de disponibilité.
9. Lancez une instance EC2 dans la même zone de disponibilité à utiliser comme instance de secours.
10. Dans le volet de navigation, sélectionnez Volumes, puis le volume racine détaché de l'instance concernée.
11. Sélectionnez Actions, puis Attacher un volume.
12. Choisissez l'ID de l'instance de secours, puis dans Nom du périphérique, sélectionnez un périphérique inutilisé, par exemple /dev/sdf.

Monter le volume de l'instance concernée

Procédez comme suit :

1. Connectez-vous à l’instance de secours avec le protocole SSH.

2. Exécutez la commande lsblk pour afficher les unités de disque disponibles :

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

   Exemple de résultat :

   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

   Remarque : Les instances basées sur Nitro affichent les volumes EBS en tant que périphériques de stockage en mode bloc NVMe. La sortie générée par la commande lsblk sur les instances basées sur Nitro affiche les noms de disque sous la forme nvme[0-26]n1. Pour en savoir plus, consultez la section Volumes Amazon EBS et NVMe.

3. Exécutez les commandes suivantes pour créer un répertoire de montage et monter la partition racine du volume monté dans le nouveau répertoire :

   [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

   Remarque : Remplacez /dev/xvdf2 par la partition racine de votre volume monté. Pour plus d'informations, consultez la section Instances Linux de la section Rendre un volume Amazon EBS disponible pour utilisation.

4. Exécutez la commande suivante pour monter /dev, /run, /proc et /sys de l'instance de secours sur les mêmes chemins que le volume nouvellement monté :

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

5. Exécutez la commande suivante pour démarrer l’environnement chroot :

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

Régénérer les fichiers blscfg

Procédez comme suit :

1. Exécutez la commande rpm pour trouver des informations sur les noyaux disponibles dans votre instance :

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

   Exemple de résultat :

   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

   Notez les noyaux disponibles dans la sortie.

2. Exécutez la commande kernel-install pour chaque noyau installé dans l'instance afin de recréer le fichier 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

   Remarque : Remplacez 4.18.0-147.3.1.el8_0.x86_64 par le numéro de version de votre noyau. Le package d'installation systemd-udev rpm fournit le binaire kernel-install.
   Le fichier blscfg du noyau désigné est régénéré sous /boot/loader/entries/.
   Exemple :

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

3. Le dernier noyau par défaut que vous avez défini avec kernell-install devient le noyau par défaut. Pour afficher le noyau par défaut actuel, exécutez la commande --default kernel :

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

4. Exécutez la commande suivante pour quitter chroot, et démontez les montages /dev, /run, /proc et /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. Remontez le périphérique sur l'instance d'origine avec le mappage de périphérique de stockage en mode bloc. Le périphérique démarre désormais avec le noyau par défaut.

Informations connexes

Comment puis-je revenir à un noyau stable connu après qu'une mise à jour a empêché mon instance Amazon EC2 de redémarrer correctement ?