Comment rétablir un noyau stable connu après qu'une mise à jour empêche mon instance 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.

Ré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 à la console série à l'aide de la console Amazon EC2 ou d'AWS Command Line Interface (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 Stockage, sous Périphérique de stockage en mode bloc, sélectionnez l'ID de volume pour /dev/sda1 ou /dev/xvda.

Remarque : Le périphérique racine se distingue par l'AMI, mais /dev/xvda ou /dev/sda1 est toujours réservé 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é.

Remarque : Vous pouvez étiqueter le volume EBS avant de le détacher pour permettre son identification dans les étapes ultérieures.

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 en savoir plus, consultez la section Obtenir le code produit de votre instance.

Si l'instance d'origine exécute SELinux (RHEL, CentOS 7 ou 8, par exemple), lancez l'instance de secours à partir d'une AMI qui utilise SELinux. Si vous sélectionnez une AMI exécutant un autre système d'exploitation, tel qu'Amazon Linux 2, tout fichier modifié sur l'instance d'origine endommagerait les étiquettes SELinux.

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/sdf.

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 /
xvdf    202:0     0   15G  0 disk
    └─xvdf1 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 en savoir plus, consultez la section Amazon EBS et NVMe sur les instances Linux. Voici un exemple de sortie de commande lsblk sur une instance Nitro :

NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1        259:0    0    8G  0 disk 
└─nvme0n1p1    259:1    0    8G  0 part /
└─nvme0n1p128  259:2    0    1M  0 part 
nvme1n1        259:3    0  100G  0 disk 
└─nvme1n1p1    259:4    0  100G  0 part /

13.    Exécutez la commande suivante pour devenir racine :

sudo -i

14.    Montez la partition racine du volume monté sur /mnt. Dans l'exemple précédent, /dev/xvdf1 ou /dev/nvme1n1p1 est la partition racine du volume monté. Pour en savoir plus, consultez la section Rendre un volume Amazon EBS disponible pour une utilisation sur Linux. Dans l'exemple suivant, remplacez /dev/xvdf1 par la partition racine appropriée pour votre volume.

mount -o nouuid /dev/xvdf1 /mnt

Remarque : Si /mnt n'existe pas dans votre configuration, créez un répertoire de montage, puis montez la partition racine du volume monté sur ce nouveau répertoire. 

mkdir /mnt
mount -o nouuid /dev/xvdf1 /mnt

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

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

for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done

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

Remarque : Si vous disposez d'une partition /boot distincte, montez-la dans /mnt/boot avant d'exécuter la commande suivante.

chroot /mnt

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

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, 16.04 et 18.04
• GRUB2 pour RHEL 7 et Amazon Linux 2
• GRUB2 pour RHEL 8 et CentOS 8

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

Servez-vous de la commande sed pour remplacer le noyau corrompu par le noyau stable dans le fichier /boot/grub/grub.conf :

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

GRUB2 pour Ubuntu 14 LTS, 16.04 et 18.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 :

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 :

grub-set-default 1

GRUB2 pour RHEL 7 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 :

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 :

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-172-31-29-221 /]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"
index=1
kernel="/boot/vmlinuz-0-rescue-0c75beb2b6ca4d78b335e92f0002b619"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"
root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
initrd="/boot/initramfs-0-rescue-0c75beb2b6ca4d78b335e92f0002b619.img"
title="Red Hat Enterprise Linux (0-rescue-0c75beb2b6ca4d78b335e92f0002b619) 8.4 (Ootpa)"
id="0c75beb2b6ca4d78b335e92f0002b619-0-rescue"
index=2
kernel="/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
initrd="/boot/initramfs-4.18.0-305.3.1.el8_4.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.3.1.el8_4.x86_64) 8.4 (Ootpa)"
id="ec2fa869f66b627b3c98f33dfa6bc44d-4.18.0-305.3.1.el8_4.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-4.18.0-305.3.1.el8_4.x86_64

Remarque : Remplacez 4.18.0-305.3.1.el8_4.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
umount /mnt/{dev,proc,run,sys,}

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

---