kdump przechwytuje zawartość pamięci systemowej (crash dump) w momencie wystąpienia Kernel Panic. Zrzut można przeanalizować narzędziami takimi jak crash, aby zidentyfikować wadliwy sterownik, błąd w jądrze lub inną przyczynę awarii.

Jak działa Kdump?

Działanie kdump opiera się na koncepcji dwóch jąder:

  1. Jądro systemowe (System Kernel): To jest główne jądro, na którym pracuje Twój system operacyjny.
  2. Jądro przechwytujące (Capture Kernel): To drugie, minimalistyczne jądro, które jest ładowane do specjalnie zarezerwowanego obszaru pamięci RAM podczas startu systemu. Jest ono nieaktywne podczas normalnej pracy.

Gdy w jądrze systemowym wystąpi Kernel Panic, kontrolę przejmuje mechanizm kexec. kexec to funkcja jądra, która pozwala na załadowanie i uruchomienie nowego jądra bezpośrednio z pamięci, z pominięciem etapu BIOS/UEFI. W przypadku kdump, kexec uruchamia jądro przechwytujące.

To drugie jądro ma jedno zadanie: zebrać zawartość pamięci RAM (w której znajdują się informacje o stanie systemu w momencie awarii) i zapisać ją jako plik zrzutu (zazwyczaj w /var/crash/). Ponieważ jądro systemowe już nie działa, potrzebujemy drugiego, niezależnego środowiska, aby bezpiecznie zapisać dane.

Podstawowa konfiguracja

Konfiguracja kdump różni się w zależności od dystrybucji, ale ogólne kroki są podobne.

  1. Instalacja narzędzi: Na systemach bazujących na Red Hat (CentOS, Fedora, RHEL):

    sudo dnf install kexec-tools

    Na systemach bazujących na Debianie (Ubuntu):

    sudo apt-get install kdump-tools

  2. Rezerwacja pamięci dla jądra przechwytującego: Należy zarezerwować stały obszar pamięci RAM, który będzie niedostępny dla głównego jądra. Robi się to, dodając parametr crashkernel do linii poleceń jądra w konfiguracji bootloadera (np. GRUB).

    Przykład w /etc/default/grub:

    GRUB_CMDLINE_LINUX="... crashkernel=256M"

    Wartość 256M to typowa wielkość, ale może wymagać dostosowania w zależności od ilości RAM w systemie. Po zmianie należy zaktualizować konfigurację GRUB-a, używając odpowiedniej komendy dla swojej dystrybucji:

    • Dla systemów bazujących na Red Hat (Fedora, CentOS, RHEL): 
      sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    • Dla systemów bazujących na Debianie (Ubuntu, Debian): 
      sudo update-grub

    WAŻNE: Po aktualizacji GRUB-a, wymagany jest restart systemu, aby zmiany zostały aktywowane.

  3. Włączenie i uruchomienie usługi kdump:

    Nazwa usługi również różni się między dystrybucjami.

    • Dla systemów bazujących na Red Hat: 
      sudo systemctl enable kdump.service
sudo systemctl start kdump.service
    • Dla systemów bazujących na Debianie: Usługa często nazywa się kdump-tools. Po instalacji pakietu i restarcie, powinna być już włączona. Jej status można sprawdzić za pomocą: 
      sudo systemctl status kdump-tools.service

  4. Testowanie konfiguracji: Aby upewnić się, że kdump działa, można celowo wywołać Kernel Panic:

    # UWAGA: To polecenie natychmiast zawiesi Twój system!
# Używaj go tylko w środowisku testowym.
echo c | sudo tee /proc/sysrq-trigger

    Po restarcie systemu, w katalogu /var/crash/ powinien pojawić się nowy folder z plikiem vmcore – to jest właśnie zrzut pamięci.

Analiza zrzutu

Do analizy pliku vmcore używa się najczęściej narzędzia crash. Wymaga ono również dostępu do symboli debugowania jądra, które należy doinstalować. Nazwy pakietów z symbolami różnią się między dystrybucjami.

  • Dla systemów bazujących na Red Hat (np. Fedora): 
    sudo dnf install crash kernel-debuginfo
  • Dla systemów bazujących na Debianie (np. Ubuntu): Nazwy pakietów mogą się różnić, często jest to linux-image-$(uname -r)-dbgsym lub podobny. Należy go poszukać w repozytoriach.

Po zainstalowaniu odpowiednich pakietów, analizę można uruchomić, podając jako argumenty ścieżkę do pliku vmcore oraz do pliku vmlinux z symbolami debugowania:

# Przykład uruchomienia analizy
sudo crash /var/crash/127.0.0.1-2025-12-21-21:30:00/vmcore /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

Narzędzie crash udostępnia interaktywną powłokę, w której można wykonywać polecenia takie jak bt (backtrace, aby zobaczyć stos wywołań), log (aby przejrzeć logi jądra) czy ps (aby zobaczyć procesy działające w momencie awarii).

W połączeniu z kernel.panic do automatycznych restartów, kdump daje solidny workflow analizy post-mortem crashów jądra w produkcji.