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

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…