Panique du noyau dans les machines virtuelles Linux Azure
S’applique à : ✔️ Machines virtuelles Linux
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 panneau diagnostics de démarrage, le panneau de la console série ou l’interface CLI AZ pour identifier la chaîne de panique du noyau spécifique.
Une panique du noyau ressemble à la sortie ci-dessous et s’affiche à 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 de noyau les plus courants :
| Message de panique | Motif |
|---|---|
| Oops : 0000 [#1] SMP » (vérifiez le 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 principal a été initié par l’utilisateur avec sysrq-c ou en échoant 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 ayant échoué (qui est tout comme une ASSERTION, mais la logique est inversée). Le nom de fichier et le numéro de ligne indiquent l’échec de la vérification DU BOGUE. |
| Panique du noyau - pas de synchronisation : softlockup : tâches bloquées | Le détecteur de verrouillage logiciel a trouvé un processeur qui n’a pas planifié la tâche de surveillance dans le seuil de 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 trouvé un processeur qui n’a reçu aucune interruption hrtimer dans le seuil de verrouillage dur. |
| Panique du noyau - pas de synchronisation : hung_task : tâches bloquées | L’observateur de tâche suspendu a détecté au moins une tâche qui a été dans un état ininterruptible pour plus que la valeur de délai d’expiration de tâche bloquée. |
| Panique du noyau - pas de synchronisation : hors mémoire. panic_on_oom est sélectionné | Le système a dépassé la mémoire et l’échange et a été obligé de commencer à tuer les processus pour libérer de la mémoire (pas le comportement par défaut). |
| Panique du noyau - pas de synchronisation : hors mémoire et aucun processus tuable... | Le système a dépassé la mémoire et l’échange et a tué des processus pour libérer de la mémoire, mais a dépassé les processus pour tuer. |
| 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 - pas de synchronisation : erreur NMI IOCK : Pas continuer | Le système a reçu une NMI de vérification d’E/S à partir du matériel (et non une erreur de parité de mémoire) et kernel.panic_on_io_nmi a été défini (et non la valeur 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 - pas de synchronisation : nmi watchdog | Le système a reçu une NMI, et kernel.panic_on_timeout ou kernel.panic_on_oops a été défini (et non les valeurs par défaut). |
| Panique du noyau - pas de synchronisation : vérification irrécupérable de la machine | Un événement d’exception de vérification de machine a été déclenché pour une condition irrécupérable. |
| Panique du noyau - pas de synchronisation : tentative de tuer init ! | Le processus d’init est le premier processus à démarrer et ne doit jamais quitter. |
| 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 : La panique du noyau se produit au moment du 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é à :
- Mise à niveau récente du noyau.
- Rétrogradation récente du noyau.
- Modifications du module noyau.
- Modifications de configuration du système d’exploitation (GRUB, sysctl et SELinux).
- Problèmes SELinux.
- Fichiers et répertoires importants manquants.
- Bibliothèques et packages principaux système manquants.
- Autorisations incorrectes sur les fichiers.
- Partitions manquantes.
Résolution du scénario 1
Pour traiter ce type de panique du noyau, 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 :
- Réinstallez ou régénérez un initramfs manquant.
- Réinstallez le noyau problématique.
- Passez en revue les modules de noyau chargés ou manquants.
- Passez en revue les partitions.
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 :
- Réinstallez ou régénérez un initramfs manquant.
- Réinstallez le noyau problématique.
- Passez en revue les modules de noyau chargés ou manquants.
- Passez en revue les partitions.
- Récupérer les fichiers manquants.
- Récupérez les bibliothèques et packages principaux système manquants.
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é à :
- Mise à niveau récente du noyau.
- Rétrogradation récente du noyau.
- Modifications du module noyau.
- Modifications de configuration du système d’exploitation (GRUB, sysctl et SELinux).
- Problèmes SELinux.
- Modifications de charge de travail d’application.
- Modifications ou bogues du développement d’applications.
- Bogues de noyau possibles.
- Problèmes liés aux performances.
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 principal à partager avec prise en charge d’une analyse plus approfondie.
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 Azure sur un noyau 3.10 panique 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 exécutant 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 suite à 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. |
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.