Passer au contenu

Comment revenir à un noyau stable connu après qu'une mise à jour bloque le redémarrage de mon instance EC2 ?

Lecture de 9 minute(s)
0

Une mise à jour a empêché le redémarrage de mon instance Amazon Elastic Compute Cloud (Amazon EC2). Je souhaite revenir à un noyau stable.

Brève description

Si vous avez effectué une mise à jour du noyau de votre instance EC2 Linux mais que le noyau est maintenant endommagé, l'instance ne peut pas redémarrer. Vous ne pouvez pas non plus utiliser SSH pour vous connecter à l'instance concernée.

Pour résoudre ce problème, utilisez l’EC2 Serial Console pour accéder à votre volume racine. Vous pouvez également créer une instance de secours temporaire, puis remonter votre volume Amazon Elastic Block Store (Amazon EBS) sur celle-ci. Configurez votre GNU GRUB pour utiliser le noyau précédent, puis redémarrez l'instance.

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 section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Accéder au volume racine de l'instance

Pour accéder au volume racine, utilisez l’EC2 Serial Console ou une instance de secours.

Utiliser l’EC2 Serial Console

Prérequis : Vous devez déjà avoir configuré l'accès à l’EC2 Serial Console. Si votre instance est inaccessible et que vous n'avez pas encore configuré l'accès, vous devez utiliser une instance de secours pour accéder au volume racine. Assurez-vous également de respecter les prérequis relatifs à la console série.

Si vous avez activé l’EC2 Serial Console pour Linux, utilisez-la pour les types d'instances basés sur Nitro afin de résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH.

Vous pouvez utiliser la console série pour vous connecter à votre instance sans disposer d’une connexion réseau fonctionnelle.

Avant d’utiliser la console de série, accordez-lui l'accès au niveau du compte AWS. Puis, créez des politiques de Gestion des identités et des accès AWS (AWS 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.

Utiliser une instance de secours

Important : N’effectuez pas cette procédure sur une instance basée sur le stockage d'instances. La procédure de restauration nécessite l'arrêt et le démarrage de votre instance. Vous perdrez donc les données de l'instance.

Pour utiliser une instance de secours pour accéder au volume racine, procédez comme suit :

  1. Créez un instantané Amazon EBS du volume racine.

  2. Arrêtez l'instance concernée.

  3. Détachez le volume racine Amazon EBS (/dev/xvda ou /dev/sda1) de l’instance concernée. Notez le nom de périphérique de votre volume racine.
    Remarque : Pour faciliter l'identification du volume EBS lors des étapes ultérieures, étiquetez-le avant de le détacher. Le périphérique racine diffère en fonction de l’Amazon Machine Image (AMI). Par exemple, Amazon Linux 2 (AL2) et Amazon Linux 2023 (AL2023) utilisent /dev/xvda. Cependant, Ubuntu 14, 16, 18, CentOS 7 et Red Hat Enterprise Linux (RHEL) 7.5 utilisent /dev/sda1.

  4. Lancez une instance EC2 de secours dans la même zone de disponibilité que votre instantané.
    Remarque : Vérifiez le code produit de votre instance. Certains codes produit nécessitent que vous lanciez une instance EC2 dans le même type de système d'exploitation. Par exemple, si l'instance concernée est une AMI RHEL payante, vous devez lancer une AMI avec le même code produit. Si vous disposez d’une instance AL2, vous devez créer une instance de secours AL2 pour éviter les erreurs.

  5. Attachez le volume en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.

  6. Connectez-vous à l’instance de secours avec le protocole SSH.

  7. Pour consulter les unités de disque disponibles, exécutez la commande suivante :

    lsblk

    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 affichent les volumes EBS en tant que périphériques en mode bloc NVMe avec le nom de disque nvme[0-26]n1. Exemple de sortie 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 /
  8. Pour devenir l'utilisateur racine, exécutez la commande suivante :

    sudo -i
  9. Pour monter la partition racine du volume monté sur /mnt, exécutez la commande suivante :

    mount -o nouuid /dev/xvdf1 /mnt

    Remarque : Remplacez /dev/xvdf1 par la partition racine de votre volume. Si /mnt n'existe pas dans votre configuration, exécutez les commandes suivantes pour créer un répertoire de montage, puis montez la partition racine dans le nouveau répertoire :

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

    Remarque : Si un message d'erreur s'affiche lorsque vous exécutez la commande mount précédente, exécutez plutôt la commande suivante :

    mount /dev/xvdf1 /mnt

    Puis, utilisez le répertoire de montage pour accéder aux données de l'instance concernée.

  10. Pour monter /dev, /run, /proc et /sys de l'instance de secours sur les mêmes chemins que le volume monté, exécutez la commande suivante :

for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done
  1. Si vous disposez d’une partition /boot distincte, montez-la sur /mnt/boot.
  2. Pour accéder au répertoire de montage, exécutez la commande suivante :
chroot /mnt

Mettre à jour le noyau par défaut dans le chargeur de démarrage GRUB

Vous pouvez trouver le noyau endommagé en position 0 dans la liste, et le dernier noyau stable en position 1. Pour remplacer le noyau endommagé par le noyau stable, effectuez les étapes suivantes en fonction de votre distribution.

GRUB1 (GRUB hérité) pour Red Hat 6

Pour remplacer le noyau endommagé par le noyau stable dans le fichier /boot/grub/grub.conf, exécutez la commande suivante :

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

GRUB2 pour Ubuntu 14 LTS, 16.04 et 18.04

Procédez comme suit :

  1. Pour remplacer 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, exécutez la commande suivante :

    sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub
  2. Pour vous assurer que GRUB reconnaît la modification, exécutez la commande suivante :

    update-grub

    Remarque : Vous pourriez recevoir le message « device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed » lorsque vous reconstruisez le fichier de configuration grub. Pour résoudre ce problème, ajoutez le paramètre GRUB_DISABLE_OS_PROBER=true au fichier /etc/default/grub, puis exécutez à nouveau la commande précédente.

  3. Pour vous assurer qu'Amazon EC2 charge le noyau stable au prochain redémarrage, exécutez la commande suivante :

    grub-set-default 1

GRUB2 pour RHEL 7 et AL2

Procédez comme suit :

  1. 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
  2. Pour mettre à jour GRUB afin de régénérer le fichier /boot/grub2/grub.cfg, exécutez la commande suivante :

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

    Remarque : Vous pourriez recevoir le message « device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed » lorsque vous reconstruisez le fichier de configuration grub. Pour résoudre ce problème, ajoutez le paramètre GRUB_DISABLE_OS_PROBER=true au fichier /etc/default/grub, puis exécutez à nouveau la commande précédente.

  3. Pour vous assurer qu'Amazon EC2 charge le noyau stable au prochain redémarrage, exécutez la commande suivante :

    grub2-set-default 1

GRUB2 pour RHEL 8 et CentOS 8, et AL2023

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. Vous devez régénérer les fichiers pour restaurer la fonctionnalité.

Pour mettre à jour le noyau par défaut dans GRUB2, procédez comme suit :

  1. Pour afficher le noyau par défaut actuel, exécutez la commande suivante :

    grubby --default-kernel
  2. Pour afficher tous les noyaux disponibles et leurs index, exécutez la commande suivante :

    grubby --info=ALL

    Exemple de sortie :

    root@ip-172-31-29-221 /]# grubby --info=ALLindex=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 l'exemple précédent, le chemin du noyau sur l'index 2 est /boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64.

  3. Pour modifier le noyau par défaut de l'instance, exécutez la commande suivante :

    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. Pour vérifier que vous avez correctement configuré le noyau par défaut, exécutez la commande suivante :

    grubby --default-kernel

Redémarrer l'instance

Si vous avez utilisé l’EC2 Serial Console, Amazon EC2 charge maintenant le noyau stable. Vous pouvez redémarrer l'instance.

Si vous avez utilisé une instance de secours pour accéder au volume racine, procédez comme suit :

  1. Pour quitter chroot et démonter /dev, /run, /proc et /sys, exécutez la commande suivante :

    exit
    umount /mnt/{dev,proc,run,sys,}
  2. Arrêtez l'instance de secours.

  3. Détachez le volume de l'instance de secours.

  4. Attachez le volume racine à l'instance d'origine en tant que volume racine 1 /dev/xvda ou /dev/sda

  5. Démarrez l'instance d'origine.

  6. Amazon EC2 charge maintenant le noyau stable. Vous pouvez redémarrer l'instance.

AWS OFFICIELA mis à jour il y a 6 mois