Attivare Kdump su Linux: crash dump per kernel panic

Livello: Intermedio / Senior
Tempo stimato: ~30 minuti
Obiettivo: Configurare l'acquisizione del dump di crash (crash dump) di kdump in Linux per i panic del kernel, consentendo un'analisi post-mortem affidabile dei guasti in produzione. Questa guida spiega come abilitare kdump in Linux, coprendo l'intera configurazione del dump di crash di Linux, dalla riserva di memoria all'analisi del vmcore.

Introduzione

Un panic del kernel (kernel panic) blocca il sistema e, senza un dump di crash, non hai dati con cui lavorare. Kdump, il framework standard per il dump di crash del kernel Linux, risolve questo problema: precarica un kernel di cattura nella memoria riservata e, quando il kernel principale va in panic, kexec avvia quel kernel di cattura per scrivere un'immagine completa della memoria (vmcore) su disco. In questo tutorial, imparerai come abilitare kdump in Linux per l'acquisizione del dump di crash del kernel Linux su sistemi Ubuntu, Debian e basati su RHEL. Ti mostreremo esattamente come abilitare i sistemi kdump richiesti da Linux, inclusi i passaggi per l'analisi post-mortem del vmcore in Linux.

Cos'è Kdump?

Kdump è un meccanismo di dump di crash del kernel che utilizza kexec per avviare un kernel di cattura secondario da una regione di memoria riservata ogni volta che il kernel principale va in panic. Il kernel di cattura viene eseguito con memoria limitata (impostata dal parametro di boot crashkernel) e scrive l'immagine di memoria del kernel fallito su disco come vmcore: un file di dump della memoria completo che può essere analizzato con l'utilità crash o gdb. Il servizio kdump (kdump.service sui sistemi basati su RHEL o kdump-tools.service sui sistemi basati su Debian) gestisce il caricamento del kernel di cattura al momento dell'avvio.

Componenti chiave:

• Kexec: la system call e lo strumento userspace che carica il kernel di cattura nella memoria riservata.
• Crashkernel: il parametro di boot che indica al kernel principale quanta RAM riservare per l'operazione di kdump in Linux (ad esempio, crashkernel=256M).
• Vmcore: il file di output contenente il dump completo della memoria, scritto in /var/crash per impostazione predefinita.
• /var/crash: la directory predefinita in cui kdump memorizza i file vmcore dopo un panic del kernel.

Prerequisiti

Prima di iniziare, assicurati che siano soddisfatte le seguenti condizioni:

• Sistema operativo: Ubuntu 22.04/24.04 LTS, Debian 12/13 o RHEL/CentOS/AlmaLinux 9/10 (Testato e verificato su Ubuntu 24.04, Debian 13 e AlmaLinux 10).
• Accesso: Accesso sudo o root al server.
• RAM: Minimo 2 GB totali. Kdump riserva una parte della memoria di sistema (tipicamente 256 MB) per il kernel di cattura; i sistemi con poca memoria potrebbero non avere margine sufficiente.
• Spazio su disco: Almeno tanto spazio libero in /var/crash quanta RAM ha il tuo sistema (un vmcore può essere grande quanto la memoria fisica).
• Conoscenze richieste: uso sicuro della riga di comando Linux, modifica di base dei file e familiarità con i parametri di boot di GRUB.
• Finestra di riavvio: La configurazione del parametro crashkernel richiede un riavvio per avere effetto.

Passaggio 1: Installare i pacchetti kdump e kexec

Kdump si basa su kexec-tools (il componente userspace di kexec/kdump in Linux) e su helper specifici della distribuzione.

Ubuntu/Debian:

sudo apt update && sudo apt install kdump-tools kexec-tools crash -y

Durante un'installazione interattiva su Ubuntu, potrebbe apparire un prompt debconf che chiede di configurare automaticamente il parametro crashkernel. Seleziona Sì se richiesto. Se il prompt non appare (ad esempio, in modalità non interattiva), crashkernel viene configurato automaticamente tramite un file drop-in. Se devi regolare il valore in seguito, il Passaggio 2 copre la configurazione manuale.

RHEL/CentOS/AlmaLinux:

sudo dnf install kexec-tools crash -y

Sui sistemi basati su RHEL, il pacchetto kexec-tools fornisce tutto il necessario: il binario kexec, il servizio kdump e i file di configurazione predefiniti.

Passaggio 2: Configurare il parametro di boot crashkernel

Il parametro crashkernel indica al kernel quanta memoria riservare per kdump in Linux al momento dell'avvio. Senza questa riserva, il kernel di cattura non ha dove eseguire. Comprendere come configurare correttamente i valori del parametro crashkernel è essenziale: troppo poca e il kernel di cattura non si avvierà; troppa e sprecherai RAM di produzione.

2.1 Controllare la configurazione attuale

Per prima cosa, controlla se crashkernel è già impostato:

cat /proc/cmdline | grep crashkernel

Se l'output contiene una voce crashkernel=, il parametro è già configurato. Puoi verificare la quantità riservata e saltare al Passaggio 3 se soddisfa le tue esigenze.

2.2 Configurare il parametro crashkernel sui sistemi basati su GRUB

Ubuntu/Debian:

Prima di modificare la configurazione principale di GRUB, controlla se esiste già un file drop-in:

cat /etc/default/grub.d/kdump-tools.cfg

Se il pacchetto ha già configurato crashkernel qui, modifica questo file invece di prevenire voci duplicate in grub.cfg. Altrimenti, apri il file delle impostazioni predefinite principale di GRUB:

sudo nano /etc/default/grub

Trova la riga GRUB_CMDLINE_LINUX_DEFAULT e aggiungi il parametro crashkernel. Per la maggior parte dei server di produzione con 4 GB o più di RAM, 256 MB sono sufficienti per riservare memoria per kdump in Linux:

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

Per i server con meno di 4 GB di RAM, usa crashkernel=128M. Per i sistemi con 64 GB o più, considera crashkernel=512M. Puoi anche usare la sintassi di scalatura automatica crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M per configurare i valori del parametro crashkernel dinamicamente in base alla RAM installata.

Salva e chiudi il file, quindi rigenera la configurazione di GRUB:

sudo update-grub

RHEL/CentOS/AlmaLinux:

Per RHEL/AlmaLinux 8+, il parametro crashkernel si trova in GRUB_CMDLINE_LINUX (senza _DEFAULT). Tuttavia, sui sistemi moderni che utilizzano BLS (Boot Loader Specification), il modo più sicuro e raccomandato per aggiornare la riga di comando del kernel è usare grubby invece di modificare direttamente /etc/default/grub:

sudo grubby --update-kernel=ALL --args="crashkernel=256M"

Se devi modificarlo manualmente tramite le configurazioni di GRUB, modifica /etc/default/grub e aggiorna GRUB_CMDLINE_LINUX. Quindi rigenera la configurazione (i percorsi variano a seconda della modalità di avvio):

# Per sistemi BIOS legacy:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Per sistemi UEFI (ad esempio, AlmaLinux):
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Riavviare per applicare la riserva di crashkernel

La riserva di memoria crashkernel ha effetto solo dopo un riavvio:

sudo reboot

Dopo che il sistema è tornato attivo, verifica che la riserva sia attiva:

cat /proc/cmdline | grep crashkernel

L'output atteso include:

crashkernel=256M

Conferma anche che la memoria sia stata effettivamente riservata:

sudo dmesg | grep -i "crashkernel reserved"

Dovresti vedere una riga come:

crashkernel reserved: 0x... - 0x... (NNN MB)

Se la riserva è fallita (il messaggio dice "crashkernel reservation failed"), potrebbe essere necessario aumentare o diminuire il valore. Questo è un passaggio comune per la risoluzione dei problemi di panic del kernel in Linux: il kernel non è riuscito a trovare un blocco contiguo della dimensione richiesta.

Passaggio 3: Configurare le impostazioni del servizio kdump in Linux

Con la memoria riservata, configura dove e come kdump memorizza il vmcore.

3.1 Configurazione su RHEL/CentOS/AlmaLinux

Il file di configurazione principale è /etc/kdump.conf. Aprilo:

sudo nano /etc/kdump.conf

Le direttive critiche:

path /var/crash
core_collector makedumpfile -l --message-level 7 -d 31

• path /var/crash: imposta la directory di destinazione del vmcore. Tutti i dump di crash finiscono qui.
• core_collector makedumpfile: comprime il dump e filtra le pagine non necessarie. Il flag -d 31 esclude le pagine zero, la cache, i dati utente e le pagine libere, riducendo tipicamente un vmcore al 10-20% della RAM totale.

3.2 Configurazione su Ubuntu/Debian

Sui sistemi basati su Debian, la configurazione di kdump-tools si trova in /etc/default/kdump-tools. Aprilo:

sudo nano /etc/default/kdump-tools

Assicurati che queste righe siano impostate:

USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
KDUMP_CORE_COLLECTOR="makedumpfile -l --message-level 7 -d 31"

USE_KDUMP=1 abilita il servizio kdump. Senza di esso, il kernel di cattura non verrà caricato all'avvio.

Passaggio 4: Abilitare e avviare il servizio kdump

Questo è il passaggio finale su come abilitare kdump in Linux. Abilita il servizio kdump in modo che il kernel di cattura venga caricato automaticamente a ogni avvio, completando la configurazione di kexec/kdump in Linux.

Ubuntu/Debian:

sudo systemctl enable kdump-tools
sudo systemctl start kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl enable kdump
sudo systemctl start kdump

Verifica che il servizio sia in esecuzione:

Ubuntu/Debian:

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl status kdump

L'output atteso include:

Active: active (exited)

Lo stato "exited" (uscito) è normale: il servizio kdump carica il kernel di cattura nella memoria riservata e poi esce. Non viene eseguito come un demone persistente.

Passaggio 5: Verifica e test

5.1 Verificare che kdump sia pronto

Conferma che il kernel di cattura sia caricato e pronto a scattare in caso di panic del kernel:

cat /sys/kernel/kexec_crash_loaded

Output atteso:

1

Un valore di 1 significa che il kernel di cattura è caricato. Un 0 significa che kdump non è operativo; torna indietro e controlla lo stato del servizio e la riserva di crashkernel.

Puoi anche ispezionare quanta memoria è stata messa da parte per riservare memoria per kdump in Linux:

cat /sys/kernel/kexec_crash_size

Questo restituisce la riserva in byte.

5.2 Innescare un crash di test

Abilita i trigger SysRq, quindi forza un crash:

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

Il sistema andrà in panic. Se kdump è configurato correttamente, il kernel di cattura si avvierà, scriverà il vmcore in /var/crash e il sistema si riavvierà automaticamente.

5.3 Confermare che il vmcore sia stato catturato

Dopo il riavvio, controlla /var/crash per il dump:

ls -lh /var/crash/

Output atteso (il formato varia in base alla distribuzione):

Famiglia RHEL (AlmaLinux/CentOS):

drwxr-xr-x 2 root root 4.0K May 23 14:00 127.0.0.1-2026-05-23-14:00:01/

All'interno di questa directory con timestamp, troverai vmcore (il dump della memoria) e vmcore-dmesg.txt (il log del kernel).

Famiglia Debian (Ubuntu/Debian):

drwxr-xr-x 2 root root 4.0K May 23 14:00 202605231400/

All'interno di questa directory, i file sono tipicamente denominati dump.<timestamp> e dmesg.<timestamp>.

Controlla all'interno della directory:

ls -lh /var/crash/*/

Vedere questi file conferma che la tua pipeline di dump di crash del kernel Linux è completamente operativa.

Passaggio 6: Analizzare un file vmcore

Catturare un dump di crash è utile solo se puoi leggerlo. L'utilità crash è lo strumento standard su cui gli amministratori Linux fanno affidamento per l'analisi del vmcore e la risoluzione dei problemi di panic del kernel in Linux.

6.1 Installare il kernel di debug

Lo strumento crash richiede i simboli di debug della versione esatta del kernel che è andato in panic.

Ubuntu:

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse" | sudo tee /etc/apt/sources.list.d/ddebs.list
sudo apt install ubuntu-dbgsym-keyring
sudo apt update
sudo apt install linux-image-unsigned-$(uname -r)-dbgsym

Debian:

echo "deb http://deb.debian.org/debian-debug/ $(lsb_release -cs)-debug main" | sudo tee /etc/apt/sources.list.d/debian-debug.list
sudo apt update
sudo apt install linux-image-$(uname -r)-dbg

RHEL/CentOS/AlmaLinux:

sudo dnf --enablerepo='*-debuginfo' install -y kernel-debuginfo-$(uname -r)

6.2 Aprire il vmcore con crash

Prima di eseguire crash, verifica che i simboli di debug siano installati e corrispondano alla versione del tuo kernel per non eseguirlo alla cieca:

# RHEL/Debian:
ls -lh /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

# Ubuntu:
ls -lh /usr/lib/debug/boot/vmlinux-$(uname -r)

Naviga nella directory del dump di crash e apri il vmcore (il comando esatto varia in base al SO):

RHEL/CentOS/AlmaLinux:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Debian:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/dump.*

Ubuntu:

sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/*/dump.*

L'utilità crash si carica e ti porta in una shell interattiva. Comandi chiave per il triage iniziale:

bt          # backtrace del task che ha causato il panic
log         # buffer del log del kernel (uguale a dmesg al momento del panic)
ps          # elenco dei processi al momento del crash
mod         # moduli del kernel caricati
sys         # informazioni di sistema

Digita exit o quit per uscire dalla shell di crash.

Ripristino (Rollback)

Per annullare la configurazione di kdump e recuperare la memoria riservata:

1. Arrestare e disabilitare il servizio kdump:

Ubuntu/Debian:

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl disable --now kdump

2. Rimuovere il parametro crashkernel:

Ubuntu/Debian:

Apri il file di configurazione drop-in:

sudo nano /etc/default/grub.d/kdump-tools.cfg

Rimuovi il parametro crashkernel (se lo hai aggiunto manualmente a /etc/default/grub, modifica invece quel file).

RHEL/CentOS/AlmaLinux:

Apri il file delle impostazioni predefinite di GRUB:

sudo nano /etc/default/grub

Rimuovi crashkernel=256M dalla riga GRUB_CMDLINE_LINUX o GRUB_CMDLINE_LINUX_DEFAULT.

Rigenerare GRUB:

Ubuntu/Debian:

sudo update-grub

RHEL/CentOS/AlmaLinux:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

3. Riavviare per rilasciare la memoria riservata:

sudo reboot

4. Rimuovere i pacchetti (opzionale):

Ubuntu/Debian:

sudo apt remove --purge kdump-tools kexec-tools crash -y

RHEL/CentOS/AlmaLinux:

sudo dnf remove kexec-tools crash -y

Risoluzione dei problemi

Il servizio kdump non si avvia

Controlla il journal per il motivo:

journalctl -xeu kdump

Cause comuni:

• Nessuna riserva di crashkernel. Verifica con cat /proc/cmdline | grep crashkernel. Se manca, ripeti il Passaggio 2.
• Memoria riservata insufficiente. Il kernel di cattura ha bisogno di RAM sufficiente per inizializzarsi e scrivere il dump. Prova ad aumentare il valore (ad esempio, crashkernel=512M).
• Conflitto con Secure Boot. Alcune configurazioni di Secure Boot impediscono a kexec di caricare kernel non firmati. Firma il kernel di cattura o disabilita Secure Boot nel BIOS.

Vmcore non scritto dopo un panic

• Spazio su disco. Verifica che /var/crash abbia spazio libero sufficiente. Un vmcore può avvicinarsi alle dimensioni della RAM fisica (prima della compressione di makedumpfile).
• Percorso errato. Conferma che path in /etc/kdump.conf (o KDUMP_COREDIR in /etc/default/kdump-tools) punti a un filesystem montato e scrivibile.
• Diniego di SELinux. Sui sistemi basati su RHEL, controlla ausearch -m avc -ts recent per dinieghi relativi a kdump.

Il sistema si blocca invece di catturare il dump

Questo indica tipicamente un problema hardware o del driver che impedisce la transizione di kexec/kdump in Linux. Prova ad aggiungere irqpoll nr_cpus=1 reset_devices alla riga di comando del kernel di kdump in /etc/sysconfig/kdump (RHEL) o /etc/default/kdump-tools (Debian) come KDUMP_CMDLINE_APPEND.

Conclusione

Questo è tutto. Crashkernel riserva la memoria, il servizio kdump carica il kernel di cattura all'avvio e, in caso di dump di panic del kernel Linux, il vmcore finisce in /var/crash, pronto per una configurazione di dump di crash di Linux di cui puoi davvero fidarti. Ora hai una configurazione funzionante per abilitare automaticamente l'acquisizione del dump di crash di kdump in Linux; per una risoluzione dei problemi di panic del kernel Linux più approfondita, passa il vmcore a crash e inizia con il backtrace.

Versione del documento: 1.0
Ultimo aggiornamento: Maggio 2026
Proprietario: Team di Documentazione Tecnica