Debian 13 Kdump: налаштування та перевірка захоплення аварійних дампів (випадок №17)

Що ви створюєте: kexec + друге ядро + шлях збереження дампу

Kdump працює, залишаючи “crash kernel” у резерві. Коли працююче ядро панікує (або ви примусово викликаєте аварію для тесту),
система не виконує холодний ребут. Натомість вона використовує kexec, щоб перейти безпосередньо в crash kernel,
який запускає невеликий userspace з initramfs і записує пам’ять на диск або в мережу як vmcore.

Критична вимога: crash kernel потребує зарезервованої оперативної пам’яті, до якої аварійне ядро ніколи не має доступу.
Саме тому ви вказуєте crashkernel= в командному рядку. Якщо пропустите це, отримаєте сервіс kdump, який
“запуститься”, а аварія нічого корисного не створить. Це як встановити пожежні спринклери без тиску води.

Дві швидкі уточнення, що заощадять години:

• Kdump не виправляє аварії. Він перетворює аварію на артефакт, з яким можна працювати.
• Kdump корисний лише настільки, наскільки надійний шлях збереження дампу. Якщо ваша ціль зберігання залежить від того, що тільки-но зламалося, вам доведеться вчитися смиренню.

Факти та контекст, які справді мають значення

1. Kdump — старий механізм за мірками Linux. Підхід на базі kexec дозрів у середині 2000-х і став стандартом у корпоративних дистрибутивах.
2. «Друге ядро» — це буквально. Kdump не є функцією налагодження в тому самому ядрі; воно завантажує окреме ядро в резервну пам’ять.
3. Ранні реалізації kdump були здебільшого про діагностику апаратних збоїв. Вони допомагали вендорам відрізняти проблемну RAM/PCIe від помилок ядра без здогадок.
4. Аварійні дампи стимулювали реальну роботу над надійністю ядра. Як тільки операційні команди могли передати розробникам vmcore, “не відтворюється” стало менш модним.
5. З компресією стало важливо через зростання обсягів RAM. 512 MB дамп дратував у 2006; 512 GB дамп — подія, що шкідливо впливає на кар’єру.
6. NUMA та великі системи змінили правила підбору розміру. Раніше 128 MB могло вистачати; на сучасному залізі crash kernel може потребувати більше пам’яті, щоб завантажити драйвери й записати дамп.
7. Secure Boot ускладнює kexec в деяких середовищах. Залежно від політики, kexec може бути обмежений; перевіряйте це у моделі довіри вашої платформи.
8. Initramfs — це справжнє поле бою. Більшість збоїв kdump — не «kdump», а відсутні драйвери зберігання/мережі в crash initramfs.
9. Systemd зробив стан сервісу kdump видимим. Тепер швидко можна побачити, чи завантажено crash kernel, а не спиратися на народні прикмети.

Проєктні рішення: куди зберігати, як завантажувати, що резервувати

Виберіть ціль дампу, яка переживе ймовірні відмови

Зазвичай є три розумні місця для дампів:

• Локальна файловa система (швидко, просто): підходить, якщо диски залишаються доступними під час аварії і файлову систему можна змонтувати в crash kernel.
• Виділений локальний розділ або raw-пристрій (нудно, надійно): менше залежностей від нормального userspace; кращі шанси при складних стекових конфігураціях зберігання.
• Мережа (зазвичай NFS) (найкращий варіант, якщо місцевий сторедж може вийти з ладу): уникає складнощів локального зберігання, але crash kernel має підняти NIC і маршрути.

Якщо ви використовуєте складний стек зберігання — LUKS на LVM на MD RAID на multipath — ваш шлях дампу буде тим, що зламається.
У такому випадку невеликий виділений незашифрований розділ або NFS-ціль — дорослий вибір.
Так, це означає, що ви плануєте власний провал. Ласкаво просимо в SRE.

Підбір розміру crashkernel: краще «працює», ніж «мінімально»

На сучасних Debian-системах резервування замалої пам’яті призводить до тихих, дурних відмов: crash kernel завантажується,
але не може ініціалізувати драйвери або виділити буфери для запису дампу. Не будьте надто хитрі.

Орієнтовне практичне правило, яке зазвичай працює:

• Малі VM: 256M може вистачити.
• Звичайні сервери з типовими драйверами: 512M — безпечна база.
• Великі машини, багато модулів зберігання/мережі або сильний NUMA: 768M–1024M.

Якщо ви не можете виділити 512M RAM у 2025 році, ваша реальна проблема — бюджетування, а не kdump.

Цитата, яку можна повісити над дашбордом

Сподівання — не стратегія. — загальна максимa операційної практики (перефразовано)

Встановлення та увімкнення kdump на Debian 13

Пакети Debian можуть змінюватися між точковими випусками, але операційний шаблон лишається сталим:
встановити інструменти kdump, зарезервувати пам’ять crashkernel, згенерувати заново конфігурацію завантажувача/initramfs, переконатися, що crash kernel завантажено.

Завдання 1 — Підтвердьте ядро, інструменти initramfs та завантажувач

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

Що це означає: У вас встановлено Debian-ядро з підтримкою kexec/kdump. Якщо ви використовуєте кастомне ядро,
переконайтеся, що воно зібране з підтримкою аварійних дампів. Рішення: продовжуйте, якщо ви не впевнені, що опції 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

Що це означає: Цей хост, швидше за все, використовує конфігурацію GRUB у /etc/default/grub. Деякі налаштування Debian
використовують /etc/kernel/cmdline з flow kernel-install. Рішення: використовуйте той файл, який ваша система справді читає.

Завдання 2 — Встановіть компоненти 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) ...

Що це означає: У вас тепер є обгортки сервісів і інструменти для дампів. Рішення: наступний крок — резервування crashkernel;
без цього kdump переважно лише імітуватиме роботу.

Завдання 3 — Перевірте, чи сервіс kdump увімкнено і що він думає

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)

Що це означає: «active (exited)» — нормально; сервіс завантажує crash kernel і виходить із шляху.
Рішення: не святкуйте; потрібно підтвердити, що crash kernel реально завантажено.

Жарт №1: Kdump схожий на бекапи — у всіх є “воно”, доки воно не знадобилося, і виявляється, що вони збирали лише атмосферу.

Резервування пам’яті для crashkernel (і доказ, що вона зарезервована)

Завдання 4 — Перевірте поточний командний рядок ядра

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

Що це означає: Параметр crashkernel= відсутній. Зараз kdump, ймовірно, не зможе зарезервувати пам’ять.
Рішення: додайте crashkernel=512M (або більше, якщо у вас складний набір драйверів).

Завдання 5 — Встановіть crashkernel у GRUB і згенеруйте конфіг

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"

Що це означає: Crashkernel тепер налаштовано для майбутніх завантажень. Рішення: оновіть GRUB і перезавантажте в контрольований час.

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

Завдання 6 — Перезавантажте й підтвердіть зарезервовану пам’ять

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)

Що це означає: Резервування реальне. Якщо ви не бачите таких рядків, у вас немає kdump — лише відчуття.
Рішення: якщо резервування не вдалося, збільште розмір або виправте конфліктні параметри ядра (поширено на малих VM або через непрості карти пам’яті прошивки).

Завдання 7 — Підтвердіть, що crash kernel kexec завантажено

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

Що це означає: Інструменти бачать зарезервований регіон. Рішення: тепер перевірте шлях дампу та вміст crash initramfs.

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

Що це означає: Ця перевірка нічого не повідомляє. Деякі налаштування завантажують kernel під час старту сервісу або після конфігурації.
Рішення: перезапустіть kdump-tools і повторіть перевірку.

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

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

Що це означає: Чудово. Ваш crash kernel підготовлено. Рішення: переходьте до конфігурації цілі дампу та валідації.

Конфігурування цілі для дампів: локальний диск проти NFS (і чому це важливо)

Локальний диск у /var/crash: найпростіше, коли сторедж адекватний

За замовчуванням Debian часто зберігає дамп під /var/crash. Це нормально, якщо:
ваша root-файлова система змонтована в crash initramfs і ваш стек зберігання простий.
Для однодискового ext4 на VM зазвичай підходить.

Завдання 8 — Перевірте, чи є місце для дампів і чи файл. система цього допускає

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

Що це означає: У вас є простір. Повний дамп приблизно дорівнює обсягу RAM; makedumpfile може стискати/фільтрувати.
Рішення: якщо вільного місця мало, пишіть дамп на виділений том або NFS, і налаштуйте фільтрацію/стиск.

Завдання 9 — Перегляньте конфіг kdump-tools (і встановіть стиснення/фільтрацію)

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=""

Що це означає: MAKEDUMPFILE_ARGS контролює, скільки ви відкидаєте. -d 31 — поширена маска для великих відкидань сторінок.
Рішення: тримайте фільтрацію ввімкненою, якщо у вас немає специфічної потреби в повних дампах і ви можете їх надійно зберігати.

NFS як ціль дампу: менше драйверів зберігання, більше мережевих налаштувань

NFS — мій дефолт, коли локальний стек зберігання складний (LUKS-на-всьому, екзотичні RAID-контролери, завантаження з iSCSI).
Це переносить залежність від “чи зможемо ми змонтувати root FS в поламаному світі” до “чи зможемо ми підняти мережу в crash kernel”.
Зазвичай це простіше зробити детерміновано, особливо на фіксованому VLAN.

Завдання 10 — Налаштуйте NFS-ціль для дампу (приклад)

Це прикладний стиль конфігурації. Ваші точні ключі файлів можуть відрізнятися залежно від версії пакета Debian, але операційна вимога стабільна: crash initramfs має знати, куди писати і як туди дістатися.

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

Для NFS зазвичай встановлюють директорію дампів як шлях, змонтований через NFS та доступний у середовищі crash.
Поширений підхід — створити mountpoint і звичайний запис у fstab для видимості у звичайному userspace, а потім переконатися, що crash initramfs також має необхідні компоненти.
(Не припускайте, що crash initramfs використовує ваші звичні монтовані точки. Це маленький окремий світ.)

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)

Що це означає: Звичайний userspace може дістатися до NFS-експорту. Рішення: тепер потрібно переконатися, що crash initramfs може зробити те саме
(драйвери, IP-конфіг, маршрут, клієнтські компоненти 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"

Що це означає: Ви спрямували дампи до NFS-монту. Рішення: перебудуйте kdump initramfs і перевірте, що crash kernel і далі завантажується.

Перевірте ядро kdump та initramfs перед тим, як щось падатиме

Найшвидший спосіб здаватися дурним — “протестувати kdump” у робочий час без перевірки того, чи може crash-оточення записати дамп.
Ставтеся до цього як до міграції: зробіть сухий прогін того, що можна, доведіть наявність компонентів, а потім робіть руйнівний тест із планом відкату.

Завдання 11 — Перестворіть initramfs і перезапустіть 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

Що це означає: Після змін конфігурації crash kernel усе ще підготовлено. Рішення: перевірте вміст initramfs,
особливо модулі зберігання та NIC.

Завдання 12 — Перегляньте kdump initramfs на наявність критичних модулів (зберігання і мережа)

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

Що це означає: Ваш initramfs містить принаймні деякі потрібні компоненти. Відсутні драйвери тут — причина №1, чому дампи не з’являються.
Рішення: якщо ви покладаєтеся на ixgbe, bnx2, megaraid_sas, nvme,
dm_crypt тощо, переконайтеся, що їх включено.

Завдання 13 — Переконайтеся, що sysctl налаштовані для фактичної аварії при проблемах

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

Що це означає: Система буде панікувати при oops (часто бажано для захоплення дампів), але не перезавантажуватиметься автоматично після паніки.
Рішення: у продуктивному середовищі встановіть kernel.panic=10 (або схоже), щоб crash kernel встиг записати дамп, а потім перезавантажити систему.
Якщо ви поставите 0 назавжди, можете отримати мертву хост-машину, яка потребуватиме ручного втручання.

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

Завдання 14 — Підтвердіть, що ваша директорія дампів записувана і стабільна

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

Що це означає: У цьому прикладі NFS-монт був доступний лише для читання (ro у fstab). Це самообріз.
Рішення: виправте опції монтування; ваша ціль дампу має бути записуваною, очевидно.

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

Що це означає: Ваша ціль записувана у звичайному userspace. Рішення: цього недостатньо — crash kernel теж має бути здатним записувати,
але це усуває одну просту причину відмови.

Завдання 15 — Сухий прогін прав запису і поведінки імен

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

Що це означає: Структура директорій працює і сервер приймає запис. Рішення: переходьте до контрольованого тесту аварії
лише коли у вас є доступ до консолі (IPMI/iDRAC/віртуальна консоль) і вікно технічного обслуговування.

Спровокуйте контрольовану тестову аварію та підтвердіть захоплення vmcore

Тестова аварія kdump за визначенням руйнівна. Робіть це серйозно:
вікно обслуговування, доступ до консолі, відкритий інцидент, хтось, хто дивиться на ціль дампу, і план відкату
(мінімум: видалити crashkernel=, якщо це буде спричиняти проблеми з завантаженням, хоча це рідко).

Жарт №2: Примусова аварія ядра в продуктиві схожа на тестування пожежної сигналізації підпалом кухні — ефективно, але корисно мати вогнегасник.

Завдання 16 — Переконайтеся, що SysRq увімкнено (потрібно для «більш безпечного» тригера)

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

Що це означає: SysRq увімкнено (176 дозволяє підмножину, включно з тригером аварії на багатьох системах).
Рішення: якщо значення 0, тимчасово увімкніть його для тесту, потім вирішіть політику надовго.

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

Завдання 17 — Запустіть live-лог на ціль дампу (на NFS-сервері або на хості)

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

Що це означає: Ви можете бачити появу нових директорій. Рішення: тримайте цей вигляд відкритим під час тесту; це ваше джерело істини.

Завдання 18 — Викличте аварію через SysRq

Це негайно спричинить крах ядра. Не робіть цього по SSH-сесії, яку ви не готові втратити.
За можливості використовуйте доступ до консолі.

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

Що ви повинні побачити далі: хост панікує, потім kexec завантажує crash kernel, який записує дамп, після чого відбувається перезавантаження.
Час залежить від розміру RAM і швидкості цілі запису. Якщо ви зарезервували 512M, але маєте 256G RAM і без фільтрації — приготуйте перекуси.

Завдання 19 — Після перезавантаження підтвердіть, що дамп записано

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

Що це означає: Це і є успіх: vmcore плюс метадані. Рішення: якщо vmcore відсутній,
переходьте одразу до розділу “Швидка діагностика” та таблиці типових помилок нижче.

Завдання 20 — Підтвердіть у логах, що kdump виконався (журнал за післяаварійний завантаження)

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.

Що це означає: Логи попереднього завантаження показують завантаження crash kernel. Це не доводить, що дамп записано (список файлів доводить це),
але підтверджує, що шлях підготовки працює. Рішення: якщо тут показано “failed to load crash kernel”, виправте це перед подальшими тестами.

Елементарна перевірка дампу та базовий аналіз

Вам не потрібно бути інженером ядра, щоб підтвердити, що vmcore реальний і внутрішньо консистентний.
Мета — операційна: переконатися, що ви захопили пам’ять і можете витягти backtrace за потреби.

Завдання 21 — Визначте формат дампу і підтвердіть, що це не порожній брак

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)

Що це означає: Це ELF core-файл, як очікувалося. Рішення: переходьте до інструментів аналізу, якщо потрібно дебажити; інакше — архівуйте.

Завдання 22 — Підтвердіть версію ядра для підбору символів

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

Що це означає: Вам потрібні відповідні символи (debug-пакети) для глибокого аналізу. Рішення: у серйозних середовищах зеркальте debug-пакети
внутрішньо, щоб мати можливість аналізувати через тижні після оновлень.

Завдання 23 — Швидкий “smoke” тест із crash (необов’язково, але рекомендовано)

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>

Що це означає: Ви можете відкрити дамп. Це операційна ціль. Рішення: якщо це не працює з помилкою “cannot find vmlinux”,
створіть процес збереження debug-символів для розгорнутих ядер (або хоча б для тих, що важливі).

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

Що це означає: Backtrace чітко показує крах, спричинений SysRq — саме те, що ми зробили. Це чистий тест.
Рішення: ви підтвердили end-to-end захоплення kdump і базову придатність для пост-мортем аналізу.

Швидкий план діагностики

Коли kdump “не працює”, не бешкетуйте. Діагностуйте в порядку, що найшвидше звужує простір пошуку.
Це послідовність, якою я користуюся під час чергового дзвінка.

1) Чи ядро зарезервувало пам’ять crashkernel?

• Перевірте /proc/cmdline на наявність crashkernel=.
• Перевірте dmesg | grep -i crashkernel на рядки резервування.

Якщо резервування відсутнє: дампу не буде. Виправте параметри завантажувача і перезавантажте. Все інше — відволікання.

2) Чи дійсно завантажено crash kernel?

• Запустіть sudo kexec -p -s, щоб перевірити, чи завантажено crash kernel.
• Перевірте systemctl status kdump-tools і journalctl -u kdump-tools.

Якщо не завантажено: виправляйте конфігурацію kdump-tools, генерацію initramfs або відсутні образи ядер.

3) Чи може аварійне оточення доступитися до цілі дампу?

• Локальний диск: переконайтеся, що потрібні блочні драйвери й файлові системи є в initramfs; перевірте, що монтаж відбувся.
• NFS: переконайтеся, що драйвер NIC + IP-конфіг + маршрут + клієнт NFS присутні в initramfs.

Якщо ціль недоступна: налаштуйте hooks initramfs, додайте модулі, спростіть шлях дампу.
Не оптимізуйте зарано. Спочатку зробіть, щоб працювало.

4) Чи занадто агресивна фільтрація makedumpfile?

• Якщо ви отримуєте крихітний vmcore, який не відкривається, перевірте MAKEDUMPFILE_ARGS.
• Тимчасово зменшіть фільтрацію для тестової аварії, якщо потрібно.

5) Якщо все виглядає правильно, але дампи зникають

• Розгляньте: Secure Boot / обмеження lockdown для kexec, прошивкові особливості, проблеми IOMMU або скидання зберігання.
• Спробуйте простішу ціль дампу (виділений незашифрований ext4-розділ) як контрольний експеримент.

Типові помилки: симптом → причина → виправлення

Немає vmcore після аварії, і в логах нічого очевидного

Симптоми: Ви примусово викликаєте аварію; хост перезавантажується; директорія дампів залишається порожньою.

Причина: Відсутнє резервування crashkernel пам’яті або резервування не вдалося.

Виправлення: Додайте crashkernel=512M (або більше), перезавантажте, підтвердьте через dmesg | grep -i crashkernel.

Сервіс kdump “active”, але kexec -p -s каже, що crash kernel не завантажено

Симптоми: systemd показує, що kdump-tools успішний; kexec стверджує, що нічого не завантажено.

Причина: kdump-tools не завантажив crash kernel через відсутнє резервування або неправильно згенерований initramfs.

Виправлення: Спочатку виправте crashkernel=, потім update-initramfs -u -k all, перезапустіть kdump-tools і перевірте знову.

Директорія дампів існує, але лише метадані, без vmcore

Симптоми: Ви бачите dmesg.txt або інформаційні файли, але немає vmcore.

Причина: Запис дампу зупинився посеред процесу: закінчився простір, збій NFS, відсутній драйвер або crash kernel закінчив пам’ять.

Виправлення: Перевірте місце, стабільність NFS, збільште розмір crashkernel, переконайтеся, що NIC/сторедж модулі є в initramfs.

Дамп записано локально, але файлова система пошкоджена після цього

Симптоми: vmcore є, але при наступному завантаженні запускається fsck або виникають помилки.

Причина: Запис дампу на ту саму файлову систему, яка вже була ненадійною, або аварія сталася під час запису і відновлення журналу викликало проблеми.

Виправлення: Пишіть дамп на виділений розділ або NFS. Сприймайте /var як недовірену під час катастроф.

Дамп на NFS ніколи не з’являється; локальні дампи працюють

Симптоми: Захоплення на локальний диск працює; NFS-ціль залишається порожньою після тестових аварій.

Причина: Crash kernel не може підняти мережу (відсутній модуль NIC, немає IP-конфіг, відсутній маршрут, потрібен VLAN).

Виправлення: Переконайтеся, що драйвер NIC є в initramfs; налаштуйте статичну IP для crash kernel; уникайте залежності від складних мережевих сервісів (DHCP, 802.1X).

Система зависає при аварії замість перезавантаження в crash kernel

Симптоми: Ви викликаєте аварію; хост зависає; немає перезавантаження.

Причина: Блокування апаратури/прошивки, проблеми з NMI або шлях паніки не може виконати kexec; іноді watchdog не налаштовано.

Виправлення: Увімкніть апаратний watchdog, якщо доступний; протестуйте інші тригери аварії; розгляньте відключення проблемних налаштувань IOMMU для тесту; перевірте доступ до консолі.

vmcore існує, але інструмент crash не читає його

Симптоми: file показує core-файл, але crash видає помилки.

Причина: Відсутні відповідні debug-символи для точної збірки ядра, що породила дамп, або дамп обрізано.

Виправлення: Зберігайте debug-пакети для розгорнутих ядер; перевірте розмір дампу та цілісність сховища; повторіть тест з менш агресивною фільтрацією makedumpfile.

Після увімкнення crashkernel система не завантажується або пам’яті замало

Симптоми: OOM, контейнери працюють гірше або завантаження не проходить на системах з малою пам’яттю.

Причина: Резервування занадто великого обсягу в обмеженій VM або конфліктна мапа пам’яті прошивки.

Виправлення: Використайте менше значення (256M) або параметри з діапазоном пам’яті; підтвердьте резервування через dmesg.

Чеклісти / покроковий план

Мінімальний план «Мені просто потрібно, щоб працювало» (локальний диск)

1. Встановіть: kdump-tools, kexec-tools, makedumpfile.
2. Додайте crashkernel=512M в GRUB, запустіть update-grub, перезавантажте систему.
3. Підтвердіть резервування: dmesg | grep -i crashkernel.
4. Перевірте завантаження crash kernel: kexec -p -s.
5. Переконайтеся, що /var/crash має місце і доступна для запису.
6. Протестуйте аварію під час вікна обслуговування: echo c > /proc/sysrq-trigger.
7. Після перезавантаження перевірте, що /var/crash містить vmcore.

План, придатний для продакшн (ціль NFS)

1. Налаштуйте NFS-експорт, присвячений дампам (права, політика квот, збереження).
2. Змонтируйте його в звичайному userspace для видимості, але не припускайте, що crash kernel використовує те саме монтування.
3. Встановіть KDUMP_COREDIR на потрібний шлях і перебудуйте initramfs.
4. Переконайтеся, що initramfs містить драйвер NIC і клієнтські компоненти NFS (перевірте через lsinitramfs).
5. Встановіть kernel.panic=10, щоб система перезавантажувалася після дампу.
6. Зробіть контрольовану аварію і спостерігайте за NFS-директорією в реальному часі.
7. Відкрийте дамп за допомогою crash хоча б один раз. Доведіть, що його можна аналізувати, а не просто що “файл існує”.

Нотатки для зміни управління (що я пишу в тикеті)

• Ризик: резервування crashkernel зменшує доступну RAM; рідкісні проблеми з завантаженням на нестандартній прошивці.
• Відкат: видалити crashkernel= з GRUB і перезавантажити.
• Перевірка: dmesg резервування, crash kernel завантажено, тестова аварія створює vmcore.
• Операційні дії: політика зберігання, права доступу і наявність символів для аналізу.

Три корисні корпоративні історії (дуже правдоподібні)

1) Інцидент через хибне припущення

Команда розгорнула kdump по флоту після паніки ядра, яка вивела з ладу ноду бази даних, і всі в післямортемі лише знизували плечима.
Вони встановили пакети, увімкнули сервіс і перевірили, що systemctl status зелений.
Потім оголосили перемогу. Тікет закрили зі скріншотом. Ніхто не протестував крах.

Через місяці продуктивна машина почала панікувати під великим навантаженням мережі. Цього разу вони подумали: “У нас є kdump.”
Дочекалися перезавантаження, зайшли в систему і зазирнули в /var/crash. Порожньо. Навіть заглушки не було.
Тема ескалації почалася з знайомої фрази: “Але ми ж його увімкнули.”

Корінь проблеми був ганебно простий. У параметрах завантажувача ніколи не було crashkernel=.
Сервіс мов би “працює” у сенсі, що він запускався й виходив успішно, але йому було нічого завантажувати.
Припущення, що встановлення kdump-tools автоматично резервує пам’ять — хибне.

Виправлення було простим, але урок — ні: будь-яка функція надійності, яку не верифіковано end-to-end, — це театр.
Вони додали crashkernel=512M, перезавантажили хости пачками і провели одну контрольовану аварію на стійку під час вікна обслуговування.
Після цього, коли баг драйвера мережі повторився, у них був vmcore і реальний backtrace. Розмова з вендором одразу стала іншою.

2) Оптимізація, яка вдарила по вас

Інша організація мала аналітичні машини з великою пам’яттю. Хтось вирішив, що дампи занадто великі і повільні, тому вони “оптимізували”
makedumpfile, щоби скидати більше сторінок і сильніше стискати. Дампи стали менші. Усі аплодували.
Вони ще зменшили crashkernel з 1G до 256M, бо “воно завантажується і ми хочемо повернути RAM”.

Потім паніка трапилася під час шторму скидів контролера зберігання. Kdump іноді писав крихітний vmcore — кілька мегабайт — іноді нічого.
Коли дамп записувався, crash не міг витягти корисні стеки, бо ключові області пам’яті були відфільтровані.
Оптимізований набір дав гарний артефакт, що містив операційну еквівалентність lorem ipsum.

Розслідування виявило дві складові помилки. Менший crashkernel означав, що аварійне оточення виявилося обмеженим по пам’яті при завантаженні драйверів зберігання та буферизації записів.
До того ж агресивна фільтрація видалила структури ядра, потрібні для розслідування (стан I/O-шляху).

Вони повернулися до консервативного базового рівня: crashkernel 768M і помірна фільтрація.
Дампи знову стали більші. Але вони стали надійними й корисними. Справжня оптимізація не в стисканні; вона в перенесенні дампів на NFS, щоб локальні проблеми зі стореджем не впливали.
Налаштування продуктивності — добре, але тільки після забезпечення коректності.

3) Нудна, але правильна практика, яка врятувала день

Платформна команда мала змішаний флот Debian і суху політику: кожне оновлення ядра також має архівувати відповідні debug-символи
(або принаймні робити їх доступними) для двох попередніх версій. Ніхто не кричав від радості — це додаткове сховище,
додаткові кроки, додаткова бюрократія.

Одної ночі хост панікував так, що впав критичний внутрішній сервіс. Kdump спрацював і записав vmcore на NFS.
Оні-кол зняв дамп у VM для аналізу, запустив crash і відразу отримав чіткий backtrace, що вказував на конкретний підсистему.
Це не був повний root-cause, але було достатньо, щоб переадресувати інцидент правильній команді і застосувати пом’якшення.

Ключове — наявність символів перетворила “маємо vmcore” на “маємо відповідь”. Без символів у вас був би просто бітовий блоб.
З символами — імена функцій і правдоподібний наратив відмови. Нудна практика — зберігати debug-артефакти у відповідності з розгорнутими ядрами —
змінила двогодинний інцидент на двогодинне вирішення замість дворічних суперечок.

Ніхто не писав святкового емейлу про політику після цього. Саме так ви розумієте, що це була справжня інженерія.

Питання та відповіді

1) Чи справді потрібно перезавантажувати систему після додавання crashkernel=?

Так. Резервування пам’яті відбувається під час завантаження. Без перезавантаження немає зарезервованої пам’яті, а отже — немає надійного захоплення аварійних дампів.

2) Як я можу знати, що kdump зараз справді готовий?

Перевірте обидва: dmesg | grep -i crashkernel (резервування) і sudo kexec -p -s (crash kernel завантажено).
“Сервіс увімкнено” — це не доказ.

3) Який найобережніший спосіб протестувати kdump?

Використовуйте тригер SysRq (echo c > /proc/sysrq-trigger) у вікні обслуговування з доступом до консолі.
Перевірте, що дамп з’явився і його можна прочитати через crash.

4) Який розмір crashkernel слід встановити на Debian 13?

Почніть з 512M для типових серверів. Якщо у вас великі потреби по драйверах зберігання/мережі, використовуйте 768M–1024M.
Для малих VM 256M може бути граничним — тестуйте.

5) Чи можна писати дамп на зашифровану файлову систему (LUKS)?

Можна, але це крихке: crash initramfs має розблокувати LUKS, що означає наявність ключів у безперервному режимі.
Для більшості середовищ краще писати на незашифрований виділений розділ або на NFS.

6) Чи працюватиме kdump, якщо аварію спричинив драйвер зберігання?

Можливо. Якщо ваша ціль дампу залежить від того самого стеку драйвера, що щойно зламався, ви ризикуєте.
Саме тому NFS або простий виділений локальний розділ часто кращі.

7) Чому vmcore занадто великий?

Ймовірно ви записуєте більшість RAM без суттєвої фільтрації/стиснення. Налаштуйте MAKEDUMPFILE_ARGS для фільтрації сторінок
і забезпечте ціль достатнього розміру для найгіршого випадку. Часто “занадто великий” — проблема політики зберігання, а не kdump.

8) Чому crash скаржиться на відсутні символи?

Вам потрібен відповідний vmlinux з debug-символами для точної версії ядра, що згенерувало дамп.
Налаштуйте процес збереження або отримання цих артефактів після оновлень.

9) Чи слід встановлювати kernel.panic_on_oops=1?

У багатьох продакшн-середовищах — так: oops часто означає пошкоджений стан ядра, і продовження роботи може спричинити тихе псування даних.
Якщо ви рішенням вмикаєте panic-on-oops, поєднуйте це з kdump і розумним таймаутом kernel.panic.

10) Чи змінюють щось контейнери або віртуальні машини?

Контейнери не контролюють ядро хоста, тож kdump — це функція хоста. У VM kdump зазвичай працює добре — пам’ятайте, що гостьовій ОС теж потрібно зарезервувати RAM для crashkernel,
а ваш гіпервізор може впливати на швидкість запису дампів на віртуальний диск або мережу.

Наступні кроки, які варто виконати

• Виберіть ціль дампу, орієнтуючись на сценарії відмов, а не на зручність. Якщо сторедж складний — обирайте NFS або виділений розділ.
• Стандартизуйте розміри crashkernel. Починайте з 512M; задокументуйте, коли потрібно більше.
• Проведіть одну контрольовану аварію для кожного типу платформи. Різні NIC/RAID контролери поводяться по-різному в crash kernel.
• Зробіть наявність символів політикою. Якщо ви не можете відкрити дамп через два тижні, ви збираєте дорогі паперові ваги.
• Автоматизуйте перевірку. Хоча б оповістіть, якщо crashkernel не зарезервовано або crash kernel не завантажено.
• Опишіть операторський рукопис. Хто витягає vmcore, де він зберігається, як працює зберігання, хто має доступ.

Kdump — це функція надійності, яка виправдовує себе лише після всіх інших відмов. Це не причина відкладати.
Це причина зробити все правильно, протестувати і зробити процес нудним.