Comment rétablir un noyau stable connu après qu'une mise à jour empêche mon instance Amazon EC2 de redémarrer correctement ?

Dernière mise à jour : 2021-05-07

Comment rétablir un noyau stable après qu'une mise à jour empêche mon instance Amazon Elastic Compute Cloud (Amazon EC2) de redémarrer correctement ?

Brève description

Si vous avez effectué une mise à jour le noyau de votre instance Linux EC2, mais que le noyau est à présent corrompu, l'instance ne peut pas redémarrer. Vous ne pourrez pas utiliser SSH pour vous connecter à l'instance affectée.

Pour revenir aux versions précédentes, procédez comme suit :

1.    Accédez au volume racine de l'instance.

2.    Mettez à jour le noyau par défaut dans le programme d'amorçage GRUB.

Solution

Accéder au volume racine de l'instance

Il existe deux méthodes pour accéder au volume racine :

Méthode 1 : utilisation d'EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l'utiliser pour résoudre les problèmes liés aux types d'instance Nitro pris en charge. EC2 Serial Console vous aide à résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. EC2 Serial Console se connecte à votre instance sans qu'aucune connexion réseau ne soit nécessaire. Vous pouvez accéder à EC2 Serial Console à l'aide de la console Amazon EC2 ou de l'interface de ligne de commande AWS (AWS CLI).

Avant d'utiliser EC2 Serial Console, accordez-lui l'accès au niveau du compte. Créez ensuite des stratégies AWS Identity and Access Management (IAM) accordant l'accès à vos utilisateurs IAM. En outre, chaque instance qui utilise la console série doit inclure au moins un utilisateur avec mot de passe. Si votre instance n'est pas accessible et que vous n'avez pas configuré l'accès à EC2 Serial Console, suivez les instructions de la méthode 2. Pour plus d'informations sur la configuration d'EC2 Serial Console pour Linux, consultez la section Configurer l'accès à EC2 Serial Console.

Remarque : en cas d'erreurs lors de l'exécution des commandes depuis AWS CLI, assurez-vous d'utiliser la version la plus récente.

Méthode 2 : utiliser une instance de secours

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, vous pouvez configurer votre GRUB pour prendre le noyau précédent pour le démarrage.

Important : n'effectuez pas cette procédure sur une instance basée sur le stockage d'instance. Comme la procédure de récupération nécessite l'arrêt et le démarrage de votre instance, toutes les données qui se trouvent sur cette instance sont perdues. Pour plus d'informations, consultez la section Déterminer le type de périphérique racine de votre instance.

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

2.    Ouvrez la console Amazon EC2.

Remarque : assurez-vous que vous êtes dans la bonne région.

3.    Sélectionnez Instances dans le panneau de navigation, puis sélectionnez l'instance affectée.

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

5.    Dans l'onglet Storage (Stockage), sous Block devices (Périphériques de stockage en mode bloc), sélectionnez le Volume ID (ID de volume) pour /dev/sda1.

Remarque : le périphérique racine se distingue par l'AMI, mais /dev/xvda ou /dev/sda1 sont toujours réservées au périphérique racine. Par exemple, Amazon Linux 1 et 2 utilisent /dev/xvda. D'autres distributions, telles que Ubuntu 14, 16, 18, CentOS 7 et RHEL 7.5, utilisent /dev/sda1.

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

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

Remarque : en fonction du code produit, il est possible que vous soyez obligé de lancer une instance EC2 du même type de système d'exploitation. Par exemple, si l'instance EC2 affectée est une AMI RHEL payante, vous devez lancer une AMI avec le même code produit. Pour plus d'informations, consultez la section Obtenir le code produit de votre instance.

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

9.    Choisissez Actions, Attach Volume (Attacher un volume).

10.    Choisissez l'ID de l'instance de secours ( id-xxxxx), puis définissez un périphérique inutilisé. Dans cet exemple, /dev/xvdb.

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

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

lsblk

Voici un exemple de résultat :

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0     0   15G  0 disk
└─xvda1 202:1     0   15G  0 part /
xvdb    202:0     0   15G  0 disk
    └─xvdb1 202:1 0   15G  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.

13.    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/xvdb1 est la partition racine du volume monté. Pour plus d'informations, consultez la section Rendre un volume Amazon EBS disponible à l'utilisation sur le Linux.

sudo mkdir /mount
sudo mount /dev/xvdb1 /mount

Vous pouvez désormais accéder aux données de l'instance affectée via le répertoire de montage.

14.    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

Mettez à jour le noyau par défaut dans le programme d'amorçage GRUB

Appelez la fonction chroot pour apporter des modifications dans le répertoire de montage :

sudo chroot /mount

Le noyau corrompu actuel occupe la position 0 (zéro) dans la liste. Le dernier noyau stable occupe la position 1. Pour remplacer le noyau corrompu par le noyau stable, utilisez l'une des procédures suivantes, en fonction de votre distribution :

GRUB1 (GRUB existant) pour Red Hat 6 et Amazon Linux

GRUB2 pour Ubuntu 14 LTS et 16.04

GRUB2 pour RHEL 7.5 et Amazon Linux 2

GRUB2 pour RHEL 8 et CentOS 8

GRUB1 (GRUB existant) pour Red Hat 6 et Amazon Linux 1

Utilisez la commande sed pour remplacer le noyau corrompu par le noyau stable dans le fichier /boot/grub/grub.conf :

sudo sed -i '/^default/ s/0/1/' /boot/grub/grub.conf

GRUB2 pour Ubuntu 14 LTS et 16.04

1.    Remplacez l'entrée corrompue GRUB_DEFAULT=0 du menu par défaut par la valeur stable GRUB_DEFAULT=saved dans le fichier /etc/default/grub :

sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2.    Exécutez la commande update-grub pour permettre au GRUB de reconnaître le changement :

sudo update-grub

3.    Exécutez la commande grub-set-default pour permettre le chargement du noyau stable au prochain redémarrage. Dans cet exemple, la commande grub-set-default est définie sur 1 en position 0 :

sudo grub-set-default 1

GRUB2 pour RHEL 7.5 et Amazon Linux 2

1.    Remplacez l'entrée corrompue GRUB_DEFAULT=0 du menu par défaut par la valeur stable GRUB_DEFAULT=saved dans le fichier /etc/default/grub :

sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2.    Mettez à jour GRUB, afin de régénérer le fichier /boot/grub2/grub.cfg :

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

3.    Exécutez la commande grub2-set-default pour permettre le chargement du noyau stable au prochain redémarrage. Dans cet exemple, la commande grub2-set-default est définie sur 1 en position 0 :

sudo grub2-set-default 1

GRUB2 pour RHEL 8 et CentOS 8

GRUB2 dans RHEL 8 et Centos 8 utilise des fichiers et des entrées blscfg dans /boot/loader pour la configuration de démarrage, au lieu du format grub.cfg précédent. Il est recommandé d'utiliser l'outil grubby 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. Par conséquent, l'indexation des noyaux dépend des fichiers .conf situés sous /boot/loader/entries et des versions du noyau. L'indexation est configurée pour conserver le dernier noyau avec l'index le plus bas. Pour plus d'informations sur comment régénérer les fichiers de configuration BLS, consultez Comment 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 BLS Grub2 ?

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

grubby --default-kernel

2.    Exécutez la commande grubby --info=ALL pour afficher tous les noyaux disponibles et leurs index :

grubby --info=ALL

Voici un exemple de sortie de la commande --info=ALL :

[root@ip-10-10-1-111 ~]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-4.18.0-147.3.1.el8_1.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto $tuned_params"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/boot/initramfs-4.18.0-147.3.1.el8_1.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-147.3.1.el8_1.x86_64) 8.1 (Ootpa)"
id="2bb67fbca2394ed494dc348993fb9b94-4.18.0-147.3.1.el8_1.x86_64"
index=1
kernel="/vmlinuz-0-rescue-2bb67fbca2394ed494dc348993fb9b94"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/initramfs-0-rescue-2bb67fbca2394ed494dc348993fb9b94.img"
title="Red Hat Enterprise Linux (0-rescue-2bb67fbca2394ed494dc348993fb9b94) 8.1 (Ootpa)"
id="2bb67fbca2394ed494dc348993fb9b94-0-rescue"
index=2
kernel="/boot/vmlinuz-4.18.0-80.4.2.el8_0.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto $tuned_params"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/boot/initramfs-4.18.0-80.4.2.el8_0.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-80.4.2.el8_0.x86_64) 8.0 (Ootpa)"
id="c74bc11fb3d6436bb2716196dd0e7a47-4.18.0-80.4.2.el8_0.x86_64"

Notez le chemin du noyau que vous souhaitez définir comme valeur par défaut pour votre instance. Dans l'exemple précédent, le chemin du noyau à l'index 2 est /boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64.

3.    Exécutez la commande grubby --set-default pour modifier le noyau par défaut de l'instance :

grubby --set-default=/boot/vmlinuz-0-rescue-4.18.0-80.4.2.el8_1.x86_64

Remarque : remplacez 4.18.0-80.4.2.el8_1.x86_64 par le numéro de version de votre noyau.

4.    Exécutez la commande grubby --default-kernel pour vérifier que la commande précédente a fonctionné :

grubby --default-kernel

Si vous accédez à l'instance à l'aide d'EC2 Serial Console, le noyau stable se charge désormais et vous pouvez redémarrer l'instance.

Si vous utilisez une instance de secours, suivez les étapes décrites dans la section suivante.

Démontez les volumes, détachez le volume racine de l'instance de secours, puis attachez-le à l'instance affectée

Remarque : suivez les étapes suivantes si vous avez utilisé la Méthode 2 : utiliser une instance de secours pour accéder au volume racine.

1.    Quittez 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

2.    Dans la console Amazon EC2, choisissez Instances, puis choisissez l'instance de secours.

3.    Choisissez Instance State (État de l'instance), Stop instance (Arrêter l'instance), puis sélectionnez Yes, Stop (Oui, arrêter).

4.    Détachez le volume racine id-xxxxx (volume de l'instance affectée) de l'instance de secours.

5.    Attachez le volume racine que vous avez détaché à l'étape 4 à l'instance affectée en tant que volume racine (/dev/sda1), puis démarrez l'instance.

Remarque : le périphérique racine diffère selon l'AMI. Les noms /dev/xvda ou /dev/sda1 sont toujours réservés au périphérique racine. Par exemple, Amazon Linux 1 et 2 utilisent /dev/xvda. D'autres distributions, telles que Ubuntu 14, 16, 18, CentOS 7 et RHEL 7.5, utilisent /dev/sda1.

Le noyau stable se charge désormais et votre instance redémarre.


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


Besoin d'aide pour une question technique ou de facturation ?