Kdump in Linux aktivieren: Dumps bei Kernel-Panic

Niveau: Fortgeschritten / Senior
Geschätzte Dauer: ca. 30 Minuten
Ziel: kdump für die Linux-Crash-Dump-Erfassung bei Kernel-Panics konfigurieren, um Produktionsausfälle zuverlässig post mortem analysieren zu können. Diese Anleitung erklärt, wie Sie kdump unter Linux aktivieren, und deckt die vollständige Linux-Crash-Dump-Konfiguration von der Speicherreservierung bis zur vmcore-Analyse ab.

Einführung

Eine Kernel-Panic legt das System lahm, und ohne Crash-Dump haben Sie keinerlei Daten zur Analyse. Kdump, das Standard-Framework für Crash-Dumps des Linux-Kernels, löst dieses Problem: Es lädt vorab einen Capture-Kernel in reservierten Speicher, und wenn der primäre Kernel in eine Panic läuft, startet kexec diesen Capture-Kernel, der ein vollständiges Speicherabbild (vmcore) auf die Festplatte schreibt. In dieser Anleitung lernen Sie, wie Sie kdump unter Linux für die Erfassung von Kernel-Panic-Dumps auf Ubuntu-, Debian- und RHEL-basierten Systemen aktivieren. Wir zeigen Ihnen genau, wie Sie kdump auf Linux-Systemen aktivieren, einschließlich der Schritte zur vmcore-Analyse unter Linux nach dem Absturz.

Was ist Kdump?

Kdump ist ein Mechanismus zur Erstellung von Kernel-Crash-Dumps, der mit kexec bei jeder Panic des primären Kernels einen sekundären Capture-Kernel aus einem reservierten Speicherbereich bootet. Der Capture-Kernel läuft mit begrenztem Speicher (festgelegt durch den Boot-Parameter crashkernel) und schreibt das Speicherabbild des ausgefallenen Kernels als vmcore auf die Festplatte, eine vollständige Speicherabbilddatei, die sich mit dem Dienstprogramm crash oder mit gdb analysieren lässt. Der kdump-Dienst (kdump.service auf RHEL-basierten bzw. kdump-tools.service auf Debian-basierten Systemen) steuert das Laden des Capture-Kernels beim Systemstart.

Wichtige Komponenten:

• Kexec – der Systemaufruf und das Userspace-Werkzeug, das den Capture-Kernel in den reservierten Speicher lädt.
• Crashkernel – der Boot-Parameter, der dem primären Kernel mitteilt, wie viel RAM für den kdump-Betrieb unter Linux zu reservieren ist (z. B. crashkernel=256M).
• Vmcore – die Ausgabedatei mit dem vollständigen Speicherabbild, die standardmäßig nach /var/crash geschrieben wird.
• /var/crash – das Standardverzeichnis, in dem kdump nach einer Kernel-Panic die vmcore-Dateien ablegt.

Voraussetzungen

Stellen Sie vor dem Start sicher, dass folgende Bedingungen erfüllt sind:

• Betriebssystem: Ubuntu 22.04/24.04 LTS, Debian 12/13 oder RHEL/CentOS/AlmaLinux 9/10 (getestet und verifiziert auf Ubuntu 24.04, Debian 13 und AlmaLinux 10)
• Zugriff: sudo- oder Root-Zugriff auf den Server
• RAM: mindestens 2 GB insgesamt. Kdump reserviert einen Teil des Systemspeichers (üblicherweise 256 MB) für den Capture-Kernel; Systeme mit wenig Speicher haben dafür möglicherweise nicht genug Reserven.
• Speicherplatz: mindestens so viel freier Platz in /var/crash, wie das System RAM hat (ein vmcore kann so groß wie der physische Speicher werden)
• Erforderliche Kenntnisse: sicherer Umgang mit der Linux-Kommandozeile, grundlegendes Bearbeiten von Dateien und Vertrautheit mit GRUB-Boot-Parametern
• Neustartfenster: Die Konfiguration des Parameters crashkernel erfordert einen Neustart, damit sie wirksam wird

Schritt 1: Die Pakete kdump und kexec installieren

Kdump benötigt kexec-tools (die Userspace-Komponente für kexec/kdump unter Linux) sowie distributionsspezifische Hilfspakete.

Ubuntu/Debian:

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

Bei einer interaktiven Installation unter Ubuntu kann eine debconf-Abfrage erscheinen, ob der Parameter crashkernel automatisch konfiguriert werden soll. Wählen Sie Yes, falls Sie gefragt werden. Erscheint die Abfrage nicht (z. B. im nicht interaktiven Modus), wird crashkernel automatisch über eine Drop-in-Datei konfiguriert. Wenn Sie den Wert später anpassen müssen, behandelt Schritt 2 die manuelle Konfiguration.

RHEL/CentOS/AlmaLinux:

sudo dnf install kexec-tools crash -y

Auf RHEL-basierten Systemen liefert das Paket kexec-tools alles Nötige: die Binärdatei kexec, den kdump-Dienst und die Standardkonfigurationsdateien.

Schritt 2: Den Boot-Parameter crashkernel konfigurieren

Der Parameter crashkernel teilt dem Kernel mit, wie viel Speicher er beim Start für kdump unter Linux reservieren soll. Ohne diese Reservierung hat der Capture-Kernel keinen Platz, an dem er laufen kann. Es ist entscheidend, die Werte des Parameters crashkernel richtig zu wählen: Ist er zu klein, bootet der Capture-Kernel nicht; ist er zu groß, verschwenden Sie RAM im Produktivbetrieb.

2.1 Aktuelle Konfiguration prüfen

Prüfen Sie zunächst, ob crashkernel bereits gesetzt ist:

cat /proc/cmdline | grep crashkernel

Enthält die Ausgabe einen Eintrag crashkernel=, ist der Parameter bereits konfiguriert. Sie können die reservierte Größe prüfen und, wenn sie Ihren Anforderungen genügt, direkt zu Schritt 3 springen.

2.2 Den Parameter crashkernel auf GRUB-basierten Systemen konfigurieren

Ubuntu/Debian:

Prüfen Sie vor der Änderung der Haupt-GRUB-Konfiguration, ob bereits eine Drop-in-Datei existiert:

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

Hat das Paket crashkernel hier bereits konfiguriert, ändern Sie stattdessen diese Datei, um doppelte Einträge in grub.cfg zu vermeiden. Öffnen Sie andernfalls die Haupt-GRUB-Standarddatei:

sudo nano /etc/default/grub

Suchen Sie die Zeile GRUB_CMDLINE_LINUX_DEFAULT und fügen Sie den Parameter crashkernel hinzu. Für die meisten Produktionsserver mit 4 GB RAM oder mehr genügen 256 MB, um Speicher für kdump unter Linux zu reservieren:

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

Verwenden Sie für Server mit weniger als 4 GB RAM crashkernel=128M. Für Systeme mit 64 GB oder mehr bietet sich crashkernel=512M an. Sie können auch die automatisch skalierende Syntax crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M verwenden, um die Werte des Parameters crashkernel dynamisch anhand des installierten RAM festzulegen.

Speichern und schließen Sie die Datei und erzeugen Sie dann die GRUB-Konfiguration neu:

sudo update-grub

RHEL/CentOS/AlmaLinux:

Bei RHEL/AlmaLinux 8+ steht der Parameter crashkernel in GRUB_CMDLINE_LINUX (ohne _DEFAULT). Auf modernen Systemen mit BLS (Boot Loader Specification) ist es jedoch der sicherste und empfohlene Weg, die Kernel-Kommandozeile mit grubby zu aktualisieren, statt /etc/default/grub direkt zu ändern:

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

Wenn Sie die Änderung zwingend manuell über die GRUB-Konfiguration vornehmen müssen, bearbeiten Sie /etc/default/grub und aktualisieren Sie GRUB_CMDLINE_LINUX. Erzeugen Sie anschließend die Konfiguration neu (die Pfade hängen vom Boot-Modus ab):

# Für Legacy-BIOS-Systeme:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Für UEFI-Systeme (z. B. AlmaLinux):
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Neustart, um die crashkernel-Reservierung zu übernehmen

Die Speicherreservierung durch crashkernel wird erst nach einem Neustart wirksam:

sudo reboot

Prüfen Sie nach dem Hochfahren des Systems, ob die Reservierung aktiv ist:

cat /proc/cmdline | grep crashkernel

Die erwartete Ausgabe enthält:

crashkernel=256M

Bestätigen Sie außerdem, dass der Speicher tatsächlich reserviert wurde:

sudo dmesg | grep -i "crashkernel reserved"

Sie sollten eine Zeile wie diese sehen:

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

Ist die Reservierung fehlgeschlagen (die Meldung lautet "crashkernel reservation failed"), müssen Sie den Wert eventuell erhöhen oder verringern. Das ist ein häufiger Schritt bei der Fehlersuche bei Linux-Kernel-Panics: Der Kernel konnte keinen zusammenhängenden Block der angeforderten Größe finden.

Schritt 3: Die Einstellungen des kdump-Dienstes unter Linux konfigurieren

Nachdem der Speicher reserviert ist, legen Sie fest, wo und wie kdump den vmcore speichert.

3.1 Konfiguration unter RHEL/CentOS/AlmaLinux

Die Hauptkonfigurationsdatei ist /etc/kdump.conf. Öffnen Sie sie:

sudo nano /etc/kdump.conf

Die wichtigsten Direktiven:

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

• path /var/crash – legt das Zielverzeichnis für den vmcore fest. Alle Crash-Dumps landen hier.
• core_collector makedumpfile – komprimiert den Dump und filtert unnötige Seiten heraus. Das Flag -d 31 schließt Nullseiten, Cache, Benutzerdaten und freie Seiten aus und verkleinert einen vmcore typischerweise auf 10–20 % des gesamten RAM.

3.2 Konfiguration unter Ubuntu/Debian

Auf Debian-basierten Systemen liegt die Konfiguration von kdump-tools in /etc/default/kdump-tools. Öffnen Sie die Datei:

sudo nano /etc/default/kdump-tools

Stellen Sie sicher, dass diese Zeilen gesetzt sind:

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

USE_KDUMP=1 aktiviert den kdump-Dienst. Ohne diese Einstellung wird der Capture-Kernel beim Booten nicht geladen.

Schritt 4: Den kdump-Dienst aktivieren und starten

Dies ist der letzte Schritt bei der Aktivierung von kdump unter Linux. Aktivieren Sie den kdump-Dienst, damit der Capture-Kernel bei jedem Systemstart automatisch geladen wird, und schließen Sie damit die kexec-/kdump-Einrichtung unter Linux ab.

Ubuntu/Debian:

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

RHEL/CentOS/AlmaLinux:

sudo systemctl enable kdump
sudo systemctl start kdump

Prüfen Sie, ob der Dienst läuft:

Ubuntu/Debian:

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl status kdump

Die erwartete Ausgabe enthält:

Active: active (exited)

Der Status "exited" ist normal: Der kdump-Dienst lädt den Capture-Kernel in den reservierten Speicher und beendet sich dann. Er läuft nicht als dauerhafter Daemon.

Schritt 5: Überprüfung und Test

5.1 Prüfen, ob kdump bereit ist

Bestätigen Sie, dass der Capture-Kernel geladen und bereit ist, bei einer Kernel-Panic auszulösen:

cat /sys/kernel/kexec_crash_loaded

Erwartete Ausgabe:

1

Der Wert 1 bedeutet, dass der Capture-Kernel geladen ist. Bei 0 ist kdump nicht einsatzbereit; prüfen Sie dann den Dienststatus und die crashkernel-Reservierung.

Sie können außerdem prüfen, wie viel Speicher für kdump unter Linux reserviert wurde:

cat /sys/kernel/kexec_crash_size

Die Reservierung wird in Bytes zurückgegeben.

5.2 Einen Test-Crash auslösen

Aktivieren Sie die SysRq-Trigger und erzwingen Sie dann einen Absturz:

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

Das System gerät in eine Panic. Ist kdump korrekt konfiguriert, bootet der Capture-Kernel, schreibt den vmcore nach /var/crash, und das System startet automatisch neu.

5.3 Bestätigen, dass der vmcore erfasst wurde

Prüfen Sie nach dem Neustart /var/crash auf den Dump:

ls -lh /var/crash/

Erwartete Ausgabe (das Format variiert je nach Distribution):

RHEL-Familie (AlmaLinux/CentOS):

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

In diesem Verzeichnis mit Zeitstempel finden Sie vmcore (das Speicherabbild) und vmcore-dmesg.txt (das Kernel-Log).

Debian-Familie (Ubuntu/Debian):

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

In diesem Verzeichnis heißen die Dateien üblicherweise dump.<timestamp> und dmesg.<timestamp>.

Prüfen Sie den Inhalt des Verzeichnisses:

ls -lh /var/crash/*/

Wenn Sie diese Dateien sehen, ist Ihre Pipeline für Linux-Kernel-Crash-Dumps vollständig einsatzbereit.

Schritt 6: Eine vmcore-Datei analysieren

Einen Crash-Dump zu erfassen, nützt nur etwas, wenn Sie ihn auch lesen können. Das Dienstprogramm crash ist das Standardwerkzeug, auf das sich Administratoren bei der vmcore-Analyse unter Linux und der Fehlersuche bei Linux-Kernel-Panics verlassen.

6.1 Den Debug-Kernel installieren

Das Werkzeug crash benötigt die Debug-Symbole für genau die Kernel-Version, die in die Panic gelaufen ist.

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 Den vmcore mit crash öffnen

Prüfen Sie vor dem Start von crash, dass die Debug-Symbole installiert sind und zu Ihrer Kernel-Version passen, damit Sie nicht blind arbeiten:

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

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

Wechseln Sie in das Crash-Dump-Verzeichnis und öffnen Sie den vmcore (der genaue Befehl hängt vom Betriebssystem ab):

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.*

Das Dienstprogramm crash lädt den Dump und öffnet eine interaktive Shell. Wichtige Befehle für die erste Triage:

bt          # Backtrace des in die Panic gelaufenen Tasks
log         # Kernel-Log-Puffer (entspricht dmesg zum Zeitpunkt der Panic)
ps          # Prozesse zum Zeitpunkt des Absturzes auflisten
mod         # geladene Kernel-Module
sys         # Systeminformationen

Geben Sie exit oder quit ein, um die crash-Shell zu verlassen.

Rollback

So machen Sie die kdump-Konfiguration rückgängig und geben den reservierten Speicher frei:

1. Den kdump-Dienst stoppen und deaktivieren:

Ubuntu/Debian:

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl disable --now kdump

2. Den Parameter crashkernel entfernen:

Ubuntu/Debian:

Öffnen Sie die Drop-in-Konfigurationsdatei:

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

Entfernen Sie den Parameter crashkernel (haben Sie ihn manuell in /etc/default/grub eingetragen, bearbeiten Sie stattdessen diese Datei).

RHEL/CentOS/AlmaLinux:

Öffnen Sie die GRUB-Standarddatei:

sudo nano /etc/default/grub

Entfernen Sie crashkernel=256M aus der Zeile GRUB_CMDLINE_LINUX oder GRUB_CMDLINE_LINUX_DEFAULT.

GRUB neu erzeugen:

Ubuntu/Debian:

sudo update-grub

RHEL/CentOS/AlmaLinux:

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

3. Neu starten, um den reservierten Speicher freizugeben:

sudo reboot

4. Die Pakete entfernen (optional):

Ubuntu/Debian:

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

RHEL/CentOS/AlmaLinux:

sudo dnf remove kexec-tools crash -y

Fehlerbehebung

Der kdump-Dienst startet nicht

Prüfen Sie das Journal auf die Ursache:

journalctl -xeu kdump

Häufige Ursachen:

• Keine crashkernel-Reservierung. Prüfen Sie mit cat /proc/cmdline | grep crashkernel. Fehlt sie, wiederholen Sie Schritt 2.
• Zu wenig reservierter Speicher. Der Capture-Kernel braucht genug RAM, um zu initialisieren und den Dump zu schreiben. Versuchen Sie, den Wert zu erhöhen (z. B. crashkernel=512M).
• Secure-Boot-Konflikt. Manche Secure-Boot-Konfigurationen verhindern, dass kexec nicht signierte Kernel lädt. Signieren Sie entweder den Capture-Kernel oder deaktivieren Sie Secure Boot im BIOS.

Nach einer Panic wird kein vmcore geschrieben

• Speicherplatz. Prüfen Sie, ob /var/crash genug freien Platz hat. Ein vmcore kann (vor der Kompression durch makedumpfile) die Größe des physischen RAM erreichen.
• Falscher Pfad. Vergewissern Sie sich, dass path in /etc/kdump.conf (bzw. KDUMP_COREDIR in /etc/default/kdump-tools) auf ein beschreibbares, eingehängtes Dateisystem zeigt.
• SELinux-Verweigerung. Prüfen Sie auf RHEL-basierten Systemen mit ausearch -m avc -ts recent auf kdump-bezogene Verweigerungen.

Das System hängt, statt den Dump zu erfassen

Das deutet in der Regel auf ein Hardware- oder Treiberproblem hin, das den Übergang zum kexec/kdump-Kernel unter Linux verhindert. Versuchen Sie, irqpoll nr_cpus=1 reset_devices der Kommandozeile des kdump-Kernels in /etc/sysconfig/kdump (RHEL) oder /etc/default/kdump-tools (Debian) als KDUMP_CMDLINE_APPEND hinzuzufügen.

Fazit

Das war's. Crashkernel reserviert Speicher, der kdump-Dienst lädt beim Booten den Capture-Kernel, und bei einer Linux-Kernel-Panic landet der vmcore in /var/crash, bereit für eine Linux-Crash-Dump-Konfiguration, der Sie wirklich vertrauen können. Sie haben nun ein funktionierendes Setup, um die Linux-Crash-Dump-Erfassung mit kdump automatisch zu aktivieren; für eine tiefergehende Fehlersuche bei Linux-Kernel-Panics übergeben Sie den vmcore an crash und beginnen mit dem Backtrace.

Dokumentversion: 1.0
Zuletzt aktualisiert: Mai 2026
Verantwortlich: Team für technische Dokumentation