Je reçois une erreur « Kernel panic » (Panique du noyau) après avoir mis à niveau le noyau ou tenté de redémarrer mon instance EC2 Linux. Comment résoudre ce problème ?

Brève description

Votre instance ne démarre pas et affiche le message d'erreur de panique du noyau pour les raisons suivantes :

• L'image initramfs ou initrd est absente de la configuration du noyau nouvellement mise à jour dans /boot/grub/grub.conf. Ou bien, le fichier initrd ou initramfs lui-même est absent du répertoire /boot.
• Les packages du noyau ou du système n'ont pas été entièrement installés pendant la mise à niveau en raison d'un espace insuffisant.
• Les modules tiers sont absents de l'image initrd ou initramfs. Par exemple, les modules NVMe, LVM ou RAID.

Solution

L'image initramfs ou initrd est absente du répertoire /boot/grub/grub.conf ou/boot

Utilisez l'une des méthodes suivantes pour corriger ce problème :

Méthode 1 : utilisation d'EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Windows, vous pouvez ensuite l'utiliser pour dépanner les types d'instances pris en charge basés sur Nitro. La console de série permet de résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. La console série 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 la console série, 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. De même, chaque instance utilisant EC2 Serial Console 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 à Serial Console, suivez les instructions de la Méthode 2 : Utilisation d'une instance de secours. Pour en savoir plus sur la configuration d'EC2 Serial Console pour Linux, consultez Configuration de l'accès à EC2 Serial Console.

Remarque : Si vous recevez des erreurs lors de l'exécution de commandes AWS CLI, vérifiez que vous utilisez la version la plus récente d'AWS CLI.

Méthode 2 : Utilisation d'une instance de secours

Avertissement :

• Cette procédure nécessite d'arrêter et de redémarrer votre instance EC2. Notez que si votre instance repose sur un stockage d’instance ou qu'elle dispose de volumes de stockage d’instance qui contiennent des données, les données sont perdues lorsque vous arrêtez l’instance. Pour plus d'informations, consultez Détermination du type d'appareil racine de votre instance.
• Si vous lancez des instances à l'aide d'EC2 Auto Scaling, l'arrêt de l'instance peut résilier l'instance. Certains services AWS utilisent EC2 Auto Scaling pour lancer des instances. C'est le cas d'Amazon EMR, d'AWS CloudFormation et d'AWS Elastic Beanstalk. Vérifiez les paramètres de protection de diminution de la taille des instances de votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement de ce groupe avant de suivre les étapes de résolution du problème.
• L'adresse IP publique de votre instance change lorsque vous arrêtez et démarrez une instance. Il est recommandé d'utiliser une adresse IP Elastic au lieu d'une adresse IP publique lors de l'acheminement du trafic externe vers l'instance.

1.    Ouvrez la console Amazon EC2.

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

3.    Sélectionnez Actions, Instance State (État de l'instance), Stop instance (Arrêter l'instance).

4.    Dans l'onglet Storage (Stockage), sélectionnez l'appareil racine (Root device), puis l'ID de volume (Volume ID).

Remarque : Vous pouvez créer un instantané du volume racine comme sauvegarde avant de passer à l'étape 5.

5.    Choisissez Actions, Detach Volume (Détacher le volume) (/dev/sda1 ou /dev/xvda), puis choisissez Yes, Detach (Oui, détacher).

6.    Vérifiez que l'état est défini Disponible.

7.    Lancez une nouvelle instance EC2 dans la même zone de disponibilité via le même système d'exploitation et la même version de noyau que l'instance d'origine. Vous pouvez installer la version appropriée du noyau après le lancement initial, puis effectuer un redémarrage. Cette nouvelle instance est votre instance de secours.

8.    Une fois que l'instance de secours démarre, choisissez Volumes dans le volet de navigation, puis sélectionnez le volume racine détaché de l'instance d'origine.

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

10.    Sélectionnez l'ID de l'instance de secours (1-xxxx), puis entrez /dev/xvdf.

11.     Exécutez la commande suivante pour vérifier que le volume racine de l'instance dégradée est correctement attaché à l'instance de secours :

$ 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:80    0   15G  0  disk
└─xvdf1 202:0     0   15G  0  part

12.    Créez un répertoire de montage, puis montez sous /mnt.

$ mount -o nouuid /dev/xvdf1 /mnt

13. Appelez un environnement chroot en exécutant la commande suivante :

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

14.    Exécutez la commande chroot sur le système de fichiers monté /mnt  :

$ chroot /mnt

Remarque : Le répertoire de travail devient «/».

15.    Exécutez les commandes suivantes en fonction de votre système d'exploitation.

Systèmes d'exploitation basés sur RPM :

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

$ sudo dracut -f -vvvvv

Systèmes d'exploitation basés sur Debian :

$ sudo update-grub && sudo update-grub2

$ sudo update-initramfs -u -vvvvv

16.    Vérifiez que l'image initrd ou initramfs est présente dans le répertoire /boot et qu'elle possède une image de noyau correspondante. Par exemple, vmlinuz-4.14.138-114.102.amzn2.x86_64 et initramfs-4.14.138-114.102.amzn2.x86_64.img.

17.    Après avoir vérifié que le dernier noyau a une image initrd ou initramfs correspondante, exécutez les commandes suivantes pour quitter et nettoyer l'environnement chroot :

$ exit

umount /mnt/{dev,proc,run,sys,}

18.    Détachez le volume racine de l'instance de secours, puis attachez-le à l'instance d'origine.

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

Le package du noyau ou système n'a pas été entièrement installé pendant une mise à jour

Revenez à une version précédente du noyau. Pour obtenir des instructions, consultez Comment rétablir un noyau stable connu après qu'une mise à jour empêche mon instance Amazon EC2 de redémarrer correctement ?

Les modules tiers sont absents de l'image initrd ou initramfs

Investiguez pour identifier le ou les modules qu'il manque dans l'image initrd ou initramfs. Vérifiez ensuite si vous pouvez rajouter le module à l'image. Il est souvent plus facile de recréer l'instance.

Voici un exemple de sortie de console d'une instance Amazon Linux 2 s'exécutant sur la plateforme Nitro. Le module nvme.ko est absent de l'image initramfs de l'instance :

dracut-initqueue[1180]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[1180]: Warning: Could not boot.
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
dracut-initqueue[1180]: Warning: /dev/disk/by-uuid/55da5202-8008-43e8-8ade-2572319d9185 does not exist
dracut-initqueue[1180]: Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line.
Starting Show Plymouth Power Off Screen...

Pour déterminer si l'erreur de panique du noyau est provoquée par un ou plusieurs modules tiers manquants, procédez comme suit :

1.    Utiliser la Méthode 1 : Utilisation d'EC2 Serial Console de la section précédente pour créer un environnement chroot dans le volume racine de l'instance qui ne démarre pas.

-ou-

Suivez les étapes 1 à 14 de la Méthode 2 : Utilisation d'une instance de secours de la section précédente pour créer un environnement chroot dans le volume racine de l'instance qui ne démarre pas.

2.    Utilisez l'une des trois options suivantes pour identifier le ou les modules qu'il manque dans l'image initramfs ou initrd :

Option 1 : exécutez la commande dracut -f -v dans le répertoire /boot pour déterminer si la recréation de l'image initrd ou initramfs échoue. Utilisez également la commande dracut -f -v pour répertorier le ou les modules manquants.
Remarque : Il se peut que la commande dracut -f -v ajoute les modules manquants à l'image initrd ou intramfs. Si la commande ne trouve pas d'erreurs, essayez de redémarrer l'instance. Si l'instance redémarre, c'est que la commande a résolu l'erreur.

Option 2 : exécutez la commande lsinitrd initramfs-4.14.138-114.102.amzn2.x86_64.img | less pour afficher le contenu du fichier initrd ou initramfs. Remplacez initramfs-4.14.138-114.102.amzn2.x86_64.img par le nom de votre image.

Option 3 : inspectez le répertoire /usr/lib/modules.

3.     Si vous trouvez un module manquant, vous pouvez essayer de l'ajouter au noyau. Pour plus d'informations sur la façon d'obtenir et d'ajouter des modules dans le noyau, consultez la documentation de votre distribution Linux.

---