Debian 13 Kdump : capture de crash — configurez et vérifiez que cela fonctionne (cas n°17)

Ce que vous construisez : kexec + un deuxième noyau + un chemin de dump

Kdump fonctionne en gardant un « noyau de crash » en réserve. Lorsque le noyau en cours fait un panic (ou que vous forcez un crash pour
les tests), le système ne redémarre pas à froid. À la place, il utilise kexec pour sauter directement dans le
noyau de crash, qui exécute un userspace minimal depuis un initramfs et écrit la mémoire sur disque ou réseau sous forme de vmcore.

L’exigence critique : le noyau de crash a besoin d’une RAM réservée que le noyau en panne ne doit jamais toucher.
C’est pourquoi vous définissez crashkernel= dans la ligne de commande du noyau. Si vous sautez cette étape, vous aurez un service kdump qui
« démarre » et un crash qui ne produit rien d’utile. C’est comme installer des sprinklers sans pression d’eau.

Deux clarifications rapides qui vous feront gagner des heures :

• Kdump ne corrige pas les crashs. Il transforme un crash en un artefact exploitable.
• Kdump n’est aussi bon que son chemin de dump. Si votre cible de dump dépend de l’élément qui est cassé, vous apprendrez l’humilité.

Faits et contexte qui comptent vraiment

1. Kdump est ancien selon les standards Linux. L’approche de dump basée sur kexec a mûri au milieu des années 2000 et est devenue un pilier des distributions d’entreprise.
2. « Deuxième noyau » est littéral. Kdump n’est pas une fonctionnalité de debug dans le même noyau ; il démarre un noyau séparé dans la mémoire réservée.
3. Les débuts de kdump concernaient surtout le diagnostic matériel. Il aidait les vendeurs à distinguer une RAM/PCIe défectueuse d’un bogue noyau sans deviner.
4. Les crash dumps ont alimenté de vrais travaux sur la fiabilité du noyau. Une fois que les équipes ops pouvaient fournir un vmcore aux développeurs, « impossible à reproduire » est devenu moins à la mode.
5. La compression est devenue essentielle avec la montée de la RAM. Un dump de 512 Mo était gênant en 2006 ; un dump de 512 Go est un événement contraignant pour une carrière.
6. NUMA et les grandes machines ont changé les règles de dimensionnement. Réserver 128 Mo suffisait autrefois ; sur le matériel moderne, le noyau de crash peut nécessiter plus pour charger les pilotes et écrire les dumps.
7. Secure Boot complique kexec dans certains environnements. Selon la politique, kexec peut être restreint ; vous devez valider dans le modèle de confiance de votre plateforme.
8. Initramfs est le véritable champ de bataille. La plupart des échecs kdump ne viennent pas de « kdump », mais de l’absence des pilotes de stockage/réseau dans l’initramfs de crash.
9. Systemd a rendu l’état du service kdump visible. Vous pouvez maintenant voir rapidement si le noyau de crash est chargé, plutôt que de vous fier au folklore.

Décisions de conception : où dumper, comment démarrer, quoi réserver

Choisissez une cible de dump qui survit à vos pannes probables

Vous avez généralement trois destinations de dump raisonnables :

• Système de fichiers local (rapide, simple) : bon si les disques restent accessibles pendant le crash et si le système de fichiers peut être monté dans le noyau de crash.
• Partition locale dédiée ou périphérique brut (sérieux, robuste) : moins de dépendance à votre userspace normal ; meilleures chances dans des piles de stockage compliquées.
• Réseau (généralement NFS) (meilleur si la pile disque peut être détruite) : évite la complexité du stockage local, mais le noyau de crash doit activer la carte réseau et la routage.

Si vous avez une pile de stockage complexe — LUKS sur LVM sur MD RAID sur multipath — votre chemin de dump sera la chose qui échoue.
Dans ce cas, une petite partition dédiée non chiffrée, ou une cible NFS, est le choix adulte.
Oui, cela signifie que vous planifiez votre propre défaillance. Bienvenue en SRE.

Dimensionnement du crashkernel : privilégiez « qui marche » plutôt que « minimal »

Sur les systèmes Debian modernes, réserver trop peu de mémoire provoque des échecs silencieux et stupides : le noyau de crash se charge,
puis ne peut pas initialiser les pilotes ou allouer des tampons pour écrire le dump. Ne cherchez pas à être malin.

Une règle empirique et pratique qui fonctionne généralement :

• Petites VM : 256M peut suffire.
• Serveurs généraux avec pilotes communs : 512M est une base sûre.
• Grosses machines, beaucoup de modules stockage/réseau, ou NUMA lourd : 768M–1024M.

Si vous ne pouvez pas vous passer de 512M de RAM en 2025, votre vrai problème est budgétaire, pas kdump.

Une citation à accrocher au-dessus du tableau de bord

L’espoir n’est pas une stratégie. — maxime courante en exploitation (idée paraphrasée, souvent attribuée dans les cercles de fiabilité)

Installer et activer kdump sur Debian 13

Le packaging de Debian peut évoluer entre les versions mineures, mais le schéma opérationnel reste cohérent :
installer les outils kdump, réserver la mémoire crashkernel, régénérer la configuration de démarrage/initramfs, assurer que le noyau de crash est chargé.

Tâche 1 — Confirmer le noyau, les outils initramfs et le chargeur de démarrage

cr0x@server:~$ uname -a
Linux server 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.3-1 (2025-09-10) x86_64 GNU/Linux

Ce que cela signifie : Vous exécutez un noyau Debian qui supporte kexec/kdump. Si vous êtes sur un noyau personnalisé,
validez qu’il est compilé avec le support de crash dump. Décision : continuez sauf si vous savez avoir supprimé les options kexec/crash.

cr0x@server:~$ ls -l /etc/kernel/cmdline /etc/default/grub 2>/dev/null || true
-rw-r--r-- 1 root root  112 Oct 12 10:03 /etc/default/grub

Ce que cela signifie : Cet hôte utilise probablement la configuration GRUB dans /etc/default/grub. Certaines installations Debian
utilisent /etc/kernel/cmdline avec des flux kernel-install. Décision : utilisez le fichier que votre système consomme réellement.

Tâche 2 — Installer les composants kdump

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y kdump-tools kexec-tools linux-image-amd64 makedumpfile
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  kdump-tools kexec-tools makedumpfile
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Setting up kexec-tools (1:2.0.28-1) ...
Setting up kdump-tools (1:1.8.0-2) ...
Setting up makedumpfile (1:1.7.6-2) ...

Ce que cela signifie : Vous avez maintenant les wrappers de service et les outils de dump. Décision : l’étape suivante est la réservation
crashkernel ; sans cela, kdump fera surtout semblant.

Tâche 3 — Vérifier si le service kdump est activé et ce qu’il indique

cr0x@server:~$ systemctl status kdump-tools --no-pager
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2025-12-30 09:12:01 UTC; 3min ago
       Docs: man:kdump-config(8)

Ce que cela signifie : « active (exited) » est normal ; le service charge le noyau de crash puis se met hors du chemin.
Décision : ne célébrez pas encore ; vous devez toujours confirmer que le noyau de crash est réellement chargé.

Blague n°1 : Kdump, c’est comme les sauvegardes — tout le monde « l’a » jusqu’au jour où on en a besoin et qu’on découvre qu’on collectionnait en réalité des ondes.

Réserver la mémoire crashkernel (et prouver qu’elle est réservée)

Tâche 4 — Inspecter la ligne de commande du noyau actuelle

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=0a1b2c3d-4e5f-6789-a012-3456789abcde ro quiet

Ce que cela signifie : Aucun paramètre crashkernel=. À l’heure actuelle, kdump ne peut probablement pas réserver de mémoire.
Décision : ajoutez crashkernel=512M (ou plus si vous avez un ensemble de pilotes complexe).

Tâche 5 — Définir crashkernel dans GRUB et régénérer la configuration

cr0x@server:~$ sudo sed -i 's/^\(GRUB_CMDLINE_LINUX_DEFAULT=".*\)"/\1 crashkernel=512M"/' /etc/default/grub

cr0x@server:~$ grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
6:GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=512M"

Ce que cela signifie : Crashkernel est maintenant configuré pour les prochains boots. Décision : mettez à jour GRUB et redémarrez à un moment contrôlé.

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done

Tâche 6 — Redémarrer et vérifier la mémoire réservée

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=0a1b2c3d-4e5f-6789-a012-3456789abcde ro quiet crashkernel=512M

cr0x@server:~$ dmesg | grep -i crashkernel | head -n 5
[    0.000000] Reserving 512MB of memory at 0x0000001f00000000 for crashkernel (System RAM: 32768MB)
[    0.000000] crashkernel reserved: 0x0000001f00000000 - 0x0000001f20000000 (512 MB)

Ce que cela signifie : La réservation est réelle. Si vous ne voyez pas des lignes similaires, vous n’avez pas kdump — juste des impressions.
Décision : si la réservation a échoué, augmentez la taille ou corrigez les paramètres du noyau en conflit (commun sur les petites VM ou avec des cartes mères étranges).

Tâche 7 — Confirmer que le noyau de crash kexec est chargé

cr0x@server:~$ sudo kdump-config show
DUMP_MODE:                kdump
USE_KDUMP:                1
KDUMP_SYSCTL:             kernel.panic_on_oops=1
KDUMP_COREDIR:            /var/crash
KDUMP_KERNELVER:          6.12.0-1-amd64
KEXEC:                    /sbin/kexec
crashkernel addr:         0x0000001f00000000
crashkernel size:         0x20000000

Ce que cela signifie : Les outils voient la région réservée. Décision : validez maintenant le chemin de dump et le contenu de l’initramfs de crash.

cr0x@server:~$ sudo kexec -p -s || true
kexec: no crash kernel loaded

Ce que cela signifie : Ce contrôle particulier ne dit rien. Certains systèmes chargent après le démarrage du service ou après configuration.
Décision : redémarrez kdump-tools et réessayez.

cr0x@server:~$ sudo systemctl restart kdump-tools

cr0x@server:~$ sudo kexec -p -s
kexec: crash kernel is loaded

Ce que cela signifie : Parfait. Votre noyau de crash est en place. Décision : passez à la configuration et validation de la cible de dump.

Configurer la cible de dump : disque local vs NFS (et pourquoi cela importe)

Disque local vers /var/crash : le plus simple quand le stockage est sain

Les valeurs par défaut Debian sont souvent « dump sous /var/crash ». C’est correct si :
votre système racine est montable depuis l’initramfs de crash et votre pile de stockage est simple.
Pour un ext4 mono-disque sur une VM, c’est généralement parfait.

Tâche 8 — Valider que vous avez de l’espace pour les dumps et que le système de fichiers peut les recevoir

cr0x@server:~$ df -h /var/crash
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        80G   22G   54G  29% /

Ce que cela signifie : Vous avez de l’espace. Un dump complet représente à peu près la taille de la RAM ; makedumpfile peut compresser/filtrer.
Décision : si l’espace libre est serré, dumpez vers un volume dédié ou NFS, et configurez filtrage/compression.

Tâche 9 — Examiner la configuration de kdump-tools (et définir compression/filtrage)

cr0x@server:~$ sudo sed -n '1,200p' /etc/default/kdump-tools
# kdump-tools configuration
USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
MAKEDUMPFILE_ARGS="-l --message-level 1 -d 31"
KDUMP_KERNELVER=""

Ce que cela signifie : MAKEDUMPFILE_ARGS contrôle la quantité de pages que vous réduisez. -d 31 est un masque courant « drop lots of pages ».
Décision : conservez le filtrage sauf si vous avez un besoin de débogage pour des dumps complets et que vous pouvez les stocker.

Destination NFS : moins de pilotes de stockage, plus de plomberie réseau

NFS est mon choix par défaut lorsque la pile de stockage locale est complexe (LUKS-sur-tout, contrôleurs RAID exotiques, boot iSCSI).
Il déplace la dépendance de « peut-on monter le FS racine dans un monde cassé » vers « peut-on activer le réseau dans le noyau de crash ».
C’est généralement plus facile à rendre déterministe, surtout sur un VLAN fixe.

Tâche 10 — Configurer une cible de dump NFS (exemple)

Ceci est un style d’exemple de configuration. Vos clés de fichier exactes peuvent différer selon la révision du packaging Debian, mais l’exigence opérationnelle est stable : l’initramfs de crash doit savoir où écrire et comment y parvenir.

cr0x@server:~$ sudo grep -R "KDUMP_" -n /etc/default/kdump-tools
2:USE_KDUMP=1
3:KDUMP_COREDIR="/var/crash"

Pour NFS vous définissez typiquement le répertoire de dump vers un chemin monté NFS disponible dans l’environnement de crash.
Une approche courante consiste à configurer des scripts kdump pour monter NFS pendant le crash. Sur Debian, ce comportement est géré par les hooks de l’initramfs kdump.
Vous devez le tester.

Exemple : créez un point de montage et une entrée fstab pour la visibilité quotidienne, puis assurez-vous que l’initramfs de crash contient aussi ce dont il a besoin.
(Ne supposez pas que l’initramfs de crash utilise vos montages normaux. C’est un petit monde séparé.)

cr0x@server:~$ sudo mkdir -p /mnt/kdump-nfs

cr0x@server:~$ echo '10.10.20.50:/exports/kdump /mnt/kdump-nfs nfs4 _netdev,nofail,ro 0 0' | sudo tee -a /etc/fstab
10.10.20.50:/exports/kdump /mnt/kdump-nfs nfs4 _netdev,nofail,ro 0 0

cr0x@server:~$ sudo mount -a

cr0x@server:~$ mount | grep kdump-nfs
10.10.20.50:/exports/kdump on /mnt/kdump-nfs type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21,local_lock=none,addr=10.10.20.50)

Ce que cela signifie : L’espace userspace normal peut atteindre l’export NFS. Décision : assurez-vous maintenant que l’initramfs de crash peut faire de même
(pilotes, configuration IP, route, composants client NFS).

cr0x@server:~$ sudo sed -i 's|^KDUMP_COREDIR=.*|KDUMP_COREDIR="/mnt/kdump-nfs"|g' /etc/default/kdump-tools

cr0x@server:~$ grep -n '^KDUMP_COREDIR' /etc/default/kdump-tools
3:KDUMP_COREDIR="/mnt/kdump-nfs"

Ce que cela signifie : Vous dirigez les dumps vers le point de montage NFS. Décision : reconstruisez l’initramfs kdump et validez que le noyau de crash se charge toujours.

Vérifier le noyau kdump et l’initramfs avant de provoquer un crash

La manière la plus rapide de passer pour un imbécile est de « tester kdump » en heures ouvrables sans vérifier que l’environnement de crash peut écrire un dump.
Traitez cela comme une migration : faites des dry-runs, prouvez que les éléments existent, puis effectuez le test disruptif avec un plan de retour arrière.

Tâche 11 — Rebuild de l’initramfs et redémarrage de kdump-tools

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

cr0x@server:~$ sudo systemctl restart kdump-tools

cr0x@server:~$ sudo kexec -p -s
kexec: crash kernel is loaded

Ce que cela signifie : Après des changements de config, le noyau de crash est toujours en place. Décision : validez ce que contient l’initramfs,
en particulier les modules de stockage et de NIC.

Tâche 12 — Inspecter l’initramfs kdump pour les modules critiques (stockage et réseau)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.12.0-1-amd64 | grep -E '(^lib/modules/.*/kernel/drivers/(net|block)|/sbin/makedumpfile|nfs|rpc)' | head -n 20
lib/modules/6.12.0-1-amd64/kernel/drivers/block/virtio_blk.ko
lib/modules/6.12.0-1-amd64/kernel/drivers/net/virtio_net.ko
sbin/makedumpfile
usr/sbin/ip
usr/sbin/ifconfig

Ce que cela signifie : Votre initramfs inclut au moins certains composants requis. L’absence de pilotes ici est la première raison
pour laquelle les dumps n’apparaissent jamais. Décision : si vous dépendez de ixgbe, bnx2, megaraid_sas, nvme,
dm_crypt, etc., confirmez leur présence.

Tâche 13 — S’assurer que les sysctls provoquent réellement un panic quand c’est nécessaire

cr0x@server:~$ sysctl kernel.panic kernel.panic_on_oops
kernel.panic = 0
kernel.panic_on_oops = 1

Ce que cela signifie : Le système paniquera sur un oops (souvent souhaitable pour capturer des dumps) mais ne redémarrera pas automatiquement après le panic.
Décision : en production, définissez kernel.panic=10 (ou similaire) pour que le noyau de crash ait le temps de dumper, puis redémarrer.
Si vous laissez à 0 indéfiniment, vous risquez un hôte mort nécessitant une intervention manuelle.

cr0x@server:~$ echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kdump-panic.conf
kernel.panic = 10

cr0x@server:~$ sudo sysctl --system | tail -n 5
* Applying /etc/sysctl.d/99-kdump-panic.conf ...
kernel.panic = 10

Tâche 14 — Confirmer que votre répertoire de dump est écrivable et stable

cr0x@server:~$ sudo test -d /mnt/kdump-nfs && sudo test -w /mnt/kdump-nfs && echo "ok: writable" || echo "not writable"
not writable

Ce que cela signifie : Dans cet exemple, le montage NFS était en lecture seule (ro dans fstab). C’est une auto-sabotage.
Décision : corrigez les options de montage ; votre cible de dump doit être évidemment écrivable.

cr0x@server:~$ sudo sed -i 's/_netdev,nofail,ro/_netdev,nofail,rw/' /etc/fstab

cr0x@server:~$ sudo mount -o remount,rw /mnt/kdump-nfs

cr0x@server:~$ sudo test -w /mnt/kdump-nfs && echo "ok: writable" || echo "not writable"
ok: writable

Ce que cela signifie : Votre cible est écrivable en userspace normal. Décision : ce n’est toujours pas suffisant — le noyau de crash doit aussi pouvoir le faire,
mais cela supprime un mode d’échec évident.

Tâche 15 — Dry-run de la permission d’écriture et du comportement de nommage

cr0x@server:~$ sudo sh -c 'd=/mnt/kdump-nfs/TEST-$(hostname)-$(date +%s); mkdir "$d" && echo hello > "$d"/marker.txt && ls -l "$d"'
total 4
-rw-r--r-- 1 root root 6 Dec 30 09:24 marker.txt

Ce que cela signifie : La structure de répertoire fonctionne et le serveur accepte les écritures. Décision : procédez au test de crash contrôlé
seulement lorsque vous avez un accès console (IPMI/iDRAC/console virtuelle) et une fenêtre de maintenance.

Déclencher un crash de test contrôlé et confirmer la capture du vmcore

Un test de crash kdump est par définition disruptif. Faites-le sérieusement :
fenêtre de maintenance, accès console, ticket ouvert, quelqu’un surveillant la cible de dump, et un plan de retour arrière
(au minimum : retirer crashkernel= si cela empêche le boot, bien que ce soit rare).

Blague n°2 : Forcer un crash noyau en production, c’est comme tester l’alarme incendie en mettant le feu à la cuisine — efficace, mais vous devriez avoir un extincteur.

Tâche 16 — S’assurer que SysRq est activé (nécessaire pour un déclenchement assez sûr)

cr0x@server:~$ sysctl kernel.sysrq
kernel.sysrq = 176

Ce que cela signifie : SysRq est activé (176 permet un sous-ensemble incluant le déclencheur de crash sur de nombreux systèmes).
Décision : si c’est 0, activez-le temporairement pour le test, puis décidez de la politique à long terme.

cr0x@server:~$ echo 'kernel.sysrq = 176' | sudo tee /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 176

cr0x@server:~$ sudo sysctl -p /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 176

Tâche 17 — Surveillez en direct la cible de dump (sur le serveur NFS ou sur l’hôte)

cr0x@server:~$ sudo ls -lah /mnt/kdump-nfs | tail -n 5
drwxr-xr-x  3 root root 4.0K Dec 30 09:24 .
drwxr-xr-x  4 root root 4.0K Dec 30 09:21 ..
drwxr-xr-x  2 root root 4.0K Dec 30 09:24 TEST-server-1735550640

Ce que cela signifie : Vous pouvez voir apparaître de nouveaux répertoires. Décision : gardez cette vue ouverte pendant le test ; c’est votre vérité terrain.

Tâche 18 — Déclencher le crash via SysRq

Ceci provoquera immédiatement le crash du noyau. Ne le faites pas depuis une session SSH que vous n’êtes pas prêt à perdre.
Utilisez l’accès console si vous le pouvez.

cr0x@server:~$ echo c | sudo tee /proc/sysrq-trigger
c

Ce que vous devriez voir ensuite : l’hôte panique, puis kexec démarre le noyau de crash, écrit un dump, puis redémarre.
Le timing dépend de la taille de la RAM et de la vitesse de la cible de dump. Si vous avez réservé 512M mais possédez 256G de RAM et aucun filtrage, prévoyez de la patience.

Tâche 19 — Après le redémarrage, confirmer qu’un dump a été écrit

cr0x@server:~$ sudo ls -lt /mnt/kdump-nfs | head
total 12
drwxr-xr-x 2 root root 4096 Dec 30 09:29 server-2025-12-30-09:29
drwxr-xr-x 2 root root 4096 Dec 30 09:24 TEST-server-1735550640

cr0x@server:~$ sudo ls -lah /mnt/kdump-nfs/server-2025-12-30-09:29
total 1.9G
-rw------- 1 root root 1.9G Dec 30 09:29 vmcore
-rw-r--r-- 1 root root 3.2K Dec 30 09:29 dmesg.txt
-rw-r--r-- 1 root root  178 Dec 30 09:29 kdump-info.txt

Ce que cela signifie : C’est la condition de succès : un vmcore plus quelques métadonnées. Décision : si le vmcore est absent,
passez directement au playbook de diagnostic rapide et au tableau des erreurs courantes ci‑dessous.

Tâche 20 — Confirmer que les logs montrent que kdump a fonctionné (journal du boot après le crash)

cr0x@server:~$ sudo journalctl -b -1 -u kdump-tools --no-pager | tail -n 60
Dec 30 09:28:12 server systemd[1]: Starting kdump-tools.service - Kernel crash dump capture service...
Dec 30 09:28:12 server kdump-tools[642]: kdump-tools: Loading crash kernel: succeeded
Dec 30 09:28:12 server systemd[1]: Finished kdump-tools.service - Kernel crash dump capture service.

Ce que cela signifie : Les logs du boot précédent montrent le chargement du noyau de crash. Cela ne prouve pas que le dump a été écrit (votre liste de fichiers le prouve),
mais cela prouve que le chemin de staging fonctionne. Décision : si ceci affiche « failed to load crash kernel », corrigez cela avant d’autres tests.

Contrôle de sanity du dump et analyse basique

Vous n’avez pas besoin d’être ingénieur noyau pour valider qu’un vmcore est réel et interne- ment cohérent.
L’objectif est opérationnel : confirmer que vous avez capturé la mémoire et que vous pouvez extraire une backtrace si nécessaire.

Tâche 21 — Identifier le format du dump et confirmer que ce n’est pas de la merde vide

cr0x@server:~$ sudo file /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
/mnt/kdump-nfs/server-2025-12-30-09:29/vmcore: ELF 64-bit LSB core file, x86-64, version 1 (SYSV)

Ce que cela signifie : C’est un fichier core ELF, comme attendu. Décision : passez aux outils d’analyse si vous devez déboguer ; sinon archivez-le.

Tâche 22 — Confirmer la version du noyau pour l’appariement des symboles

cr0x@server:~$ sudo cat /mnt/kdump-nfs/server-2025-12-30-09:29/kdump-info.txt
Kdump: 1.8.0
Kernel: 6.12.0-1-amd64
Dump saved to: /mnt/kdump-nfs/server-2025-12-30-09:29

Ce que cela signifie : Vous avez besoin des symboles correspondants (packages debug) pour une analyse approfondie. Décision : dans des environnements sérieux, répliquez les packages debug
en interne pour pouvoir analyser des dumps des semaines plus tard, après des upgrades.

Tâche 23 — Test rapide avec crash (optionnel mais recommandé)

cr0x@server:~$ sudo apt-get install -y crash
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  crash
Setting up crash (8.0.5-1) ...

cr0x@server:~$ sudo crash /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64 /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
crash 8.0.5
GNU gdb (Debian 14.2-1) 14.2
...
      KERNEL: /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64
    DUMPFILE: /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
        CPUS: 8
        DATE: Mon Dec 30 09:29:01 2025
      UPTIME: 00:41:22
LOAD AVERAGE: 0.02, 0.05, 0.01
       TASKS: 312
    NODENAME: server
     RELEASE: 6.12.0-1-amd64
     VERSION: #1 SMP PREEMPT_DYNAMIC Debian 6.12.3-1 (2025-09-10)
     MACHINE: x86_64  (3191 Mhz)
crash>

Ce que cela signifie : Vous pouvez ouvrir le dump. C’est l’objectif opérationnel. Décision : si cela échoue avec « cannot find vmlinux »,
mettez en place un processus pour conserver les symboles de debug pour les noyaux déployés (ou au moins ceux qui comptent).

cr0x@server:~$ printf "bt\nsys\nquit\n" | sudo crash /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64 /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore | tail -n 20
PID: 0      TASK: ffffffff9a000000  CPU: 3   COMMAND: "swapper/3"
 #0 [ffffb0a5000f3d20] machine_kexec at ffffffff8a2a1a5a
 #1 [ffffb0a5000f3d80] __crash_kexec at ffffffff8a34b8e1
 #2 [ffffb0a5000f3e50] panic at ffffffff8a1a7d9f
 #3 [ffffb0a5000f3f20] sysrq_handle_crash at ffffffff8a8c2f10
 #4 [ffffb0a5000f3f60] __handle_sysrq at ffffffff8a8c2b3a
 #5 [ffffb0a5000f3fb0] write_sysrq_trigger at ffffffff8a8c42d0

Ce que cela signifie : La backtrace montre clairement un crash déclenché par SysRq, exactement ce que nous avons fait. C’est un test propre.
Décision : vous avez vérifié bout en bout la capture kdump et la viabilité post-mortem basique.

Feuille de route de diagnostic rapide

Quand kdump « ne marche pas », ne paniquez pas. Diagnostiquez dans l’ordre qui réduit l’espace de recherche le plus vite.
Voici la séquence que j’utilise sous pression de pager.

1) Le noyau a-t-il réservé la mémoire crashkernel ?

• Vérifiez /proc/cmdline pour crashkernel=.
• Vérifiez dmesg | grep -i crashkernel pour les lignes de réservation.

Si pas de réservation : pas de dump. Corrigez les paramètres du chargeur et redémarrez. Tout le reste est une distraction.

2) Un noyau de crash est-il réellement chargé ?

• Exécutez sudo kexec -p -s pour voir si un noyau de crash est chargé.
• Vérifiez systemctl status kdump-tools et journalctl -u kdump-tools.

Si non chargé : corrigez la config kdump-tools, la génération d’initramfs, ou les images noyau manquantes.

3) L’environnement de crash peut-il accéder à la cible de dump ?

• Disque local : assurez-vous que les pilotes de bloc requis et les systèmes de fichiers sont dans l’initramfs ; vérifiez le montage.
• NFS : assurez-vous que le pilote NIC + configuration IP + route + composants client NFS sont dans l’initramfs.

Si la cible est inatteignable : ajustez les hooks initramfs, ajoutez des modules, simplifiez le chemin de dump.
N’ « optimisez » pas encore. Faites-le fonctionner d’abord.

4) Makеdumpfile filtre-t-il trop agressivement ?

• Si vous obtenez un vmcore minuscule qui ne s’ouvre pas, inspectez MAKEDUMPFILE_ARGS.
• Réduisez temporairement le filtrage pour un test de crash si nécessaire.

5) Si tout semble correct mais les dumps disparaissent

• Considérez : Secure Boot / restrictions de lockdown sur kexec, bizarreries du firmware, quirks d’IOMMU, ou réinitialisations de stockage.
• Essayez une cible de dump plus simple (partition ext4 dédiée non chiffrée) comme expérience témoin.

Erreurs courantes : symptômes → cause racine → correction

Pas de vmcore après un crash, et rien d’évident dans les logs

Syndromes : Vous forcez un crash ; l’hôte redémarre ; le répertoire de dump reste vide.

Cause racine : Pas de mémoire crashkernel réservée, ou la réservation a échoué.

Correction : Ajoutez crashkernel=512M (ou plus), redémarrez, confirmez avec dmesg | grep -i crashkernel.

Service kdump « actif », mais kexec -p -s indique aucun noyau de crash chargé

Syndromes : systemd montre kdump-tools réussi ; kexec affirme que rien n’est chargé.

Cause racine : kdump-tools n’a pas chargé à cause d’une absence de réservation crashkernel ou d’un initramfs mal généré.

Correction : Corrigez crashkernel= d’abord, puis update-initramfs -u -k all, redémarrez kdump-tools, revérifiez.

Le répertoire de dump existe mais contient seulement des métadonnées, pas de vmcore

Syndromes : Vous voyez dmesg.txt ou des fichiers info, mais pas de vmcore.

Cause racine : L’écriture du dump a échoué en cours de route : manque d’espace, pépin NFS, pilote manquant, ou noyau de crash à court de mémoire.

Correction : Vérifiez l’espace, la stabilité NFS, augmentez la taille crashkernel, assurez-vous que les modules NIC/stockage sont présents dans l’initramfs.

Dump écrit localement, mais le système de fichiers est corrompu ensuite

Syndromes : vmcore apparaît, mais le prochain boot déclenche fsck ou erreurs.

Cause racine : Dump sur le même système de fichiers déjà instable, ou crash survenu en plein écrit et la relecture du journal s’est mal passée.

Correction : Dumpez sur une partition dédiée ou NFS. Traitez /var comme non digne de confiance pendant les catastrophes.

Dump sur NFS n’apparaît jamais ; les dumps locaux fonctionnent

Syndromes : La capture sur disque local fonctionne ; la cible NFS reste vide après les tests de crash.

Cause racine : Le noyau de crash ne peut pas activer le réseau (pilote NIC manquant, pas de config IP, pas de route, VLAN requis).

Correction : Assurez-vous du pilote NIC dans l’initramfs ; configurez une IP statique pour le noyau de crash ; évitez la dépendance à des services réseau complexes (DHCP, 802.1X).

Le système se fige lors du crash au lieu de redémarrer dans le noyau de crash

Syndromes : Vous déclenchez un crash ; l’hôte se bloque ; pas de redémarrage.

Cause racine : Blocage matériel/firmware, problèmes NMI, ou le chemin de panic ne peut pas exécuter kexec ; parfois le watchdog n’est pas configuré.

Correction : Activez le watchdog matériel si disponible ; testez d’autres déclencheurs de crash ; envisagez de désactiver des réglages IOMMU problématiques pour le test ; vérifiez l’accès console.

vmcore existe mais l’outil crash ne peut pas le lire

Syndromes : file montre un fichier core, mais crash retourne des erreurs.

Cause racine : Absence des symboles vmlinux correspondants pour cette construction exacte du noyau, ou dump tronqué.

Correction : Conservez les packages de debug pour les noyaux déployés ; vérifiez la taille du dump et l’intégrité du stockage ; retestez avec un filtrage makedumpfile moins agressif.

Après l’activation de crashkernel, le système ne démarre pas ou la mémoire est trop serrée

Syndromes : OOMs anticipés, les conteneurs se comportent mal, ou le boot échoue sur des systèmes à mémoire limitée.

Cause racine : Réserver trop sur une VM contrainte, ou carte mère avec carte mémoire mappée en conflit.

Correction : Utilisez une valeur plus petite (256M), ou des paramètres crashkernel basés sur des plages mémoire ; confirmez la réservation dans dmesg.

Listes de vérification / plan étape par étape

Plan minimal « Je veux juste que ça marche » (disque local)

1. Installer : kdump-tools, kexec-tools, makedumpfile.
2. Ajouter crashkernel=512M à GRUB, exécuter update-grub, redémarrer.
3. Vérifier la réservation : dmesg | grep -i crashkernel.
4. Vérifier le noyau de crash chargé : kexec -p -s.
5. S’assurer que /var/crash a de l’espace et est écrivable.
6. Tester le crash durant une fenêtre : echo c > /proc/sysrq-trigger.
7. Après le redémarrage, vérifier que /var/crash contient vmcore.

Plan crédible pour la production (cible NFS)

1. Configurer une export NFS dédiée aux crash dumps (permissions, politique de quota, rétention).
2. La monter en userspace normal pour visibilité, mais ne pas supposer que le noyau de crash utilisera ce montage.
3. Définir KDUMP_COREDIR sur le chemin prévu et reconstruire l’initramfs.
4. Confirmer que l’initramfs contient le pilote NIC et les composants client NFS (inspecter avec lsinitramfs).
5. Définir kernel.panic=10 pour que le système redémarre après le dump.
6. Effectuer un crash contrôlé et surveiller le répertoire NFS en direct.
7. Ouvrir le dump avec crash au moins une fois. Prouvez qu’il est analysable, pas seulement « un fichier existe ».

Notes de gestion du changement (ce que j’écris sur le ticket)

• Risque : réserver crashkernel réduit la RAM disponible ; rares problèmes de boot sur firmware étrange.
• Rollback : retirer crashkernel= de GRUB et redémarrer.
• Vérification : réservation dans dmesg, noyau de crash chargé, test de crash produit un vmcore.
• Suivi opérationnel : politique de rétention, permissions, et disponibilité des symboles pour l’analyse.

Trois micro-histoires d’entreprise (terriblement plausibles)

1) L’incident causé par une fausse hypothèse

Une équipe a déployé kdump sur une flotte après qu’un panic noyau ait mis hors service un nœud de base de données et que tout le monde ait haussé les épaules dans le postmortem.
Ils ont installé les paquets, activé le service, et vérifié que systemctl status était vert.
Puis ils ont déclaré victoire. Le ticket de changement s’est fermé avec une capture d’écran. Personne n’a testé un crash.

Des mois plus tard, un hôte de production a commencé à paniquer sous une forte charge réseau. Cette fois ils pensaient être prêts : « on a kdump maintenant ».
Ils ont attendu le redémarrage, puis se sont connectés et ont regardé dans /var/crash. Vide. Pas même un fichier stub.
La chaîne d’escalade a commencé par la phrase familière : « Mais on l’a activé. »

La cause racine était élégamment simple. Les paramètres du chargeur n’avaient jamais eu crashkernel=.
Le service « fonctionnait » dans le sens où il s’exécutait et se terminait avec succès, mais il n’avait rien à charger.
L’hypothèse était que l’installation de kdump-tools impliquait que le système réserve automatiquement de la mémoire. Ce n’est pas le cas.

La correction a été facile et la leçon non : toute fonctionnalité de fiabilité qui n’est pas vérifiée bout en bout est du théâtre.
Ils ont ajouté crashkernel=512M, redémarré les hôtes par lots, et effectué un crash contrôlé par rack pendant une fenêtre planifiée.
Ensuite, lorsque le bogue du pilote réseau est réapparu, ils ont eu un vmcore et une vraie backtrace. La conversation avec le vendeur a immédiatement changé de ton.

2) L’optimisation qui a échoué

Une autre organisation exploitait de grosses machines d’analyse mémoire. Quelqu’un a décidé que les dumps étaient trop volumineux et trop lents, alors il a « optimisé »
makedumpfile pour supprimer plus de pages et compresser plus fort. Les dumps ont diminué. Tout le monde a applaudi.
Ils ont aussi réduit crashkernel de 1G à 256M parce que « ça boote bien et on veut récupérer de la RAM ».

Puis un panic est survenu pendant des orages de réinitialisation de contrôleur de stockage. Kdump écrivait parfois un vmcore minuscule—quelques mégaoctets—parfois rien.
Quand il écrivait, crash ne pouvait pas extraire des stacks utiles parce que des régions mémoire cruciales avaient été filtrées.
La configuration optimisée a livré un bel artefact contenant l’équivalent opérationnel de lorem ipsum.

L’analyse post-incident a révélé deux échecs concomitants. Le crashkernel réduit signifiait que l’environnement de crash manquait de mémoire
pour charger les pilotes de stockage et tamponner les écritures. En plus, le filtrage agressif supprimait des structures noyau nécessaires pour l’investigation (état du chemin I/O).

Ils sont revenus à une base conservatrice : crashkernel à 768M et filtrage modéré.
Les dumps sont redevenus plus gros. Mais ils sont devenus fiables et utiles. La vraie optimisation n’était pas la compression ; c’était s’assurer
que les dumps arrivaient sur une cible NFS pour que les bizarreries du disque local n’aient pas d’importance. L’optimisation des performances, oui, mais seulement après la correction.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme exploitait une flotte Debian mixte et avait une politique terne : chaque mise à jour du noyau doit aussi archiver les symboles de debug correspondants
(ou au moins les rendre récupérables) pour les deux versions précédentes. Aucune exception. Les ingénieurs se plaignaient que c’était du stockage en plus,
des étapes en plus, de la bureaucratie en plus.

Une nuit, un hôte a paniqué d’une façon qui a mis hors service un service interne critique. Kdump a fonctionné et a écrit un vmcore sur NFS.
L’astreinant a récupéré le dump sur la VM d’analyse, a lancé crash, et a immédiatement obtenu une backtrace propre pointant vers un sous‑système précis.
Ce n’était pas la cause racine complète, mais c’était suffisant pour acheminer l’incident vers la bonne équipe et appliquer une mitigation.

La clé était que la disponibilité des symboles a transformé « on a un vmcore » en « on a une réponse ». Sans symboles, ils auraient eu un blob.
Avec les symboles, ils ont eu des noms de fonctions et un récit crédible de la défaillance. La pratique ennuyeuse — conserver les artefacts de debug alignés avec les noyaux déployés —
a fait la différence entre un incident de deux heures et une dispute de deux jours.

Personne n’a envoyé un email de célébration à propos de la politique ensuite. C’est ainsi que vous savez que c’était du vrai ingénierie.

FAQ

1) Dois‑je vraiment redémarrer après avoir ajouté crashkernel= ?

Oui. La réservation de mémoire se fait au démarrage. Pas de redémarrage signifie pas de mémoire réservée, ce qui implique pas de dump fiable.

2) Comment savoir si kdump est réellement armé maintenant ?

Vérifiez les deux : dmesg | grep -i crashkernel (réservation) et sudo kexec -p -s (noyau de crash chargé).
« Le service est activé » n’est pas une preuve.

3) Quelle est la façon la plus sûre de tester kdump ?

Utilisez le déclencheur SysRq (echo c > /proc/sysrq-trigger) pendant une fenêtre de maintenance avec accès console.
Vérifiez que le dump apparaît et qu’il est lisible avec crash.

4) Quelle taille devrais‑je définir pour crashkernel sur Debian 13 ?

Commencez par 512M pour des serveurs typiques. Si vous avez des besoins importants en pilotes stockage/réseau, allez vers 768M–1024M.
Sur une petite VM, 256M peut être votre plafond — testez-le.

5) Puis‑je dumper sur un système de fichiers chiffré (LUKS) ?

Vous pouvez, mais c’est fragile : l’initramfs de crash doit déverrouiller LUKS, ce qui signifie que vous avez besoin de clés disponibles non‑interactivement.
Pour la plupart des environnements, dumpez vers une partition dédiée non chiffrée ou vers NFS à la place.

6) Kdump fonctionnera‑t‑il si le crash a été causé par le pilote de stockage ?

Peut‑être, peut‑être pas. Si votre cible de dump dépend du même empilement de pilotes qui vient de lâcher, vous jouez au hasard.
C’est pourquoi NFS ou une partition locale simple est souvent la meilleure conception.

7) Pourquoi j’obtiens un vmcore mais il est trop volumineux ?

Vous dumpez probablement la plupart de la RAM sans filtrage/compression suffisant. Ajustez MAKEDUMPFILE_ARGS pour filtrer des pages,
et prévoyez une cible de dump dimensionnée pour le pire cas. Aussi, « trop volumineux » est souvent un problème de rétention, pas un problème kdump.

8) Pourquoi crash se plaint de symboles manquants ?

Vous avez besoin du vmlinux avec symboles de debug correspondant exactement à la version du noyau qui a produit le dump.
Mettez en place un processus pour conserver ou récupérer ces artefacts après les mises à jour.

9) Dois‑je définir kernel.panic_on_oops=1 ?

Dans de nombreux environnements de production, oui : un oops signifie souvent un état noyau corrompu, et continuer peut provoquer une corruption silencieuse des données.
Si vous choisissez panic-on-oops, associez‑le à kdump et à un délai kernel.panic sensé.

10) Les conteneurs ou VM changent‑ils quelque chose ?

Les conteneurs ne contrôlent pas le noyau hôte, donc kdump est une fonctionnalité de l’hôte. Dans les VM, kdump fonctionne généralement bien — souvenez‑vous simplement que l’invité
a besoin de RAM crashkernel réservée, et votre hyperviseur peut influencer la vitesse à laquelle les dumps sont écrits sur le disque virtuel ou le réseau.

Prochaines étapes à effectuer réellement

• Choisissez une cible de dump basée sur les modes de défaillance, pas la commodité. Si le stockage est complexe, optez pour NFS ou une partition dédiée.
• Standardisez le dimensionnement du crashkernel. Commencez par 512M ; documentez quand utiliser davantage.
• Faites un crash contrôlé par type de plateforme. Différentes NICs / contrôleurs RAID se comportent différemment dans le noyau de crash.
• Faites de la disponibilité des symboles une politique. Si vous ne pouvez pas ouvrir un dump deux semaines plus tard, vous collectionnez des presse‑papier coûteux.
• Automatisez la vérification. Au minimum, alertez si crashkernel n’est pas réservé ou si le noyau de crash n’est pas chargé.
• Rédigez le runbook opérateur. Qui récupère le vmcore, où il est stocké, comment fonctionne la rétention, et qui peut y accéder.

Kdump est une fonctionnalité de fiabilité qui ne paye que lorsque tout le reste a échoué. Ce n’est pas une raison pour procrastiner.
C’est la raison de bien le faire, le tester et le garder ennuyeux.