Le point commun de toute plateforme exploitée sous Linux, serveur, poste de travail, matériel embarqué, est sans aucun doute le noyau Linux.

Les tests ou la mise en œuvre de telles plateformes conduisent souvent à des messages plus ou moins compréhensibles du noyau tels que des oops, voire des situations de blocage total (panic) du noyau.

La formation au debug kernel propose d'explorer avec le participant les interfaces de communication avec le noyau et comment appréhender les messages reçus.

Elle propose également des outils et des méthodes pour collecter les informations nécessaire à la dernière phase qui consiste en l'analyse du problème rencontré.

Le ou la participant·e est alors capable soit de corriger le dysfonctionnement soit de transmettre l'ensemble de ces informations au niveau compétent en faisant ainsi gagner du temps sur cette phase d'analyse.

Nos formateur·rice·s disposent de toute l'expérience pratique nécessaire, acquise lors de projets chez un éditeur de distribution mais aussi de par leurs contributions au kernel upstream.

Covid-19: Nous restons ouverts. Nos formations sont disponibles à distance.

Les objectifs

• Connaître les sources d'information relatives au fonctionnement du noyau Linux.
• Savoir collecter de manière exhaustive les informations liées à un dysfonctionnement du noyau.
• Savoir analyser les informations recueillies.

Pré-requis

• Connaissance du système Linux
• Programmation C
• Ordinateur portable sous Linux à apporter

Le programme de la formation Debug Kernel

Jour 1 : Prise en main du noyau et ses outils

• Connaître les différents systèmes de fichiers disponibles pour le debug
  • Systèmes de fichiers virtuels procfs, sysfs, debugfs
  • Stocker des informations de manière persistante avec pstore
    
• Debug user space
  • Récupérer un core dump
  • Utiliser gdb, Détecter des head corruption avec head et alloc
• Erreurs Kernel et dialogue avec le noyau :
  • backtrace
  • warn
  • Kernel tainted,
  • liste des flags,
  • oops
  • panic
  • bug
• Configurer son kernel pour améliorer le débug
  • Informations de debug
  • Activer kdump et kexec
  • Configurer les spin lock, mutex et bien utiliser les locks
  • Options de configurations liées à l'affichage de messages

Jour 2

• Les outils de debug kernel
  • system.map
  • Mettre en place une console série
  • Mise en place d'une netconsole
  • Utiliser qemu pour debugger
  • kgdb (port série)
  • crash / dump
  • De l'importance de l'appareil photo
  • Tracing avec ftrace
  • Quelques paramètres kernel utiles à connaître *Analyser les informations recueillies
  • Identifier les adresses mémoires avec addr2line
  • gdb
  • Un outil d'analyse dédié aux dumps kernel : crash
  • Outil d'aide à l'analyse : printk
  • Définir un format de message avec pr_*
  • Ajouter les noms de driver et devices aux messages avec dev_*
  • printk versus dev_* ?

Le(s) formateur(s)

Arnaud Patard

Arnaud est passionné de logiciels libres depuis des années. Il a travaillé plusieurs années chez Mandriva où il faisait partie de l'équipe des mainteneurs noyau. Il a également travaillé sur le port de la distribution sur architecture MIPC. Il contribue également à Débian, et notamment à l'équipe ARM.

Il passe également beaucoup de temps à suivre les sujets d'intégration d'infrastructures et notamment les outils relatifs à la centralisation de administration comme Puppet et Ansible, adossés à git.

Voir son profil détaillé

Suivi de formation en option

A l'issue de la formation, nos formateurs peuvent aussi intervenir pour vous accompagner dans la mise en application des compétences acquises :

• en répondant à vos questions lors de rendez-vous téléphoniques réguliers
• en étant présents physiquement à l'amorce du projet
• en réalisant un audit de vos pratiques quelques semaines/mois après la formation

Cette idée vous intéresse ? Faîtes-le nous savoir pour que nous trouvions la formule adaptée à votre situation.