Réagir à un kernel panic quand on est développeur

Magazine
Marque
GNU/Linux Magazine
Numéro
213
Mois de parution
mars 2018
Spécialité(s)


Résumé
Face à un kernel panic, la meilleure solution est-elle de faire l'autruche et de penser que le problème se résoudra de lui-même avec une mise à jour, ou vaut-il mieux sortir sa boîte à outils et profiter de notre système libre pour comprendre la situation ? Évidemment, nous allons explorer ici cette deuxième option…

Mes machines tournent toutes sur Debian, de stable à unstable, selon l'usage. Récemment, une machine sous unstable s'est vue proposée un passage au noyau 4.13. Mais lors du reboot suivant, échec critique : sitôt le noyau sélectionné dans Grub, un kernel panic recouvre l'écran et le boot échoue.

Un kernel panic peut être un symptôme d'un problème matériel, d'un pilote défaillant ou encore d'un bug. Eh oui, notre cher noyau a des bugs, comme tout logiciel d'une telle envergure (on parle de millions de lignes de code tout de même). Le noyau 4.12 continuant à tourner comme une horloge sur cette machine, et la configuration n'ayant pas été triturée au-delà du raisonnable, la probabilité d'un bug dans le noyau ou dans un pilote est assez élevée.

Nous allons donc devoir analyser ce kernel panic et nous lancer dans le code du noyau pour tenter de comprendre ce qui a échoué, pourquoi, et comment corriger pour que les futurs noyaux marchent à nouveau sur cette...

Cet article est réservé aux abonnés. Il vous reste 95% à découvrir.
S'abonner à Connect
  • Accédez à tous les contenus de Connect en illimité
  • Découvrez des listes de lecture et des contenus Premium
  • Consultez les nouveaux articles en avant-première
Je m'abonne


Article rédigé par

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous