Je reçois une erreur « Panique du noyau » après avoir mis à niveau le noyau ou essayé de redémarrer mon instance EC2 Linux. Comment puis-je corriger cette erreur ?

Date de la dernière mise à jour : 28/05/2020

L'instance ne démarre pas et le message suivant s'affiche après une mise à niveau du noyau ou du système, ou après le redémarrage du système sur mon instance Amazon Elastic Compute Cloud (Amazon EC2) :

« VFS : impossible d'ouvrir le dispositif racine XXX ou bloc inconnu (0,0)
Veuillez ajouter une option de démarrage « root= » appropriée. Voici les partitions disponibles :
Panique du noyau – aucune synchronisation : VFS : impossible de monter le système de fichiers racines dans un bloc inconnu (0,0) »

Brève description

Votre instance peut ne pas démarrer et afficher 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, le fichier initrd ou initramfs lui-même est absent du répertoire /boot.
  • Les packages du noyau ou système n'ont pas été entièrement installés pendant la mise à niveau en raison d'une insuffisance d'espace.
  • Les modules tiers sont absents de l'image initrd ou initramfs. Par exemple, les modules NVMe, LVM ou RAID.

Résolution

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

Avertissement :

  • Cette procédure nécessite d'arrêter et de redémarrer votre instance EC2. Notez que les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instance ou dispose de volumes de stockage d'instance contenant des données. Pour plus d'informations, consultez Identification du type de dispositif racine de votre instance.
  • Si vous lancez des instances à l'aide d'EC2 Auto Scaling, l'arrêt de l'instance peut mettre fin à l'instance. Certains services AWS utilisent EC2 Auto Scaling pour lancer des instances. C'est le 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.    Choisissez Actions, État de l'instance, Arrêter.

4.    Dans l'onglet Description sélectionnez le dispositif racine, puis l'ID EBS.

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

5.    Choisissez Actions, puis Détacher le volume (/dev/sda1 ou /dev/xvda) et 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é et avec le même système d'exploitation que l'instance d'origine. 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.    Sélectionnez Actions, puis 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 /dev/xvdf1 /mnt

13.    Exécutez et 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
$ for i in dev proc sys run; do sudo umount /mnt/$i; done

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 savoir comment revenir à un noyau précédent, 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.

Identifiez les modules absents de l'image initrd ou initramfs et vérifiez que vous pouvez ajouter le module à l'image. Dans de nombreux cas, il est 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'instance de l'image initramfs :

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

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

1.    Suivez les étapes 1 à 14 de la section précédente L'image initramfs ou initrd est absente du répertoire /boot/grub/grub.conf ou/boot 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 déterminer les modules absents de 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 et pour répertorier le module ou les modules manquants.
Remarque : la commande dracut -f -v peut ajouter les modules manquants à l'image initrd ou intramfs. Si la commande ne trouve aucune erreur, essayez de redémarrer l'instance. Si l'instance redémarre, c'est que la commande a éliminé 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.


Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?