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 ?
Une mise à jour a empêché le redémarrage de mon instance Amazon Elastic Compute Cloud (Amazon EC2) et je souhaite revenir à un noyau stable.
Brève description
Si vous avez effectué une mise à jour du noyau de votre instance Amazon EC2 Linux mais que le noyau est maintenant endommagé, l'instance ne peut pas redémarrer. Vous ne pouvez pas utiliser SSH pour vous connecter à l'instance altérée.
Résolution
Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l’interface de la ligne de commande AWS (AWS CLI), consultez la page Résoudre les erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez la version la plus récente de l'interface AWS CLI.
Accéder au volume racine de l'instance
Il existe deux méthodes pour accéder au volume racine. Choisissez celle qui correspond le mieux à votre cas d'utilisation.
Utiliser la console de série EC2
Si vous avez activé Console de série EC2 pour Linux, vous pouvez l’utiliser pour résoudre les problèmes liés aux types d’instances basés sur Nitro. Cette console vous permet de résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. Elle se connecte à votre instance sans nécessiter de connexion réseau fonctionnelle. Vous pouvez utiliser la console Amazon EC2 ou l'interface de la ligne de commande AWS (AWS CLI) pour accéder à la console de série EC2.
Avant d’utiliser la console de série, accordez-lui l'accès au niveau du compte. Puis, créez des stratégies AWS Identity and Access Management (IAM) qui accordent l'accès aux utilisateurs IAM. Chaque instance qui utilise la console série doit inclure au moins un utilisateur avec mot de passe. Pour en savoir plus, consultez la section Configurer l'accès à la console de série EC2.
Si votre instance est inaccessible et que vous n'avez pas configuré l'accès à la console de série, suivez les instructions figurant dans la section suivante.
Utiliser une instance de secours
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, configurez votre GRUB GNU pour utiliser le noyau précédent.
Important : Cette procédure de restauration ne doit pas être effectuée sur une instance basée sur le stockage d'instance. Comme la procédure de restauration nécessite l'arrêt et le démarrage de votre instance, toutes les données se trouvant sur cette instance seront en effet perdues. Pour en savoir plus, consultez la section Déterminer le type de périphérique racine de votre instance.
- Créez un instantané Amazon EBS du volume racine. Pour en savoir plus, consultez la section Créer des instantanés Amazon EBS.
- Ouvrez la console Amazon EC2.
Remarque : Vérifiez que vous êtes dans la bonne région. - Dans le volet de navigation, sélectionnez Instances, puis choisissez l’instance altérée.
- Sélectionnez État de l’instance, Arrêter l’instance, puis Arrêter.
- Dans l'onglet Stockage, sousPériphériques de stockage en mode bloc, sélectionnez l'ID de volume pour /dev/sda1 ou /dev/xvda.
Remarque : Le périphérique racine varie selon l'AMI, mais /dev/xvda ou /dev/sda1 sont réservés au périphérique racine. Par exemple, Amazon Linux 1, Amazon Linux 2 et Amazon Linux 2023 utilisent /dev/xvda. D'autres distributions, telles qu’Ubuntu 14, 16, 18, CentOS 7 et RHEL 7.5 utilisent /dev/sda1. - Sélectionnez Actions, Détacher un volume, puis Oui, détacher.
Remarque : Pour faciliter l'identification du volume EBS lors des étapes ultérieures, étiquetez-le avant de le détacher. - Lancez une instance EC2 de secours dans la même zone de disponibilité que votre instantané.
Remarque : Selon le code produit, il est possible que vous deviez lancer une instance EC2 du même type de système d'exploitation. Par exemple, si l'instance EC2 altéré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 pour votre instance. - Une fois l'instance de secours lancée, sélectionnez Volumes dans le volet de navigation. Puis, sélectionnez le volume racine détaché de l'instance altérée.
- Sélectionnez Actions, puis Attacher un volume.
- Choisissez l'ID de l'instance de secours (id-#####), puis définissez un périphérique inutilisé. Dans cet exemple, il s’agit de /dev/sdf.
- Connectez-vous à l’instance de secours avec le protocole SSH.
- Pour afficher les unités de disque disponibles, exécutez la commande lsblk : Voici un exemple de sortie :
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 affiche les noms de disque sous la forme nvme[0-26 ]n1. Pour plus d’informations, consultez la section Amazon EBS et NVMe. Voici un exemple de sortie de la commande lsblk sur une instance basée sur 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 /
- Pour devenir l'utilisateur racine, exécutez la commande suivante :
sudo -i
- Montez la partition racine du volume monté sur /mnt. Dans l'exemple suivant, /dev/xvdf1 ou /dev/nvme1n1p1 représente la partition racine du volume monté. Pour plus d'informations, consultez la section Rendre un volume Amazon EBS accessible à l’utilisation. 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é dans le nouveau répertoire.
mkdir /mnt mount -o nouuid /dev/xvdf1 /mnt
Accédez ensuite aux données de l'instance altérée par le biais du répertoire de montage. Montez /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 accéder au répertoire de montage.
Remarque : Si vous disposez d’une partition /boot distincte, montez-la sur /mnt/boot avant d'exécuter la commande suivante.
chroot /mnt
Mettre à jour le noyau par défaut dans le chargeur de démarrage GRUB
Le noyau endommagé actuel est en position 0 (zéro) dans la liste. Le dernier noyau stable est en position 1. Pour remplacer le noyau endommagé par le noyau stable, utilisez l'une des procédures suivantes, en fonction de votre distribution.
GRUB1 (GRUB ancien) pour Red Hat 6 et Amazon Linux 1
Utilisez la commande sed pour remplacer le noyau endommagé 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
Procédez comme suit :
-
Remplacez l'entrée de menu par défaut GRUB_DEFAULT=0 endommagée par la valeur GRUB_DEFAULT=saved stable dans le fichier /etc/default/grub :
sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub
-
Pour vous assurer que GRUB reconnaît la modification, exécutez la commande update-grub :
update-grub
-
Exécutez la commande grub-set-default afin que le noyau stable soit chargé lors du redémarrage suivant. Dans l'exemple suivant, grub-set-default est défini à 1 en position 0 :
grub-set-default 1
GRUB2 pour RHEL 7 et Amazon Linux 2
Procédez comme suit :
-
Remplacez l'entrée de menu par défaut GRUB_DEFAULT=0 endommagée par la valeur GRUB_DEFAULT-saved stable dans le fichier /etc/default/grub :
sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub
-
Mettez à jour GRUB pour régénérer le fichier /boot/grub2/grub.cfg :
grub2-mkconfig -o /boot/grub2/grub.cfg
-
Pour vous assurer que le noyau stable se charge lors du redémarrage suivant, exécutez la commande grub2-set-default. Dans l'exemple suivant, grub2-set-default est défini à 1 en position 0 :
grub2-set-default 1
GRUB2 pour RHEL 8 et CentOS 8, et Amazon Linux 2023
GRUB2 utilise des fichiers blscfg et des entrées 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 dans /boot/loader/entries/. Si les fichiers blscfg sont manquants ou endommagés, grubby n'affiche aucun résultat. Pour restaurer la fonctionnalité, vous devez régénérer les fichiers. L'indexation des noyaux varie en fonction des fichiers .conf situés sous /boot/loader/entries et des versions des noyaux. L'indexation permet de conserver le noyau le plus récent avec l'index le plus bas. Pour plus d’informations, consultez la section 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 ?
Procédez comme suit :
-
Pour voir le noyau par défaut actuel, exécutez la commande grubby --default-kernel :
grubby --default-kernel
-
Pour voir tous les noyaux disponibles et leurs index, exécutez la commande grubby --info=ALL :
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 avez défini par défaut pour votre instance. Dans cet exemple, le chemin du noyau à l'index 2 est**/boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64**.
-
Pour modifier le noyau par défaut de l'instance, exécutez la commande grubby --set-default :
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.
-
Pour vérifier que la commande précédente a réussi, exécutez la commande grubby --default-kernel :
grubby --default-kernel
Si vous accédez à l'instance via la console de série EC2, le noyau stable se charge maintenant et vous pouvez redémarrer l'instance. Si vous utilisez une instance de secours, suivez les étapes figurant dans la section suivante.
Démonter les volumes, détacher le volume racine de l'instance de secours, puis attacher le volume à l'instance altérée
Si vous avez utilisé une instance de secours pour accéder au volume racine, procédez comme suit :
-
Exécutez la commande suivante pour quitter chroot, et démontez /dev, /run, /proc et /sys :
exit umount /mnt/{dev,proc,run,sys,}
-
Dans la console Amazon EC2, sélectionnez Instances. Puis, choisissez l'instance de secours.
-
Sélectionnez État de l’instance, Arrêter l’instance, puis sélectionnez Oui, Arrêter.
-
Détachez l'instance altérée du volume racine de l'instance de secours.
-
Attachez le volume racine que vous avez détaché à l'instance altérée en tant que volume racine (/dev/sda1). Puis, démarrez l'instance.
Remarque : le périphérique racine varie selon l'AMI. Les noms /dev/xvda ou /dev/sda1 sont réservés au périphérique racine. Par exemple, Amazon Linux 1, Amazon Linux 2 et Amazon Linux 2023 utilisent /dev/xvda. D'autres distributions, telles qu'Ubuntu 14, 16, 18, CentOS 7 et RHEL 7.5, utilisent /dev/sda1.
Le noyau stable se charge maintenant et votre instance redémarre.
Vidéos associées
Contenus pertinents
- demandé il y a un anlg...
- demandé il y a un anlg...
- demandé il y a 2 anslg...
- Réponse acceptéedemandé il y a 6 moislg...
- demandé il y a un anlg...
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 mois