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

Brève description

Le chargeur GRUB2 dans RHEL 8 et Centos 8 utilise 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 cet emplacement, alors grubby n'affiche aucun résultat. Pour restaurer la fonctionnalité, vous devez de nouveau générer les fichiers. Pour générer de nouveau 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, générez de nouveau le fichier blscfg pour tous les noyaux installés.
Important : cette procédure de restauration ne doit pas être effectuée sur une instance basée sur le stockage d'instance. Elle nécessite l'arrêt et le démarrage de votre instance, ce qui signifie que vous perdez toutes les données qui y résident. Pour plus d'informations, reportez-vous à Déterminer le type de périphérique racine de l’instance.

Résolution

Associer le volume racine à une instance EC2 de secours

1. Créez un instantané EBS du volume racine. Pour plus d'informations, reportez-vous à Créer des instantanés Amazon EBS.
2. Ouvrez la console Amazon EC2.
   Remarque : vérifiez que vous êtes bien dans la bonne région. La région est indiquée dans la console Amazon EC2 à droite des informations de votre compte. Vous pouvez choisir une autre région dans le menu déroulant, si nécessaire.
3. Dans le volet de navigation, choisissez Instances, puis sélectionnez l'instance dégradée.
4. Choisissez Actions, sélectionnez État de l'instance, puis Arrêter.
5. Dans l'onglet Description, sous Périphérique racine, choisissez /dev/sda1, puis l'ID EBS.
6. Choisissez Actions, Dissocier un volume, puis sélectionnez Oui, dissocier. Notez la zone de disponibilité.
7. Lancez une instance EC2 de secours similaire dans la même zone de disponibilité. La nouvelle instance devient alors votre instance de secours.
8. Une fois l'instance de secours lancée, dans le volet de navigation, choisissez Volumes, puis sélectionnez le volume racine dissocié de l'instance dégradée.
9. Choisissez Actions, puis Associer un volume.
10. Choisissez l'ID de l'instance de secours (id-xxxxx), puis définissez un périphérique inutilisé. Dans cet exemple, le périphérique inutilisé est /dev/sdf.

Monter le volume de l'instance dégradée

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 /]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

   Remarque : les instances basées sur Nitro exposent 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, reportez-vous à Amazon EBS et NVMe sur les instances Linux.

3. Créez un répertoire de montage, puis montez la partition racine du volume monté dans ce nouveau répertoire. Dans l'exemple de l'étape 2, /dev/xvdf2 est la partition racine du volume monté. Pour plus d'informations, reportez-vous à Rendre un volume Amazon EBS disponible pour une utilisation sous Linux :

   sudo mkdir /mountsudo mount /dev/xvdf2 /mount

4. Montez /dev, /run, /proc et /sys de l'instance de secours sur les mêmes chemins que le volume nouvellement monté :

   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. Démarrez l'environnement chroot :

   sudo chroot /mount

Générer de nouveau les fichiers blscfg

1. Exécutez la commande rpm. Remarque concernant les noyaux disponibles dans votre instance :

   [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. pour recréer le fichier blscfg, exécutez la commande kernel-install :
   Remarque : le package d'installation systemd-udev rpm fournit le binaire kernel-install :

   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

   Remplacez 4.18.0-147.3.1.el8_0.x86_64 par le numéro de version de votre noyau. Le fichier blscfg du noyau désigné est de nouveau généré sous /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. Si nécessaire, répétez l'étape 2 pour les autres noyaux installés sur l'instance. Le dernier noyau que vous avez défini devient le noyau par défaut.

4. Pour afficher le noyau par défaut actuel, exécutez la commande grubby --default kernel :

   sudo grubby --default-kernel

5. Quittez chroot et démontez les montages /dev, /run, /proc et /sys :

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

6. 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 ?