Kernel Panic sous Linux : causes, diagnostic et solutions

Un Kernel Panic est l’une des erreurs les plus critiques que peut rencontrer un système Linux. Il se produit lorsque le noyau détecte une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement. Le système peut alors se figer complètement, afficher une série de messages techniques ou redémarrer automatiquement.

Les causes sont nombreuses : pilote ou module noyau défectueux, mise à jour du kernel, mémoire RAM instable, problème CPU, carte graphique, SSD ou disque défaillant, système de fichiers corrompu ou erreur lors du démarrage.

Identifier l’origine d’un Kernel Panic nécessite donc d’examiner les messages du noyau et les événements ayant précédé le plantage. Des outils comme journalctl, dmesg, lsmod ou kdump permettent de récupérer des informations précieuses et d’orienter le diagnostic vers un problème logiciel ou matériel.

Dans ce guide, découvrez comment diagnostiquer un Kernel Panic sous Linux, récupérer et analyser les journaux, identifier un pilote ou module responsable, vérifier le matériel et réparer un système qui ne démarre plus après le plantage.

Qu’est-ce qu’un Kernel Panic sous Linux ?

Un Kernel Panic est une erreur critique du noyau Linux qui se produit lorsque celui-ci rencontre une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement.

Le noyau (kernel) constitue le cœur du système Linux. Il assure notamment la communication avec le matériel, la gestion de la mémoire, des processus, des pilotes et des systèmes de fichiers. Lorsqu’une erreur irrécupérable survient à ce niveau, poursuivre l’exécution pourrait provoquer une corruption des données ou aggraver le problème. Le noyau peut alors déclencher volontairement un panic et arrêter le système.

Selon la configuration de Linux, le PC peut alors :

• Se figer complètement avec un message d’erreur à l’écran.
• Afficher une série d’informations techniques et une Call Trace.
• Redémarrer automatiquement après quelques secondes.
• Rester bloqué jusqu’à un redémarrage manuel.

Un Kernel Panic est donc différent du simple plantage d’une application. Si Firefox, un jeu ou un autre programme se ferme brutalement, le noyau Linux continue généralement de fonctionner. Lors d’un Kernel Panic, c’est au contraire le fonctionnement du système lui-même qui est compromis.

Kernel Panic, Kernel Oops ou blocage : quelles différences ?

Tous les problèmes graves de Linux ne correspondent pas nécessairement à un Kernel Panic.

Un Kernel Oops indique qu’une erreur a été détectée dans le noyau. Linux enregistre des informations techniques sur l’incident et peut parfois continuer à fonctionner, même si le système peut ensuite devenir instable.

Un Kernel Panic est plus grave : le noyau considère qu’il n’est plus possible de poursuivre l’exécution de manière sûre.

Enfin, un freeze ou blocage de Linux peut avoir de nombreuses autres origines : pilote graphique bloqué, manque de mémoire, problème matériel, stockage défaillant ou processus qui monopolise certaines ressources. Un écran figé ne signifie donc pas automatiquement qu’un Kernel Panic s’est produit.

Les messages affichés à l’écran ou enregistrés dans les journaux sont essentiels pour faire la différence. Des termes comme Kernel panic, Oops, BUG, Call Trace ou le nom d’un module noyau constituent alors des indices importants.

Dans la suite de ce guide, nous allons voir quelles sont les principales causes d’un Kernel Panic et comment récupérer ces informations afin d’identifier son origine.

Quelles sont les causes d’un Kernel Panic ?

Un Kernel Panic peut avoir une origine logicielle ou matérielle. Un pilote défectueux, un problème de mémoire RAM, une erreur de stockage ou encore une mise à jour du noyau peuvent provoquer une erreur suffisamment grave pour empêcher Linux de continuer à fonctionner normalement.

Voici les causes les plus courantes :

Cause	Exemples	Indices possibles
Pilote ou module noyau	Pilote graphique, Wi-Fi, stockage, module tiers	Nom d’un module dans la Call Trace, panic après une mise à jour
Mémoire RAM instable	Barrette défectueuse, XMP/EXPO instable, timings incorrects	Erreurs aléatoires, panic différents, corruption mémoire
Processeur instable	Overclocking, undervolting, température excessive	Plantages sous forte charge, erreurs matérielles
Carte graphique / pilote GPU	Pilote NVIDIA/AMD, module noyau graphique	Écran noir, blocage graphique, module GPU cité dans les journaux
SSD ou disque dur	Erreurs d’E/S, SSD défaillant, contrôleur de stockage	I/O error, erreurs NVMe/SATA, système de fichiers inaccessible
Système de fichiers	Corruption ext4, Btrfs, XFS…	Erreurs de montage, corruption ou erreurs de lecture
Noyau Linux	Régression ou bug après une mise à jour	Problème apparu avec une nouvelle version du kernel
Initramfs / démarrage	Image initramfs endommagée, pilote de stockage manquant	Kernel Panic principalement au démarrage
Matériel ou firmware	BIOS/UEFI, carte mère, alimentation, périphérique PCIe	Erreurs matérielles, comportement instable ou aléatoire

Pilote ou module du noyau défectueux

Les pilotes et modules du noyau sont une cause importante de Kernel Panic puisqu’ils s’exécutent directement dans l’espace noyau.

Un problème peut apparaître après la mise à jour d’un pilote graphique, l’installation d’un module tiers ou le passage à une nouvelle version du noyau Linux. Les pilotes NVIDIA, les modules DKMS ou certains pilotes de périphériques constituent par exemple des éléments à vérifier lorsqu’un Kernel Panic apparaît après une modification du système.

Le nom du module impliqué peut parfois apparaître dans la Call Trace ou dans les messages enregistrés avant le plantage.

Problème matériel ou instabilité du PC

Un Kernel Panic peut également être la conséquence d’une instabilité matérielle. La mémoire RAM est notamment à surveiller : une barrette défectueuse ou des paramètres XMP/EXPO trop agressifs peuvent provoquer des corruptions mémoire qui finissent par faire planter le noyau.

Le processeur peut également devenir instable à cause d’un overclocking, d’un undervolting trop important ou, dans certains cas, de températures excessives.

Si les Kernel Panic sont aléatoires, impliquent des modules différents ou apparaissent principalement sous forte charge, il est pertinent d’élargir le diagnostic au matériel.

Les guides complets :

• Diagnostiquer le matériel sous Linux en ligne de commandes
• Tester et faire un diagnostic matériel de son PC sur Ubuntu

Stockage et système de fichiers

Un SSD ou un disque dur défaillant peut provoquer des erreurs d’entrée/sortie (I/O) qui empêchent le noyau d’accéder correctement aux données nécessaires au fonctionnement du système.

Une corruption du système de fichiers peut également entraîner des problèmes graves, notamment lorsque la partition système devient inaccessible.

Des messages contenant I/O error, EXT4-fs error, BTRFS error, nvme ou encore des erreurs SATA constituent alors des pistes à examiner.

Mise à jour ou régression du noyau Linux

Enfin, un Kernel Panic peut apparaître après une mise à jour du noyau. Une nouvelle version peut introduire une régression ou révéler une incompatibilité avec un pilote ou un périphérique particulier.

Un indice particulièrement intéressant est donc la date d’apparition du problème. Si Linux fonctionnait normalement avant une mise à jour du kernel et que les Kernel Panic ont commencé immédiatement après, démarrer temporairement sur l’ancien noyau depuis GRUB constitue un excellent test.

L’identification de la cause repose toutefois rarement sur le seul message « Kernel Panic ». Il faut récupérer les journaux du noyau et les informations affichées au moment du plantage pour déterminer quel pilote, composant ou sous-système est réellement impliqué.

Comment récupérer les informations après un Kernel Panic ?

Pour déterminer l’origine d’un Kernel Panic, il faut récupérer les messages enregistrés par le noyau avant le plantage. Ils peuvent contenir le nom d’un pilote ou d’un module, une erreur mémoire, une erreur d’entrée/sortie ou encore une Call Trace permettant d’orienter le diagnostic.

Lorsque Linux a redémarré, journalctl est généralement le premier outil à utiliser.

Consulter les messages du noyau du démarrage précédent

Sur une distribution utilisant systemd, exécutez :

journalctl -k -b -1

L’option -k limite l’affichage aux messages du noyau, tandis que -b -1 demande les journaux correspondant au démarrage précédent.

Vous pouvez également afficher uniquement les erreurs :

journalctl -k -b -1 -p err

Recherchez notamment des termes comme :

panic
Oops
BUG
Call Trace
segfault
I/O error
MCE
EDAC
nvme
ext4
btrfs

Il est souvent utile d’examiner également les dernières lignes précédant le plantage, car l’erreur ayant déclenché le Kernel Panic peut apparaître avant le message final.

Vérifier les démarrages disponibles

Pour connaître les journaux de démarrage encore disponibles :

journalctl --list-boots

Vous obtenez une liste permettant d’identifier le démarrage actuel (0) et les précédents (-1, -2, etc.).

Vous pouvez ensuite consulter un démarrage particulier, par exemple :

journalctl -k -b -2

Cette méthode est particulièrement pratique lorsque le PC a déjà été redémarré plusieurs fois depuis le Kernel Panic.

Consulter les messages avec dmesg

La commande dmesg affiche les messages du tampon du noyau :

dmesg -T

Vous pouvez filtrer les erreurs avec, par exemple :

dmesg -T | grep -Ei "error|fail|panic|oops|bug|mce|edac|nvme|i/o"

dmesg est surtout utile pour examiner le démarrage et la session en cours. Après un redémarrage consécutif à un Kernel Panic, journalctl -k -b -1 est généralement plus intéressant pour retrouver les événements du système précédent.

Que faire si le journal du démarrage précédent est vide ?

Les journaux ne sont pas toujours conservés après un redémarrage. Vous pouvez vérifier si les anciens boots sont disponibles avec :

journalctl --list-boots

Si seul le démarrage actuel apparaît, la journalisation persistante n’est probablement pas disponible ou les anciens journaux ont déjà été supprimés.

Dans ce cas, il peut être nécessaire de configurer la conservation persistante du journal systemd avant de reproduire le problème.

Il faut également garder à l’esprit qu’un Kernel Panic particulièrement brutal peut empêcher Linux d’écrire les derniers messages sur le disque. Le journal peut alors s’interrompre juste avant l’information la plus intéressante.

Pour les plantages difficiles à reproduire ou lorsque les journaux classiques ne suffisent pas, des mécanismes plus avancés comme kdump permettent de conserver un vidage mémoire du noyau afin d’effectuer une analyse plus approfondie.

Une fois les messages récupérés, l’étape suivante consiste à identifier les lignes réellement importantes dans le Kernel Panic et à interpréter la Call Trace.

Vérifier si un pilote ou module noyau est responsable

Les pilotes et modules du noyau sont une cause fréquente de Kernel Panic, car ils s’exécutent directement dans l’espace noyau. Un module défectueux, incompatible avec une nouvelle version du kernel ou mal compilé peut provoquer une erreur critique du système.

La première étape consiste à rechercher si un nom de module revient dans les journaux ou dans la Call Trace du Kernel Panic.

Vous pouvez par exemple filtrer les messages du démarrage précédent avec :

journalctl -k -b -1 | grep -Ei "module|driver|oops|bug|call trace|taint"

Si un nom de module apparaît régulièrement juste avant le plantage, notez-le pour poursuivre les vérifications.

Lister les modules noyau chargés

La commande suivante affiche les modules actuellement chargés :

lsmod

Vous pouvez rechercher un module précis avec :

lsmod | grep nom_module

Pour obtenir davantage d’informations :

modinfo nom_module

modinfo peut notamment afficher :

• Le chemin du module.
• Sa version.
• Son auteur.
• Les dépendances.
• Les paramètres disponibles.
• La version du noyau pour laquelle il a été compilé selon le module.

Ces informations sont utiles lorsqu’un pilote tiers ou un module DKMS est suspecté.

Vérifier les modules DKMS

Certains pilotes tiers sont reconstruits automatiquement à chaque mise à jour du noyau grâce à DKMS, notamment certains pilotes graphiques ou pilotes matériels additionnels.

Pour afficher les modules DKMS installés :

dkms status

Si un Kernel Panic apparaît juste après une mise à jour du noyau, vérifiez que les modules nécessaires ont bien été recompilés pour la nouvelle version et qu’aucune erreur DKMS n’est présente.

Vous pouvez aussi comparer la version du noyau actuellement utilisée :

uname -r

avec les informations retournées par modinfo.

Rechercher les erreurs liées à un pilote précis

Si vous connaissez le nom du module suspect, filtrez directement les journaux :

journalctl -k -b -1 | grep -i nom_module

ou, pour la session en cours :

dmesg -T | grep -i nom_module

Recherchez notamment des messages indiquant :

• Une erreur d’initialisation.
• Un timeout.
• Une erreur PCIe.
• Un crash ou un BUG.
• Une erreur de mémoire.
• Un module marqué comme tainted.
• Un échec de chargement du firmware.

Désactiver temporairement un module pour confirmer le diagnostic

Si un module non essentiel semble responsable, vous pouvez tenter de le désactiver temporairement afin de vérifier si les Kernel Panic disparaissent.

Pour retirer un module chargé :

sudo modprobe -r nom_module

Cette commande ne fonctionne que si le module n’est pas utilisé par un périphérique ou un autre module.

Pour empêcher son chargement au prochain démarrage, il est également possible de le placer temporairement dans une blacklist modprobe. Cette méthode doit toutefois être utilisée avec prudence : bloquer un pilote graphique, réseau ou de stockage indispensable peut empêcher le système de fonctionner correctement.

L’objectif n’est donc pas de désactiver au hasard les modules présents dans la Call Trace, mais de vérifier si le même pilote revient systématiquement dans plusieurs Kernel Panic.

Le tutoriel :

Utiliser modprobe et configurer /etc/modprobe.d/

Vérifier les changements récents

Si le problème est apparu récemment, demandez-vous ce qui a changé juste avant :

• Mise à jour du noyau Linux.
• Mise à jour du pilote NVIDIA ou AMD.
• Installation d’un nouveau module DKMS.
• Mise à jour du BIOS/UEFI.
• Ajout d’un périphérique PCIe, USB ou de stockage.
• Modification d’un paramètre du kernel ou du démarrage.

Lorsqu’un Kernel Panic apparaît juste après une mise à jour du noyau, un test très efficace consiste à redémarrer sur l’ancienne version du kernel depuis GRUB. Si les plantages disparaissent, cela renforce fortement l’hypothèse d’une régression du noyau ou d’une incompatibilité avec un pilote/module.

Enfin, gardez à l’esprit qu’un module cité dans une Call Trace n’est pas automatiquement le responsable. Une corruption mémoire ou une instabilité matérielle peut provoquer le crash d’un pilote parfaitement sain. Il faut donc toujours croiser cette piste avec les autres symptômes et les tests matériels.

Analyser un Kernel Panic avec kdump

Lorsque les journaux journalctl et dmesg ne permettent pas d’identifier l’origine d’un Kernel Panic, les utilisateurs avancés et administrateurs système peuvent utiliser kdump pour effectuer une analyse plus approfondie.

Kdump utilise kexec pour démarrer un second noyau, appelé noyau de capture, après le plantage. Une partie de la mémoire est réservée à l’avance afin que ce noyau puisse récupérer l’état mémoire du système qui vient de planter et l’enregistrer dans un fichier vmcore.

Le principe est le suivant : Kernel Panic → noyau de capture → création du vmcore → analyse du crash

Le fichier vmcore peut ensuite être analysé avec des outils spécialisés comme crash, en utilisant les symboles de débogage correspondant au noyau ayant planté. Cette analyse permet notamment d’examiner les messages du noyau, la pile d’appels, les processus et les modules présents au moment du crash.

La mise en place et surtout l’analyse d’un vmcore restent toutefois des opérations techniques destinées principalement aux administrateurs système et au débogage du noyau. Pour un PC personnel, commencez par journalctl, les messages du noyau, la vérification des pilotes/modules et le diagnostic matériel.

Pour configurer kdump ou analyser un crash en profondeur, consultez la documentation officielle : Documentation officielle de kdump — Linux Kernel

Pour l’analyse d’un vmcore avec l’utilitaire crash, la documentation Red Hat fournit également une procédure détaillée : Analyser un core dump avec crash — Red Hat

Que faire si Linux ne démarre plus après un Kernel Panic ?

Si Linux ne démarre plus après un Kernel Panic, le problème peut venir du noyau récemment installé, d’un pilote/module incompatible, de l’initramfs, du système de fichiers ou d’un problème matériel.

L’objectif est d’abord de retrouver un système démarrable, puis d’analyser ce qui a changé juste avant l’apparition du problème.

Démarrer sur un ancien noyau depuis GRUB

Si les Kernel Panic ont commencé après une mise à jour du noyau, essayez en priorité de démarrer sur une version précédente.

Depuis le menu GRUB :

• Ouvrez Options avancées pour Ubuntu/Debian ou l’entrée équivalente de votre distribution.
• Sélectionnez un ancien noyau Linux.
• Démarrez normalement.

Si le système démarre correctement avec l’ancien kernel, cela oriente fortement vers une régression du noyau ou un problème de pilote/module compatible uniquement avec certaines versions.

Vous pouvez vérifier la version utilisée avec :

uname -r

Utiliser le mode de récupération

Si un ancien noyau ne suffit pas, essayez le mode Recovery / dépannage proposé dans GRUB.

Selon la distribution, ce mode permet notamment de :

• Ouvrir un shell root.
• Vérifier le système de fichiers.
• Réparer certains paquets.
• Recréer l’initramfs.
• Désactiver temporairement un pilote ou module problématique.

Il peut être utile lorsque le Kernel Panic survient très tôt pendant le démarrage.

Vérifier ou reconstruire l’initramfs

Un initramfs endommagé ou incomplet peut empêcher le noyau de charger les pilotes nécessaires au démarrage, notamment ceux liés au stockage.

Sur Debian/Ubuntu, vous pouvez reconstruire l’initramfs avec :

sudo update-initramfs -u -k all

Puis mettre à jour GRUB :

sudo update-grub

Sur d’autres distributions, la commande peut différer, par exemple avec dracut.

Démarrer depuis un Live USB

Si aucun noyau installé ne permet de démarrer, utilisez un Live USB Linux.

Depuis le système Live, vous pouvez :

• Accéder aux fichiers importants et effectuer une sauvegarde.
• Monter la partition Linux.
• Vérifier le système de fichiers.
• Examiner les journaux présents sur le disque.
• Réparer le chargeur d’amorçage.
• Réinstaller un noyau ou reconstruire l’initramfs.

C’est également une bonne méthode pour déterminer si le problème vient du système installé ou d’une panne matérielle plus générale.

Vérifier le système de fichiers et le stockage

Si le Kernel Panic est associé à des erreurs de lecture, de montage ou d’entrée/sortie, vérifiez le stockage avant d’insister sur les réparations logicielles.

Vous pouvez rechercher des erreurs dans les journaux avec des termes comme :

I/O error
EXT4-fs error
BTRFS error
nvme
ata
Buffer I/O error

Un système de fichiers endommagé peut parfois être réparé avec fsck, à condition de ne pas lancer la vérification sur une partition montée en écriture.

Profitez également du Live USB pour vérifier l’état SMART du SSD ou du disque si une défaillance matérielle est suspectée.

Le guide :

Vérifier la santé de son disque dur sur Linux

Désactiver temporairement un module problématique

Si les journaux ou la Call Trace pointent régulièrement vers un module noyau précis, il peut être utile de désactiver temporairement ce module afin de vérifier si Linux démarre à nouveau.

Cette opération est surtout pertinente pour les pilotes graphiques, Wi-Fi ou modules tiers. Évitez toutefois de blacklister au hasard un pilote lié au stockage ou à un composant indispensable au démarrage.

En dernier recours : sauvegarder puis réparer ou réinstaller

Si Linux reste impossible à démarrer malgré un ancien noyau, la reconstruction de l’initramfs et la vérification du stockage, sauvegardez d’abord vos données depuis un Live USB.

Vous pourrez ensuite tenter une réparation plus complète du système ou, si la corruption est importante, procéder à une réinstallation.

Avant d’en arriver là, vérifiez cependant que le problème n’est pas matériel. Des Kernel Panic répétés avec des messages différents peuvent être provoqués par une RAM instable, un SSD défaillant, un CPU instable ou un autre composant matériel.

Le guide complet :

Diagnostiquer le matériel sous Linux en ligne de commandes

Les messages de Kernel Panic les plus courants

Kernel panic – not syncing: VFS: Unable to mount root fs

C’est le cas incontournable. Le noyau a démarré, mais n’arrive pas à monter le système de fichiers racine (/). Les pistes typiques sont :

• initramfs absent, endommagé ou incorrect ;
• pilote du contrôleur de stockage ou du système de fichiers absent de l’initramfs ;
• mauvais paramètre root= transmis au noyau ;
• UUID de partition incorrect ;
• problème après une mise à jour du noyau ;
• système de fichiers endommagé ;
• SSD/disque ou contrôleur de stockage défaillant.

Le guide dédié :

Kernel Panic “VFS: Unable to mount root fs” sous Linux : les solutions

Le guide Kernel Panic pourrait n’en donner qu’une explication de 200 mots + lien vers ce futur guide.

Kernel panic – not syncing: Attempted to kill init!

Le message Kernel panic - not syncing: Attempted to kill init! apparaît lorsque le processus init, généralement le processus PID 1, s’arrête ou rencontre une erreur qui l’empêche de poursuivre son fonctionnement.

Ce processus joue un rôle essentiel : il constitue le premier processus lancé en espace utilisateur et permet ensuite d’initialiser le reste du système. S’il disparaît, Linux ne peut normalement plus poursuivre son fonctionnement et déclenche un Kernel Panic.

Cette erreur peut notamment être liée à :

• Un initramfs endommagé ou incomplet.
• Un problème avec systemd ou le programme utilisé comme init.
• Une corruption du système de fichiers racine.
• Des bibliothèques ou fichiers système manquants ou corrompus.
• Une mise à jour interrompue ou défectueuse.
• Une erreur de mémoire ou une instabilité matérielle provoquant le crash du processus init.

Si le problème apparaît au démarrage, essayez d’abord de lancer un ancien noyau depuis GRUB ou le mode de récupération. Vous pouvez ensuite vérifier le système de fichiers, reconstruire l’initramfs et contrôler les fichiers système.

Il est également important d’examiner les lignes affichées juste avant Attempted to kill init! : ce message indique la conséquence finale du problème, mais pas nécessairement sa cause initiale.

Kernel panic – not syncing: Fatal exception

Le message Kernel panic - not syncing: Fatal exception indique qu’une exception suffisamment grave s’est produite dans le noyau pour empêcher Linux de poursuivre son fonctionnement en toute sécurité.

Contrairement à une erreur très spécifique comme VFS: Unable to mount root fs, le message Fatal exception ne permet généralement pas à lui seul d’identifier la cause.

Il faut donc examiner les informations qui le précèdent, notamment :

• La Call Trace.
• Le nom d’un pilote ou module noyau.
• Les éventuels messages Oops ou BUG.
• Le processus et le CPU concernés.
• Les erreurs mémoire ou matérielles précédant le panic.
• Les modules éventuellement indiqués comme chargés ou impliqués.

Une Fatal exception peut notamment provenir d’un bug du noyau, d’un pilote défectueux, d’un module tiers ou d’une corruption mémoire provoquée par une instabilité matérielle.

Après le redémarrage, consultez en priorité les messages du noyau du démarrage précédent :

journalctl -k -b -1

Si plusieurs Kernel Panic présentent des Call Trace différentes et impliquent des modules sans rapport entre eux, élargissez également les vérifications à la RAM, au processeur et au matériel.

Kernel Panic après une mise à jour du noyau

Si les Kernel Panic commencent immédiatement après une mise à jour du noyau Linux, la nouvelle version du kernel constitue une piste importante.

Le problème ne vient toutefois pas nécessairement du noyau lui-même. Une mise à jour peut également révéler une incompatibilité avec un pilote, un module DKMS, l’initramfs ou un périphérique matériel.

Le test le plus simple consiste à redémarrer le PC et à sélectionner l’ancienne version du noyau depuis les options avancées de GRUB.

Si Linux fonctionne normalement avec l’ancien kernel, vérifiez ensuite :

• Les éventuelles erreurs connues avec la nouvelle version du noyau.
• Les modules DKMS avec dkms status.
• Les pilotes graphiques ou autres pilotes tiers récemment mis à jour.
• La bonne génération de l’initramfs.
• Les journaux du démarrage ayant échoué.
• Les paramètres du noyau éventuellement modifiés.

Vous pouvez connaître le noyau actuellement utilisé avec :

uname -r

et afficher les noyaux disponibles dans /boot :

ls -lh /boot

Si l’ancien noyau fonctionne correctement, conservez-le temporairement comme solution de secours plutôt que de supprimer immédiatement les autres versions. Cela permet de continuer à utiliser Linux pendant que vous recherchez s’il s’agit d’une régression du kernel ou d’une incompatibilité avec un module.

Ressources utiles et articles liés

• Tester et faire un diagnostic matériel de son PC sur Ubuntu
• rasdaemon : surveiller et diagnostiquer les erreurs matérielles sous Linux
• Ubuntu : faire un memtest/diagnostic de la mémoire RAM
• Diagnostiquer les problèmes matériels : tester ses composants
• Stress test CPU, GPU, disque : tester la stabilité de votre ordinateur

L’article Kernel Panic sous Linux : causes, diagnostic et solutions est apparu en premier sur malekal.com.