Problem
When a Bluefin machine panics (kernel crash, hard lockup, panic during s2idle sleep), there is currently no crash dump infrastructure configured. The system reboots silently and the panic is completely invisible to the user and to developers.
Observed on: Framework Laptop 13 (Intel Core Ultra Series 1), kernel 6.19.14-101.fc43.x86_64. Machine panicked during s2idle. Boot ended at 15:20:37 with PM: suspend entry, no resume recorded, next boot started 17 minutes later. /sys/fs/pstore/ empty, /var/crash/ empty. Zero forensic evidence.
What pstore does
pstore (persistent store) reserves a memory region that survives a reboot. When the kernel panics, it writes the oops/backtrace there before resetting. On the next boot the data appears under /sys/fs/pstore/ as readable files — giving the user something concrete to attach to a bug report.
Options
Option A — ramoops (preferred for laptops)
Reserve a small RAM region for crash logs. Configured via kernel args or modprobe:
# /etc/modprobe.d/ramoops.conf
options ramoops mem_size=2097152 record_size=65536 console_size=32768
Pros: no disk I/O required, works even if storage is wedged, fast.
Cons: requires a RAM region the BIOS won't clear — needs testing per platform.
Option B — efi-pstore
Uses EFI NVRAM variables. Available on any UEFI system with no extra config.
Cons: size-limited (~64KB), NVRAM write cycles, may not fire for very hard panics.
Option C — kdump
Captures full vmcore to /var/crash/. Requires crashkernel= kernel arg and kdump.service.
Pros: full memory dump, most diagnostic value.
Cons: reserved memory overhead, longer reboot on crash, requires more setup.
Recommendation
Start with efi-pstore (zero config on UEFI systems) + Option A as an opt-in or default. Even a small ramoops region gives ujust report something to include (see projectbluefin/bonedigger issues 11 and 12 — crash detection in ujust report is planned).
Acceptance criteria
Problem
When a Bluefin machine panics (kernel crash, hard lockup, panic during s2idle sleep), there is currently no crash dump infrastructure configured. The system reboots silently and the panic is completely invisible to the user and to developers.
Observed on: Framework Laptop 13 (Intel Core Ultra Series 1), kernel 6.19.14-101.fc43.x86_64. Machine panicked during s2idle. Boot ended at 15:20:37 with
PM: suspend entry, no resume recorded, next boot started 17 minutes later./sys/fs/pstore/empty,/var/crash/empty. Zero forensic evidence.What pstore does
pstore (persistent store) reserves a memory region that survives a reboot. When the kernel panics, it writes the oops/backtrace there before resetting. On the next boot the data appears under
/sys/fs/pstore/as readable files — giving the user something concrete to attach to a bug report.Options
Option A — ramoops (preferred for laptops)
Reserve a small RAM region for crash logs. Configured via kernel args or modprobe:
Pros: no disk I/O required, works even if storage is wedged, fast.
Cons: requires a RAM region the BIOS won't clear — needs testing per platform.
Option B — efi-pstore
Uses EFI NVRAM variables. Available on any UEFI system with no extra config.
Cons: size-limited (~64KB), NVRAM write cycles, may not fire for very hard panics.
Option C — kdump
Captures full vmcore to
/var/crash/. Requirescrashkernel=kernel arg andkdump.service.Pros: full memory dump, most diagnostic value.
Cons: reserved memory overhead, longer reboot on crash, requires more setup.
Recommendation
Start with efi-pstore (zero config on UEFI systems) + Option A as an opt-in or default. Even a small ramoops region gives
ujust reportsomething to include (see projectbluefin/bonedigger issues 11 and 12 — crash detection in ujust report is planned).Acceptance criteria
ujust enable-crash-dumpujust reportis able to include pstore data when present (tracked separately in bonedigger)