PSTORE-CRASH Linux / DevOps

Linux Kernel failure in previous boot: диагностика сбоев через pstore

Обновлено: 14.09.2026 · Официальная база знаний

Симптомы внезапной перезагрузки Linux-сервера

Сервер под управлением Linux внезапно уходит в перезагрузку без штатных записей в journald или syslog. При следующем старте в логах появляется уведомление: Kernel failure in previous boot или создаются дампы памяти ядра. Стандартный /var/log/messages обрывается на нормальной работе сервисов.

Механизм логирования	Локация данных	Назначение
pstore / ramoops	/sys/fs/pstore/dmesg-*	Сохранение буфера dmesg в зарезервированной энергонезависимой памяти RAM/NVRAM
kdump / kexec	/var/crash/127.0.0.1-*/vmcore	Запуск вторичного ядра аварийного захвата для сброса полного дампа памяти
IPMI SEL	ipmitool sel list	Фиксация аппаратного сторожевого таймера (Watchdog) и NMI-прерываний

Пошаговая диагностика сбоя ядра через pstore

Проверьте наличие точки монтирования pstore: если ядро было скомпилировано с опцией CONFIG_PSTORE=y, псевдофайловая система монтируется автоматически:
```
mount | grep pstore
# Если не смонтирована, монтируем вручную:
mount -t pstore pstore /sys/fs/pstore
```

Проанализируйте сохраненные аварийные логи предыдущего падения:

ls -la /sys/fs/pstore/
# Просмотр последнего сообщения Kernel Panic / Oops:
cat /sys/fs/pstore/dmesg-ramoops-0

Настройка постоянного захвата ramoops через параметры ядра: если pstore пуст, добавьте резервирование участка памяти в конфигурационный файл загрузчика /etc/default/grub:
```
GRUB_CMDLINE_LINUX="... ramoops.mem_address=0x80000000 ramoops.mem_size=0x100000 ramoops.record_size=0x40000"
```
Обновите конфиг загрузчика: update-grub или grub2-mkconfig -o /boot/grub2/grub.cfg.

Включение kdump для генерации полного дампа vmcore:

# Включение службы на RHEL/CentOS/Rocky:
systemctl enable --now kdump.service
# Анализ полученного дампа утилитой crash:
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Обратите внимание: Записи в каталоге /sys/fs/pstore/ не удаляются автоматически. После расследования скопируйте файлы логов и очистите каталог (rm -f /sys/fs/pstore/*), чтобы освободить буфер NVRAM для следующих инцидентов.

Практический опыт инженера: Практика ITSTM: При анализе падений ядра с кодами 'Oops: 0002' или 'general protection fault' в виртуальных машинах KVM/Proxmox первым делом проверьте хост-сервер на ошибки битой памяти ECC (edac-util -v) и отключите опцию Nested Virtualization.

Частые вопросы (FAQ)

Что такое ramoops в Linux?

Ramoops — это драйвер подсистемы pstore, который логирует сообщения dmesg о сбоях ядра в заранее определенную область оперативной памяти, которая не перезаписывается контроллером при теплой перезагрузке (warm reboot).

Почему при падении ядра обычный syslog ничего не записывает?

В момент Kernel Panic прерывания блокируются, планировщик останавливается, а драйверы дисков прекращают ввод/вывод. Демоны rsyslog/journald физически не успевают записать буферы на диск.

Как искусственно сымитировать падение ядра для проверки сбора дампов?

Используйте SysRq-триггер: echo 1 > /proc/sys/kernel/sysrq, затем echo c > /proc/sysrq-trigger (Внимание: сервер немедленно упадет в Kernel Crash!).

Где еще на сервере могут храниться логи падений, если pstore пуст?

Проверьте аппаратный журнал BMC через консоль IPMI командой ipmitool sel elist.