Comment puis-je récupérer mon instance Red Hat 8 ou CentOS 8 qui ne parvient pas à démarrer en raison de problèmes avec le fichier de configuration GRUB2 BLS ?

Date de la dernière mise à jour : 03/02/2020

J'exécute une instance Amazon Elastic Compute Cloud (Amazon EC2) Red Hat 8 ou CentOS 8. Comment puis-je récupérer le fichier de configuration BLS (blscfg) trouvé sous /boot/loader/entries/ s'il est corrompu ou supprimé ?

Brève description

GRUB2 dans RHEL 8 et Centos 8 utilise des fichiers blscfg et des entrées dans /boot/loader pour la configuration de démarrage, contrairement au format grub.cfg précédent. L'outil grubby est recommandé pour gérer les fichiers blscfg et récupérer des informations à partir de /boot/loader/entries/. Si les fichiers blscfg sont manquants dans cet emplacement ou corrompus, l’outil grubby n'affiche aucun résultat. Vous devez régénérer les fichiers pour récupérer les fonctionnalités. 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 l'instance de secours. À partir de l'instance de secours, régénérez le fichier blscfg pour tous les noyaux installés.

Important : n'effectuez pas cette procédure sur une instance basée sur le stockage d'instance. Cette procédure de récupération nécessite un arrêt et un démarrage de votre instance, ce qui signifie que toutes les données sur l'instance seront perdues. Pour plus d'informations, consultez la section Définition du type de périphérique racine de votre instance.

Solution

Attachez le volume racine à une instance EC2 de secours

1.    Créez un instantané EBS du volume racine. Pour plus d'informations, consultez la section Création d'un instantané Amazon EBS.

2.    Ouvrez la console Amazon EC2.

Remarque : assurez-vous que vous êtes dans la bonne région AWS. La région s'affiche dans la console Amazon EC2 à droite de vos informations de compte. Vous pouvez choisir une autre région dans le menu déroulant, si nécessaire.

3.    Sélectionnez Instances (Instances) dans le volet de navigation, puis choisissez l'instance affectée.

4.    Choisissez Actions, sélectionnez Instance State (État de l'instance), puis Stop (Arrêter).

5.    Dans l'onglet Description, sous Root Device (Périphérique racine), sélectionnez /dev/sda1, puis l'ID EBS.

6.    Sélectionnez Actions, choisissez Detach Volume (Détacher un volume), puis Yes, Detach (Oui, détacher). Notez la zone de disponibilité.

7.    Lancez une instance EC2 de secours similaire dans la même zone de disponibilité. Cette instance devient votre instance de secours.

8.    Une fois que l'instance de secours est lancée, sélectionnez Volumes dans le volet de navigation, puis sélectionnez le volume racine détaché de l'instance affectée.

9.    Sélectionnez Actions, puis choisissez Attacher un volume (Attach Volume).

10.    Sélectionnez l'ID de l'instance de secours (id-xxxxx), puis définissez un périphérique libre. Dans cet exemple, le périphérique libre est /dev/sdf.

Montez le volume de l'instance affectée

1.    Utilisez SSH pour vous connecter à l'instance de secours.

2.    Exécutez la commande lsblk pour voir vos disques disponibles.

[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 

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 indique les noms de disques sous la forme nvme[0-26]n1. Pour plus d'informations, consultez la section 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 précédent, /dev/xvdf2 est la partition racine du volume monté. Pour plus d'informations, consultez la section Mise à disposition d'un volume Amazon EBS pour une utilisation sur Linux.

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

4.    Montez les partitions /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/dev
sudo 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

Régénération des fichiers blscfg

1.    Exécutez la commande rpm. Notez les noyaux disponibles dans votre instance.

[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.    Pour recréer le fichier blscfg exécutez la commande kernel-install.

Remarque : le fichier binaire kernel-install est fourni avec le package d'installation 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 

Remplacez 4.18.0-147.3.1.el8_0.x86_64 par le numéro de version de votre noyau.

Le fichier blscfg pour le noyau désigné est ré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 est défini sur le noyau par défaut.

4.    Exécutez la commande grubby --default kernel pour afficher le noyau par défaut actuel.

sudo grubby --default-kernel

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

Exit
sudo 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 approprié. Le périphérique démarre désormais avec le noyau par défaut.


Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d’aide ?