Сохранение логов при сбоях ядра (pstore)
Функция готовится к выпуску и появится в одном из ближайших релизов ПО контроллеров: потребуются ядро Linux 6.18 и новее, а также обновлённые U-Boot и прошивка встроенного контроллера (EC 2.4.0 и новее) из того же релиза. В текущих релизах функция недоступна.
Введение
При критическом сбое ядра Linux (kernel panic) контроллер перезагружается сторожевым таймером (watchdog). Системный журнал при этом не успевает записаться на диск, поэтому раньше после перезагрузки было невозможно выяснить причину сбоя.
В контроллерах Wiren Board 7 и Wiren Board 8 сообщения ядра в момент паники сохраняются автоматически с помощью механизма ядра pstore (ramoops) и доступны после перезагрузки — в том числе после полного цикла питания, который контроллер выполняет для восстановления после сбоя.
Как это работает
- В оперативной памяти контроллера зарезервирован буфер размером 1 МиБ. Ядро постоянно пишет в него копию консольного вывода, а при панике — полный лог ядра с трассировкой.
- После записи лога ядро взводит сторожевой таймер процессора, и тот выполняет «тёплый» сброс — без снятия питания, поэтому содержимое оперативной памяти сохраняется.
- При следующей загрузке U-Boot копирует буфер на eMMC и просит встроенный контроллер (EC) выполнить полный цикл питания. Это сделано специально: после сбоя вся периферия гарантированно возвращается в исходное состояние, как при включении.
- После цикла питания U-Boot восстанавливает буфер в оперативной памяти, операционная система загружается, и сервис systemd-pstore переносит записи в постоянное хранилище.
Зависания обрабатываются так же: детекторы ядра (panic on oops, soft lockup, hung task) переводят зависание в панику, и лог сохраняется. Если же процессор завис намертво и детекторы не сработали — срабатывает сторожевой таймер встроенного контроллера (Wiren Board 7.4 и новее, Wiren Board 8): сначала он выполняет «тёплый» сброс с сохранением содержимого памяти, а если система не ожила и после него — полный цикл питания.
Если контроллер уходит в панику снова сразу после перезагрузки, защита от циклических паник отключает механизм, и контроллер восстанавливается полным циклом питания, как раньше.
Где искать логи
После загрузки сохранённые записи находятся в каталоге /var/lib/systemd/pstore/:
dmesg-ramoops-0— лог ядра, заканчивающийся трассировкой паники;console-ramoops-0— последние сообщения консоли перед сбоем.
# ls -l /var/lib/systemd/pstore/
# grep -riE 'Kernel panic|Call trace' /var/lib/systemd/pstore/
Файлы перезаписываются при следующем сбое, но полное содержимое каждой записи также попадает в системный журнал (journalctl) и хранится там до ротации журнала:
# journalctl -u systemd-pstore -o cat --output-fields=FILE
Записи входят и в архив с диагностической информацией — приложите его к обращению в техподдержку. В архиве это файлы pstore.log и pstore-recovery-history.log, а также копии каталогов /var/lib/systemd/pstore/ и /sys/fs/pstore/.
Каталог /sys/fs/pstore/ — место, куда записи попадают сразу после загрузки; после переноса сервисом systemd-pstore он обычно пуст, это нормально.
Причина включения контроллера
Причину последнего включения сообщает встроенный контроллер (Wiren Board 7.4 и новее, Wiren Board 8):
# cat /sys/bus/spi/devices/spi*/poweron_reason_str
Full power cycle request
Значения, связанные со сбоями:
| Код | Значение | Что произошло |
|---|---|---|
| 3 | Reboot | обычная перезагрузка, например командой reboot
|
| 5 | Watchdog | сторожевой таймер EC снял питание — контроллер завис, лог мог не сохраниться |
| 8 | Watchdog (warm reset) | сторожевой таймер EC выполнил «тёплый» сброс — лог сохранён |
| 9 | Full power cycle request | полный цикл питания после сохранения лога паники — ищите лог в pstore |
Системам мониторинга следует считать срабатыванием watchdog коды 5 и 8.
Отключение
Сохранение лога через полный цикл питания можно отключить переменной окружения U-Boot:
# fw_setenv wb_shuttle off
Буфер ramoops при этом продолжает работать: лог паники переживёт «тёплый» сброс, но будет потерян при снятии питания. Чтобы включить механизм обратно, удалите переменную:
# fw_setenv wb_shuttle
Ограничения
- Лог будет потерян, если внешнее питание контроллера пропадёт в первые секунды после паники — до того, как U-Boot сохранит буфер на eMMC.
- При зависании намертво сохраняются только последние сообщения консоли (
console-ramoops-0) — записи с трассировкой не будет, её пишет только само ядро при панике. Это касается лишь случаев, когда детекторы зависаний ядра (hung task, soft lockup и подобные) не сработали, — иначе зависание переводится в панику, и лог сохраняется полностью. Если контроллер завис повторно сразу после «тёплого» сброса, выполняется полный цикл питания, и лог теряется. - При частичном обновлении ПО механизм безопасно деградирует — подробности в разделе Поведение при частичном обновлении.
Поведение при частичном обновлении
Компоненты механизма — ядро Linux, загрузчик U-Boot, прошивка встроенного контроллера (EC) и пакет wb-configs — можно обновлять в любом порядке: строгая синхронность версий не требуется, любая комбинация безопасна и в худшем случае ведёт себя как ПО без этой функции.
| Обновлено | Лог паники ядра | Зависание намертво | Лог переживает пропадание питания |
|---|---|---|---|
| Только ядро | Сохраняется при «тёплом» сбросе. Со старой прошивкой EC — не гарантировано: на медленно загружающихся системах сторожевой таймер EC может снять питание раньше, чем лог запишется на eMMC. Гонку устраняет wb-configs 3.53.0 и новее или новая прошивка EC | Цикл питания, лог теряется | Нет |
| Ядро + прошивка EC | Сохраняется надёжно: если сторожевой таймер EC срабатывает во время восстановления, он выполняет «тёплый» сброс, а не снимает питание | «Тёплый» сброс, консольный лог сохраняется; при повторном зависании — цикл питания | Нет |
| Ядро + U-Boot | Сохраняется и записывается на eMMC через несколько секунд после сброса. Вместо полного цикла питания старая прошивка EC выполняет обычный сброс питания: причина включения — 3 «Reboot», а не 9 | Цикл питания, лог теряется | Да, после записи на eMMC |
| Ядро + U-Boot + прошивка EC (штатная конфигурация) | Полный сценарий: запись на eMMC, полный цикл питания, причина включения — 9 | «Тёплый» сброс, консольный лог сохраняется; при повторном зависании — цикл питания | Да, после записи на eMMC |
Обратная комбинация — новый U-Boot со старым ядром — тоже безопасна: если ядро собрано с поддержкой pstore, U-Boot сам добавляет описание ramoops-буфера в дерево устройств, и лог паники сохраняется; ядро без поддержки pstore просто игнорирует буфер, поведение остаётся прежним.
Во всех вариантах остаётся общее окно уязвимости: пропадание внешнего питания в первые секунды после паники — до записи буфера на eMMC (там, где она есть) — приводит к потере лога.