Comment résoudre l'erreur « Kernel panic - not syncing » (Panique du noyau - non synchronisé) dans mon instance EC2 ?

Brève description

L'erreur « Kernel panic - not sync » (Panique de noyau - non synchronisé) se produit lorsque le périphérique ou l'adresse n'existent pas. Pour résoudre ce problème, lancez une instance temporaire, puis attachez le disque racine défectueux en tant que lecteur secondaire pour effectuer des diagnostics.

Important : Avant d'arrêter et de démarrer votre instance, effectuez les actions suivantes :

• Créez une sauvegarde de votre volume Amazon Elastic Block Store (Amazon EBS).
  Remarque : Si votre instance est sauvegardée par un stockage d'instances ou si ses volumes de stockage d'instances contiennent des données, Amazon EC2 supprime les données lorsque vous arrêtez l'instance.
• Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling lorsque vous avez terminé les étapes de résolution.
  Remarque : Si vous arrêtez une instance qui se trouve dans un groupe Amazon EC2 Auto Scaling, vous pouvez résilier l'instance en fonction de vos paramètres de protection de réduction horizontale. Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling.
• Définissez le comportement d'arrêt de l'instance** sur **Arrêter pour vous assurer que les instances ne se résilient pas lorsque vous les arrêtez.

Remarque : Lorsque vous arrêtez et démarrez une instance, son adresse IP publique change. Une bonne pratique consiste à utiliser une adresse IP Elastic pour acheminer le trafic externe vers votre instance au lieu d'une adresse IP publique.

Pour en savoir plus, consultez la section Ce qu’il se passe lorsque vous arrêtez une instance.

Résolution

Remarque : Les étapes de résolution suivantes concernent uniquement Amazon Linux 2, Amazon Linux 2023, Fedora 16 et versions ultérieures, et Red Hat Enterprise Linux (RHEL) 7 et versions ultérieures.

Pour attacher le disque racine à une instance temporaire, procédez comme suit :

1. Obtenez l'ID de volume et le nom du périphérique pour le volume racine de l'instance d'origine.

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

3. Lancez une instance temporaire à partir d'une Amazon Machine Image (AMI) avec la même version du système d'exploitation Linux dans la même zone de disponibilité.

4. Détachez le volume racine de l'instance d'origine et attachez-le à l'instance temporaire en tant que volume secondaire. Notez le nom du périphérique de volume.

5. Utilisez la paire de clés SSH pour vous connecter à l'instance temporaire.

6. Utilisez la commande suivante pour passer à l’utilisateur racine :

   sudo su

7. Pour identifier le nom et la partition du périphérique de stockage en mode bloc, exécutez la commande suivante depuis l'instance temporaire :

   lsblk

   Exemple de sortie :

   NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   xvda    202:0    0    8G  0 disk
   └─xvda1 202:1    0    8G  0 part /
   xvdf    202:80   0  101G  0 disk
   └─xvdf1 202:81   0  101G  0 part
   xvdg    202:80   0   10G  0 disk

   Cet exemple utilise une instance XEN avec des pilotes blkfront.

8. Si vous utilisez un volume partitionné, exécutez la commande suivante pour monter la partition /dev/xvdf1 au lieu du périphérique /dev/xvdf :

   mount -o nouuid  /dev/xvdf1 /mnt

   Remarque : /dev/xvda et /dev/xvdf sont des volumes partitionnés, mais /dev/xvdg ne l’est pas.
   Si vous utilisez une instance créée sur le système AWS Nitro, le nom du périphérique de volume est similaire à /dev/nvme[0-26]n1. Pour monter la partition dans le répertoire /mnt, exécutez la commande suivante :

   mount -o nouuid  /dev/nvme1n1p1 /mnt

   Remarque : Remplacez nvme1n1p1 par le nom du périphérique de blocage que vous avez identifié à l'étape 7. Pour plus d'informations, consultez la section Noms de périphériques pour les volumes sur les instances Amazon EC2.

9. Pour créer un environnement chroot dans le répertoire /mnt, exécutez la commande suivante :

   for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done; chroot /mnt

   Dans cet exemple, les répertoires /dev, /proc, /sys et /run sont montés par liaison à partir du système de fichiers racine d'origine. Cette configuration permet aux processus qui s'exécutent dans l'environnement chroot d'accéder aux répertoires système.

10. Pour créer une sauvegarde du fichier initramfs dans le répertoire /, exécutez la commande suivante :

for file in /boot/initramfs-*.img; do cp "${file}" "/$(basename "$file")_$(date +%Y%m%d)"; done

11. Pour répertorier le noyau par défaut, exécutez la commande suivante :

grubby --default-kernel

Exemple de sortie :

/boot/vmlinuz-5.15.156-102.160.amzn2.x86_64

La sortie précédente répertorie les noyaux qui sont lancés au démarrage. Pour répertorier les noyaux et initramfs dans le répertoire de démarrage, exécutez la commande suivante :

 ls -lh /boot/vmlinuz* && ls -lh /boot/initr*

Exemple de sortie :

-rwxr-xr-x. 1 root root 9.7M Apr 23 20:37 /boot/vmlinuz-5.10.215-203.850.amzn2.x86_64-rwxr-xr-x. 1 root root 9.9M Apr 23 17:00 /boot/vmlinuz-5.15.156-102.160.amzn2.x86_64
-rw-------. 1 root root 12M May 3 23:45 /boot/initramfs-5.10.215-203.850.amzn2.x86_64.img
-rw-------. 1 root root 9.8M May 14 08:03 /boot/initramfs-5.15.156-102.160.amzn2.x86_64.img

Notez les fichiers du noyau vmlinuz qui contiennent les fichiers initramfs correspondants. Pour reconstruire le fichier initramfs, exécutez la commande suivante :

dracut --force --verbose /boot/initramfs-kernelVersion.img kernelVersion

Remarque : Remplacez kernelVersion par la dernière version du noyau. Pour déterminer si l'instance démarre sur UEFI ou BIOS, exécutez la commande suivante :

boot_mode=$(ls /sys/firmware/efi/efivars >/dev/null 2>&1 && echo "EFI" || echo "BIOS"); echo "Boot mode detected: $boot_mode"

15. Mettez à jour la configuration de grub. Si votre instance démarre sur le BIOS, exécutez la commande suivante :

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

Remarque : Lorsque vous exécutez la commande précédente, vous pouvez recevoir le message d’erreur « device-mapper: reload ioctl on osprober-linux-xvda2 (253:0) failed: Device or resource busy Command failed » (Échec de device-mapper: reload ioctl on osprober-linux-xvda2 (253:0) : Périphérique ou ressource occupé Échec de la commande). Pour résoudre ce problème, ajoutez le paramètre GRUB_DISABLE_OS_PROBER=true au fichier /etc/default/grub, puis exécutez de nouveau la commande.
Si votre instance démarre sur UEFI, exécutez les commandes suivantes en fonction de votre système d'exploitation.
UEFI :
Amazon Linux 2 et Amazon Linux 2023 :

grub2-mkconfig -o /boot/efi/EFI/amzn/grub.cfg

Fedora 16 et versions ultérieures :

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Red Hat 7 et versions ultérieures :

grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

16. Pour quitter et détacher le volume, exécutez la commande suivante :

exit; umount -fl /mnt

17. Détachez le volume secondaire de l'instance temporaire et attachez-le à l'instance d'origine en tant que périphérique racine. Utilisez le nom de périphérique que vous avez noté à l'étape 4.
18. Connectez-vous à l'instance d'origine.