RTFM · Troubleshooting
Kernel failures
Panic during operation, oops flooding logs, or a freshly compiled kernel refusing to boot: diagnose, capture, recover, repeat.
Capture the panic first
An uncaptured panic teaches nothing. Ensure console output persists — serial console ideal, netconsole over LAN if remote.
Configure serial console BEFORE problems occur: console=ttyS0,115200 appended to the kernel command line. Retrofitting it mid-emergency rarely survives your mood.
Newly built kernel will not boot
- Storage driver compiled as module but absent from initramfs — the classic first custom-kernel failure.
- Missing devtmpfs support leaves early userspace blind.
- CPU feature mismatch: kernel built for the wrong microarchitecture level.
- Module signature enforcement refusing necessary modules.
Keep the previous known-good kernel entry selectable in GRUB; never delete the fallback until the new kernel proves itself across several reboots.
Spontaneous oops during runtime
dmesg | grep -iE 'oops|bug|warn|segfault' | tail
dmesg -T | lessA single transient oops under memory pressure often resolves after a memory test; a recurring identical backtrace is reproducible — capture it and simplify reproduction.
Prove it works: kernel stability documented
the failing kernel entry remains preserved in GRUB alongside its command line, plus captured panic text for analysis or reporting.
Did we miss something?
If this page left something unanswered, found an error, or there is another subject you would like documented, tell us. Saphira’s documentation grows from real problems people need to solve.
Send feedback or request a new section →
Prefer not to do it yourself?
Everything needed to do the work yourself is documented here and remains free — we charge for human time, not for withholding knowledge. Sometimes the missing resource is simply time. The same people who build Saphira can provide paid professional help with implementation, migration, troubleshooting and administration.