Kernel Panics

From ArchWiki
Revision as of 20:37, 8 October 2017 by Mcnster (talk | contribs) (Added 2nd level section 'Examine panic message'.)
Jump to: navigation, search

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Last major update to this page was November 2009. (Discuss in Talk:Kernel Panics#)

Merge-arrows-2.pngThis article or section is a candidate for merging with General troubleshooting.Merge-arrows-2.png

Notes: If you remove all the excess verbosity and duplicate instructions, a few paragraphs remain which can go to General troubleshooting (Discuss in Talk:Kernel Panics#)

A kernel panic occurs when the Linux kernel enters an unrecoverable failure state. The state typically originates from buggy hardware drivers resulting in the machine being deadlocked, non-responsive, and requiring a reboot. Just prior to deadlock, a diagnostic message is generated, consisting of: the machine state when the failure ocurred, a call trace leading to the kernel function that recognized the failure, and a listing of currently loaded modules. Thankfully, kernel panics don't happen very often using mainline versions of the kernel--such as those supplied by the official repositories--but when they do happen, you need to know how to deal with them.

Note: Kernel panics are sometimes referred to as oops or kernel oops. While both panics and oops occur as the result of a failure state, an oops is more general in that it does not necessarily result in a deadlocked machine--sometimes the kernel can recover from an oops by killing the offending task and carrying on.
Tip: Pass the kernel parameter oops=panic at boot or write 1 to /proc/sys/kernel/panic_on_oops to force a recoverable oops to issue a panic instead. This is advisable is you are concerned about the small chance of system instability resulting from an oops recovery which may make future errors difficult to diagnose.

Examine panic message

If a kernel panic occurs very early in the boot process, you may see a message on the console containing "Kernel panic - not syncing:", but once Systemd is running, kernel messages will typically be captured and written to the system log. However, when a panic occurs, the diagnostic message output by the kernel is almost never written to the log file on disk because the machine deadlocks before system-journald gets the chance. Therefore, the only way to examine the panic message is to view it on the console as it happens (without resorting to setting up a kdump crashkernel). You can do this by booting with the following kernel parameters and attempting to reproduce the panic on tty1:

systemd.journald.forward_to_console=1 console=tty1
Tip: In the event that the panic message scrolls away too quickly to examine, try passing the kernel parameter pause_on_oops=seconds at boot.