Résoudre les problèmes de démarrage des VM Linux en raison d'une panique du noyau

Ce document inclut des informations de dépannage concernant une VM qui ne répond plus en raison d'erreurs de panique du noyau.

Avant de commencer

Si vous souhaitez journaliser la sortie du port série sur Cloud Logging, familiarisez-vous avec Cloud Logging.
Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :
Console

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.
gcloud
1. Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante :
```
gcloud init
```
  Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant gcloud components update.
2. Définissez une région et une zone par défaut.
REST

Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

Panique du noyau

Une panique du noyau peut se produire lorsque le noyau ne peut pas charger correctement les modules initramfs, qui sont requis pour que le système d'exploitation invité démarre.

Une autre forme de panique du noyau peut se produire dans une situation où le noyau ne sait pas comment gérer une requête donnée et se protège en s'arrêtant. La panique du noyau peut se produire sur une VM Compute Engine exécutant RedHat, SUSE, CentOS ou Ubuntu.

Messages d'erreur fréquents

Voici quelques-uns des événements de panique du noyau les plus courants, à titre de référence :

Kernel panic - not syncing: hung_task: blocked tasks

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Kernel panic - not syncing: NMI: Not continuing

Kernel panic - not syncing: out of memory. panic_on_oom is selected

Kernel panic - not syncing: Fatal Machine check

Causes courantes

L'erreur de panique du noyau peut se produire pour plusieurs raisons. Voici quelques-unes des raisons les plus courantes :

L'entrée associée au fichier initramfs correspondant au noyau n'existe pas dans le fichier grub.cfg.
Le fichier initramfs n'est pas généré dans le répertoire /boot lors de l'installation du noyau.
Le fichier initramfs n'est que partiellement généré ou corrompu.

Symptômes

En cas de panique du noyau sur une instance de VM, l'un des symptômes courants est que le noyau ne vous permet pas de vous connecter à la VM, même lorsque vous utilisez la console série.

Vous devez vérifier les journaux de la console série pour identifier le noyau chargé par le système d'exploitation invité, par exemple :

[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-1160.95.1.el7.x86_64 (mockbuild@x86-vm-42.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Thu Aug 10 10:46:21 EDT 2023

Vérifiez également l'erreur de panique du noyau. Cette erreur est généralement visible au niveau de la ligne de noyau au démarrage de la VM ou à la fin des journaux de la console série avec plusieurs traces d'appel de pile.

L'exemple suivant montre une panique du noyau en raison de problèmes initramfs :

[    1.520840] No filesystem could mount root, tried:
[    1.520840]
[    1.521964] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.523495] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.0-1160.95.1.el7.x86_64 #1
[    1.524932] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
[    1.526901] Call Trace:
[    1.527421]  dump_stack+0x41/0x60
[    1.527978]  panic+0xe7/0x2ac
[    1.528578]  mount_block_root+0x2be/0x2e6
[    1.529693]  ? do_early_param+0x95/0x95
[    1.530441]  prepare_namespace+0x135/0x16b
[    1.531237]  kernel_init_freeable+0x203/0x22d
[    1.532081]  ? rest_init+0xaa/0xaa
[    1.532808]  kernel_init+0xa/0x103
[    1.533395]  ret_from_fork+0x35/0x40
[    1.535229] Kernel Offset: 0x23a00000 from 0xffffffff81000000

Résoudre l'erreur de panique du noyau

Pour résoudre l'erreur de panique du noyau, procédez comme suit :

Connectez-vous à la console série, puis connectez-vous à la VM à partir de la console Google Cloud.
Cliquez sur Réinitialiser pour la VM dans la console Google Cloud.
Une fois que l'écran d'accueil GRUB s'affiche, sélectionnez le noyau préalablement opérationnel ou le noyau de secours, puis démarrez le système. La VM démarre alors avec le noyau sélectionné.

Remarque : Le démarrage de la VM en sélectionnant le noyau précédent depuis l'écran d'accueil de GRUB ne modifie pas le fichier de configuration GRUB. Il ne s'agit donc pas d'une modification persistante.
Lorsque la VM est accessible, vous pouvez établir une connexion SSH à la VM.
Identifiez la cause du problème et prenez les mesures nécessaires.

Par exemple, si le fichier initramfs est manquant ou corrompu, procédez comme suit :
1. Générez le fichier initramfs correspondant au noyau d'origine à l'aide de la commande dracut, par exemple :
```
dracut -f /boot/initramfs-3.10.0-1160.95.1.el7.x86_64.img 3.10.0-1160.95.1.el7.x86_64
```
2. Mettez à jour le fichier grub2.cfg à l'aide de la commande grub2-mkconfig, par exemple :
```
grub2-mkconfig -o /boot/grub2/grub.cfg
```
3. Une fois le fichier initramfs généré, vous pouvez redémarrer la VM sans aucune erreur.