Panique du noyau dans les machines virtuelles Linux d'Azure

S’applique à : ✔️ Machines virtuelles Linux

Résumé

Cet article décrit plusieurs conditions qui peuvent entraîner une panique du noyau et fournit des conseils de dépannage.

En général, une panique du noyau est une situation où le noyau ne peut pas se charger correctement, et par conséquent, le système ne parvient pas à démarrer. Une autre forme de panique du noyau se produit lorsque le noyau rencontre une situation qu’il ne sait pas comment gérer et se protéger en s’arrêtant.

Prerequisites

Vérifiez que la console série est activée et fonctionnelle dans la machine virtuelle Linux.

Comment identifier une panique de noyau ?

Utilisez le portail Azure pour afficher la sortie du journal de la console série de la machine virtuelle dans le volet diagnostics de démarrage, le volet console série ou AZ CLI afin d’identifier la chaîne spécifique de panique du noyau.

Une panique du noyau est similaire à la sortie ci-dessous et apparaîtra à la fin du journal de la console série.

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Voici quelques-uns des événements de panique du noyau les plus courants :

Message de panique Motif
Oops : 0000 [#1] SMP « vérifiez le fichier journal pour plus d’informations » Système paniqué en raison de la désréférence d’une mauvaise adresse.
SysRq : déclencher un crashdump Le vidage de mémoire a été initié par l’utilisateur avec sysrq-c ou en envoyant la commande echo c dans /proc/sysrq-trigger.
bug du noyau à l’adresse <pathname/filename> :<line number> ! Ce format est la norme d’une vérification de bogue échouée (qui est tout comme une assertion, mais la logique est inversée). Le nom de fichier et le numéro de ligne indiquent quelle vérification du bug a échoué.
Panique du noyau - pas de synchronisation : softlockup : tâches bloquées Le détecteur de verrouillage logiciel a identifié un processeur qui n'a pas exécuté la tâche de surveillance dans le délai imparti pour le verrouillage logiciel.
Panique du noyau - pas de synchronisation : l’agent de surveillance a détecté le verrouillage dur sur le processeur 0 Le détecteur de verrouillage dur a détecté un processeur qui n'a reçu aucune interruption hrtimer dans le délai limite de verrouillage dur.
Panique du noyau - pas de synchronisation : hung_task : tâches bloquées Le chien de garde des tâches suspendues a détecté au moins une tâche qui a été dans un état ininterruptible pendant une durée supérieure à la valeur de délai d'expiration des tâches bloquées.
Panique du noyau - pas de synchronisation : hors mémoire. panic_on_oom est sélectionné Le système est à court de mémoire et de swap et a été obligé de commencer à terminer les processus pour libérer de la mémoire (ce n'est pas le comportement par défaut).
Panique du noyau - pas de synchronisation : hors mémoire et aucun processus tuable... Le système a épuisé la mémoire et l'espace d'échange et a terminé des processus pour libérer de la mémoire, mais a épuisé les processus à terminer.
Panique du noyau - pas de synchronisation : une NMI s’est produite, consultez le journal de gestion intégré pour plus d’informations. Watchdog a intercepté une NMI (interruption non masquable).
Panique du noyau - non synchronisation : erreur NMI IOCK : Ne continue pas Le système a reçu un signal NMI de vérification d'E/S du matériel (et non une erreur de parité de mémoire) et kernel.panic_on_io_nmi a été activé (ce qui n'est pas la configuration par défaut).
Panique du noyau - pas de synchronisation : NMI : Ne pas continuer Le système a reçu une NMI (erreur de parité matérielle ou de mémoire) et kernel.panic_on_unrecovered_nmi a été défini (et non la valeur par défaut).
Panique du noyau - arrêt de la synchronisation : nmi watchdog Le système a reçu une NMI, et soit kernel.panic_on_timeout, soit kernel.panic_on_oops a été défini (au lieu des valeurs par défaut).
Panique du noyau - ne se synchronise pas : erreur fatale de vérification de l'état de la machine Un événement d'exception de vérification de machine a été signalé pour une condition fatale.
Panique du noyau - pas de synchronisation : tentative de tuer init ! Le processus d’init est le premier processus à démarrer et ne doit jamais se terminer.
Panique du noyau - pas de synchronisation : VFS : Impossible de monter la racine fs sur unknown-block(0,0) Il est supposé que le noyau utilisera un initramfs pour monter les rootfs. Cette erreur se produit lorsque le noyau n’a pas d’initramfs.

Scénario 1 : Un kernel panic se produit au démarrage

Une panique du noyau au moment du démarrage empêche la machine virtuelle de terminer le processus de démarrage du système d’exploitation. Il se produit chaque fois que la machine virtuelle est démarrée et qu’elle n’autorise pas la connexion.

Ce type d’événement est généralement lié, mais pas limité à :

Résolution du scénario 1

Pour traiter ce type de kernel panic, les approches suivantes peuvent être utilisées :

Méthode 1 : Utilisation de la console série Azure

Utilisez la console série Azure pour interrompre le processus de démarrage et sélectionner une version précédente du noyau, le cas échéant. De cette façon, la machine virtuelle sera en mesure de démarrer à nouveau, puis vous pouvez utiliser l’une des méthodes suivantes pour résoudre le problème spécifique avec le noyau qui ne démarre pas :

Méthode 2 : Réparation hors connexion à l’aide d’une machine virtuelle de secours

Si la console série Azure n'est pas disponible ou qu'aucun noyau précédent n'est disponible, vous avez besoin d'une machine virtuelle de secours/réparation pour effectuer une réparation hors connexion.

Utilisez la commande Réparer la machine virtuelle pour créer une machine virtuelle de réparation qui a une copie du disque du système d’exploitation de la machine virtuelle cible attachée. Utilisez ensuite chroot monter la copie des systèmes de fichiers du système d’exploitation dans la machine virtuelle de réparation. Ensuite, essayez les méthodes suivantes pour résoudre les problèmes de noyau :

Scénario 2 : Panique du noyau au moment de l’exécution

Ce type de panique du noyau se déclenche généralement à des moments imprévisibles une fois le processus de démarrage du système d’exploitation terminé et provoque l’arrêt de la réponse de la machine virtuelle, ce qui l’empêche de se connecter. Il est généralement lié, mais pas limité à :

Résolution du scénario 2

Pour traiter ce type de panique du noyau, les approches suivantes peuvent être utilisées :

  • Passez en revue l’utilisation des ressources et les performances globales du système. La panique du noyau peut être liée à une pénurie possible de ressources susceptibles d’entraîner un redimensionnement d’une machine virtuelle.
  • Si possible, installez les dernières mises à jour disponibles dans les référentiels de distribution Linux correspondants. La panique du noyau peut être liée à des bogues connus dans le noyau ou d’autres logiciels.
  • Il est possible que la panique du noyau soit liée à une modification récente du noyau, auquel cas il est également conseillé de démarrer sur une version précédente du noyau, comme expliqué dans Résolution pour le scénario 1.
  • Si les options ci-dessus ne s'appliquent pas, il peut être nécessaire de configurer kdump et de générer un vidage de noyau à partager avec le support pour une analyse plus poussée.

Scénarios de panique de noyau plus spécifiques

Scénarios de panique de noyau courants avec des instructions de dépannage/récupération spécifiques :

Document Scénario
Une machine virtuelle Linux sur Azure subit une panique du noyau basée sur la version 3.10 après la mise à niveau d'un nœud hôte Cet article décrit un problème qui se produit lorsqu'une machine virtuelle Linux Azure qui exécute le noyau 3.10 se bloque après une mise à niveau d'un nœud hôte dans Azure.
Comment récupérer une machine virtuelle Linux Azure après des problèmes de démarrage liés au noyau Cet article fournit des solutions à un problème dans lequel une machine virtuelle Linux ne peut pas redémarrer après l’application des modifications du noyau.
  • Last updated on