A kernel panic is what happens when the Linux kernel hits a fatal, unrecoverable error and halts the entire machine on purpose instead of carrying on with corrupted state. The usual triggers are failing RAM, a buggy or mismatched driver, a corrupted initramfs or root filesystem, a failed kernel upgrade, overheating or a dying disk, and genuine bugs in the kernel itself.
That last part surprises people. A panic is not the operating system falling over the way a crashed app does. It is the kernel deciding it can no longer trust what it is looking at, so it stops every processor at once. If you just watched it happen, the most valuable thing you can do right now is photograph the screen before you power the machine off, because rebooting erases most of the evidence.
The causes fall into six families, and the rest of this guide walks through each one:
- Hardware faults — bad RAM, a dying disk, overheating, unstable power, ECC or machine check exceptions, and firmware trouble.
- Driver and kernel module bugs — out-of-tree modules, proprietary GPU drivers, and modules built against the wrong kernel version.
- Kernel bugs — race conditions, broken invariants caught by BUG(), and regressions in a specific kernel release.
- Filesystem and init failure — a root filesystem that will not mount, a damaged initramfs, or an init process that dies at startup.
- Boot and upgrade damage — a half-finished kernel update, a stale bootloader, or bad boot parameters.
- Resource exhaustion and deliberate triggers — an out-of-memory or out-of-disk condition, or an explicit call to panic() from software.
I have pulled these apart in the order they are worth checking, because the fastest route to an answer is almost always the cheapest test first.
Table of Contents
- What Is a Linux Kernel Panic?
- What Causes a Kernel Panic in Linux?
- Hardware and Firmware Failures
- Bad RAM and memory corruption
- Dying disks, overheating and unstable power
- Machine check exceptions, ECC and firmware
- Drivers, Modules, and Kernel Bugs
- Faulty and out-of-tree drivers
- Mismatched kernels and DKMS after an upgrade
- Kernel bugs, races and corrupted memory
- Filesystem, Disk, and Boot Problems
- Attempted to kill init and a broken root filesystem
- Corrupted initramfs and bad boot parameters
- Failed kernel upgrades and bootloader damage
- How to Diagnose a Kernel Panic Step by Step
- Capture the panic text before you reboot
- Read the taint flags
- Check the phase: pre-boot, early boot or runtime
- Pull the logs for the boot that failed
- Test hardware, then compare against a known-good kernel
- How to Fix Common Linux Kernel Panic Triggers
- Bad RAM
- Corrupted filesystem
- Failed kernel upgrade
- Driver and module problems
- Overheating, power and firmware
- When Is the Kernel Panic Not the Real Problem?
- Softlockup and hardlockup
- OOM kills and init-system failures
- Graphics stalls and hardware lockups
- Frequently Asked Questions
- What is the root cause of a kernel panic?
- Can you recover from a kernel panic?
- How serious is a kernel panic?
- Should I test RAM first when my machine panics?
- What does u0022Kernel panic – not syncingu0022 mean?
- What information should I include when asking about a kernel panic?
- Conclusion
What Is a Linux Kernel Panic?
A kernel panic is the kernel’s deliberate, unrecoverable shutdown. When kernel code hits an error it cannot safely continue from, it prints a report to the console and calls panic(), which halts all CPUs immediately rather than let a fault propagate into the rest of the system.
The reasoning is protective. A kernel with corrupted memory writing to your disk can destroy every filesystem it touches. Stopping is the safer failure mode, which is also why a panic is annoying but not, by itself, a sign your data is gone.
Not everything printed on screen with a traceback counts as a panic. Three terms get mixed up constantly:
- Oops — the kernel took a fault it might have survived. It prints a call trace and often kills the offending process. With
panic_on_oops=1, an Oops is escalated into a full panic. - BUG() — a compile-time assertion that a programmer added to catch a broken invariant. When it fires, the kernel has found a real logic error and always halts.
- Panic — the final state. Every CPU is stopped and the machine sits there until you reset it.
Then there is the phrase at the bottom of nearly every panic screen: Kernel panic – not syncing: …. “Not syncing” does not mean the kernel is broken. It means the kernel tried to sync its buffered filesystem data to disk and could not, because it had to stop right then. Anything written since the last flush may be lost, which is why the panic text names the reason it could not continue.
A useful contrast is an application crash. When a program segfaults, the kernel kills just that process and everything else keeps running. When the kernel itself faults, there is no supervisor left to contain the damage.
What Causes a Kernel Panic in Linux?
In plain terms, a kernel panic in Linux comes from the kernel reaching a state it cannot recover from: a fatal hardware fault, a bug in a driver or module, a bug in kernel code, a filesystem or init failure, damage from a failed upgrade, or an explicit panic triggered by a resource or software condition.
The table below maps each family to the signature it usually leaves and the cheapest first check.
| Cause family | Typical signature | First thing to check |
|---|---|---|
| Failing RAM | Random panics at different times, “Unable to handle kernel paging request”, bad page state | memtest86+ for one full pass, ideally overnight |
| Dying storage | I/O errors, EXT4 errors, “Attempted to kill init”, panic only after hours of uptime | SMART data and a kernel self-test with smartctl |
| Driver or module bug | Tainted: P or O in the panic header, panic tied to one device or display change | The module name in the panic and the last package you installed |
| Kernel bug | BUG: assertion failure in a specific function, or a call trace full of unfamiliar symbols | The running kernel version against known regressions, then the previous kernel |
| Filesystem or init failure | “not syncing: Attempted to kill init! exit code: 0x…”, panic during boot only | Mount status of the root filesystem and the entries in /etc/fstab |
| Failed upgrade | Panic right after a kernel update, or a boot that never reaches userspace | Boot the previous kernel from the bootloader menu |
| Overheating or power loss | Panic under load, sudden resets, shutdowns that feel random | Temperature sensors under load and the power supply under stress |
| Firmware or microcode | Early boot panics, ACPI errors, machine check exception reports | BIOS/UEFI version and any pending firmware update |
Two habits pay off more than any other. First, panics that come and go with no pattern are usually hardware, and random intermittent panics across several distributions on the same machine point straight at RAM or the disk. Second, a panic that always lands in the same place after the same change is a software trigger, and timing is the clue.
Hardware and Firmware Failures
Bad RAM and memory corruption
Yes, faulty RAM causes kernel panics, and it is the single most common cause of the random, unreproducible kind. The kernel trusts memory implicitly. When a bit flips, a pointer becomes wrong, and the kernel dereferences something that is not a valid address, you get a paging fault or a bad page report.
The signature is inconsistency. The same machine panics on Tuesday and behaves perfectly for two weeks. On a machine with ECC memory you may catch it earlier as a machine check exception or a corrected error report in the kernel log, which is a much clearer signal than a panic.
How to check bad RAM: boot memtest86+ from a USB stick and let it run at least one full pass, overnight if you can. A single pass that reports zero errors is reassuring but not conclusive, because marginal faults often only appear when the memory is warm or the machine is under load. You can also watch the kernel’s own view while it runs, with sudo dmesg | grep -i -E "mce|ecc|memory error|hardware error".
Dying disks, overheating and unstable power
A drive that is losing sectors produces I/O errors the filesystem cannot absorb, and the kernel’s response is often to stop. The signature is a panic that appears hours into a session rather than at startup, often with filesystem complaints in the log just before the traceback.
Check the drive before you reinstall anything. sudo smartctl -a /dev/sda prints the full SMART data and attributes for the drive, and sudo smartctl -t long /dev/sda starts a self-test you can collect with smartctl -l selftest an hour later. Reading those numbers from a live USB with a tool like GSmartControl is the safer route if the machine will not boot normally. Reallocated sectors, pending sectors and a rising uncorrectable error count are all reasons to replace the drive rather than keep re-installing Linux on it.
Overheating looks like a panic under sustained load: compiling, rendering, stress-testing. Check temperatures with sensors during the load that triggers it, and confirm the machine reboots cleanly when you cap the clock speed. A power supply that cannot hold steady voltage produces hard resets and random panics that look like memory faults, which is why swapping or reseating the PSU is a legitimate diagnostic step.
Machine check exceptions, ECC and firmware
A machine check exception is the CPU reporting that something at the hardware level went wrong, such as a corrected memory error or a bus error. On systems with ECC RAM you will see these logged, and on systems without it the same underlying fault tends to surface as a panic instead.
Firmware sits in the same family because the kernel depends on it heavily at boot. ACPI table problems, a BIOS or UEFI update that went wrong, and buggy platform firmware on an ARM board all produce early panics before you ever reach a login prompt. If a panic happens on early boot and only after a firmware update, check the release notes and see whether a newer version fixes known issues.
Drivers, Modules, and Kernel Bugs
Faulty and out-of-tree drivers
A driver is code running in kernel space with no isolation. A bug in one does not crash a process, it crashes the kernel. That is why the panic header usually names the module involved and marks the kernel as tainted.
Proprietary and out-of-tree modules are the usual suspects, particularly for GPUs and Wi-Fi adapters. The taint letter P means a proprietary module is loaded, O means an out-of-tree module is loaded, and both mean your kernel is now in a state upstream considers unsupported for bug reports.
NVIDIA graphics drivers are the classic example. Panics tied to a display event — switching a monitor, changing resolution, waking from suspend, rotating a laptop panel — usually come from the graphics driver rather than from the kernel core. Users on Hyprland and similar compositors have reported reproducible panics from high-resolution or high-refresh mode settings. If your panic happens only when you change display settings, stop treating it as a hardware fault until you have tested another driver.
Mismatched kernels and DKMS after an upgrade
This is the most common cause of a panic that starts the day you install an update. Kernel modules are compiled against an exact kernel release. When you install a new kernel but your graphics, storage or virtualisation modules are still built for the old one, the new kernel loads a module it cannot trust and dies.
DKMS, the system that rebuilds out-of-tree modules automatically, sometimes fails silently. On Debian and Ubuntu you can check with dkms status; on Fedora and RHEL the equivalent is lsmod combined with a look at the installation log. A module that failed to rebuild for your new kernel is a module that will not load at boot.
Arch users hit a specific version of this: the rolling kernel updates mean the running kernel and the module tree move together, and a partial upgrade can leave a system that panics on the next reboot. The fix is almost always to boot the kernel you had before.
Kernel bugs, races and corrupted memory
Sometimes the fault really is in the kernel. Race conditions between CPUs on SMP systems, mistakes in memory management, and regressions introduced in a specific release all produce panics with call traces pointing at kernel symbols. BUG: sleeping function called from invalid context and stack protector messages are the kernel telling you an invariant was broken.
Race bugs are hard to attribute because they depend on timing, which is why a panic with an unfamiliar call trace and no hardware complaint deserves a check of the running version against reported regressions. Upstream tracks these, and the kernel version in the panic header tells you exactly where to look.
Filesystem, Disk, and Boot Problems
Attempted to kill init and a broken root filesystem
The panic Kernel panic - not syncing: Attempted to kill init! exit code: 0x... has a specific meaning: PID 1, the first process and the supervisor for everything else, died. The kernel cannot carry on without it, so it halts.
Most often this is a root filesystem that failed to mount or came up read-only when it needed to be writable, or an initramfs that could not find the right device. If the mount failed because of a UUID change after reinstalling or repartitioning, /etc/fstab is pointing at a filesystem that no longer exists under that name. A full root filesystem causes the same symptom, because init cannot write and dies trying.
From a live USB you can check the root filesystem without touching anything: lsblk -f to see real UUIDs, then sudo fsck -n /dev/sdXN for a read-only check that reports problems without modifying anything.
Corrupted initramfs and bad boot parameters
The initramfs is the early userspace image the kernel unpacks before it mounts your real root filesystem. If it was built badly during an upgrade, it can lack the storage driver your disk needs, and the kernel then cannot find root at all. You see errors about a missing module, a missing root device, or a timeout while waiting for the root filesystem.
Bad boot parameters produce the same result. A kernel command line that names the wrong root device, a stale resume= parameter, or a wrong rootfstype after switching filesystems will stop a boot that used to work. In the bootloader menu you can edit those parameters temporarily, which tells you immediately whether the configuration is the problem.
Failed kernel upgrades and bootloader damage
A kernel update is the most common trigger for a panic that happens on boot and nothing else. If the new kernel panics every time and the old one boots fine, the cause is the update, not your hardware. This is why keeping a known-good kernel installed is the cheapest insurance in Linux.
When the bootloader itself is damaged you land in GRUB rescue or at a grub> prompt instead of a menu. That prompt can still find and load a kernel by hand: ls to list devices, set root=(hd0,gpt2) to select the boot partition, then linux /boot/vmlinuz-... root=/dev/sdXN ro and initrd /boot/initramfs-...img followed by boot.
If a machine will not boot at all after an update, a live USB with the previous kernel package reinstalled usually fixes it. Do not format anything while diagnosing this; the filesystem is usually fine and only the boot configuration is wrong.
How to Diagnose a Kernel Panic Step by Step
Follow this order and you will either find the cause or eliminate the cheap suspects quickly.
Capture the panic text before you reboot
This is the step people skip, and skipping it is why panics stay undiagnosed. Once the machine reboots, the console text from the failed boot is gone unless something captured it.
- pstore stores a small compressed dump in RAM that survives the panic and is written to the filesystem on the next boot. Enable it with the
pstore_blkorefi_pstorekernel parameter depending on your platform, and read it from/sys/fs/pstore/afterwards. - kexec and kdump load a second, minimal kernel into reserved memory at the moment of the crash. That kernel dumps physical memory to a
vmcorefile, which is the only way to get a complete picture. On most distributions installing the kdump package and reservingcrashkernel=512Min the bootloader configuration sets it up.
Without either, take a photo. The call trace is still visible on screen for several seconds after the halt on most configurations.
Read the taint flags
The Tainted: line tells you the kernel is running in a state upstream will not take bug reports for, and each letter identifies what got it there. This is the single most informative field in the panic header for a normal user.
| Flag | Meaning | What it tells you |
|---|---|---|
| G | Out-of-tree module loaded | A module outside the mainline tree is active |
| P | Proprietary module loaded | A closed-source module such as a proprietary GPU driver is loaded |
| F | Firmware forced the kernel to halt | Firmware reported a fatal error |
| S | Kernel compiled with an out-of-tree SMP workaround | A workaround for an SMP bug is enabled |
| R | Module forcibly loaded | A module was inserted by hand, so the usual checks were bypassed |
| M | Machine check exception occurred | The CPU reported a hardware-level error |
| B | A binary out-of-tree module was loaded | A non-GPL-compatible binary module is in use |
| U | Userspace helper is active | A userspace helper such as a security agent is loaded |
| D | Kernel refused to load | The kernel has been locked down deliberately |
| A | ACPI override in use | An ACPI workaround is active |
| W | Kernel has a warning | A warning was issued on this kernel |
| C | Non-fatal chip revision errata | A CPU erratum workaround is applied |
| I | Kernel is running in firmware | A firmware payload such as a shim is loaded |
| O | Out-of-tree module loaded | A third-party module is active |
A tainted kernel is not a broken system. It means whoever you report the panic to will be told they cannot help until the taint is gone, which in practice means testing without the third-party module.
Check the phase: pre-boot, early boot or runtime
When the panic happens tells you a lot. Before the bootloader appears points at firmware or bootloader hardware. Between the bootloader and the login prompt points at the kernel, initramfs, root filesystem or init. Mid-session points at drivers, hardware or memory. A panic that happens only under one workload points at whatever that workload exercises, usually a device driver.
Pull the logs for the boot that failed
With a journal, the previous boot is still there after a reboot. journalctl -k -b -1 prints the kernel log from the failed boot, and journalctl -xb shows the current one including any errors carried over. dmesg works when there is no journal, such as in a minimal initramfs rescue shell.
Once you have the trace, scripts/decodecode from the kernel source turns the raw Code: bytes into the actual trapping instruction, and matching the RIP address against a vmlinux with objdump gives you the source line. That step matters for kernel bugs rather than hardware faults, because a hardware fault shows up as a wild address rather than a sensible one.
Test hardware, then compare against a known-good kernel
Run memtest86+ for a full pass, check the disks with smartctl, and note whether the machine panics with a different kernel installed. If the panic follows the kernel version, it is software. If it follows the hardware, it is hardware. That single comparison resolves more cases than any amount of log reading.
How to Fix Common Linux Kernel Panic Triggers
Bad RAM
Replace the memory. There is no reliable software repair for a failing module, and a machine that panics from memory corruption will eventually take data with it. If memtest86+ passes cleanly but panics continue, test one stick at a time, then reseat or replace the memory controller path before suspecting software.
Corrupted filesystem
Boot a live USB and check the filesystem offline. sudo fsck -y /dev/sdXN repairs a damaged ext4 filesystem; on XFS you cannot repair in place, so the fix is to format and restore from backup. Before repairing, read the SMART data. Repairing a filesystem on a drive that is about to fail can turn a recoverable problem into a total loss.
Failed kernel upgrade
On Ubuntu, Debian and Linux Mint, hold the Shift key during boot to reach the GRUB menu, open Advanced options, and pick the previous kernel. Once you are back in, reinstall the broken kernel package and its initramfs, then reinstall any DKMS packages so their modules rebuild. On Arch, the same menu exists under advanced options, and the fix is to reinstall the linux package and rebuild the initramfs for the kernel you are currently running. On Fedora and RHEL, press e at the GRUB menu, select an older kernel, and rebuild the initramfs for the current one with dracut -f --regenerate-all.
Driver and module problems
Rebuild or remove the suspect module. dkms status shows which DKMS modules matched your running kernel; modprobe -r modulename unloads one for testing; modinfo modulename shows where it came from and which kernel built it. Blacklisting a module in /etc/modprobe.d/ stops it loading at boot, which is the fastest way to confirm it is the cause.
For graphics, test the open-source driver in place of the proprietary one before hunting anywhere else. If the machine panics on kernel A but boots fine on kernel B, pin it to the known-good version until a fixed release appears.
Overheating, power and firmware
Clean the dust out of the cooling path, verify the fans spin, and check that the machine is not sealed in a cabinet with no airflow. Undervoltage and a failing power supply need hardware, not configuration. Update the BIOS/UEFI to a current version, and check the vendor notes for ACPI or platform fixes.
Stop using a machine that panics repeatedly if you value the data on it. Back up first, then keep diagnosing. A panic is a safety mechanism, and repeated panics mean something is corrupting state that you may not notice until the wrong file is written.
When Is the Kernel Panic Not the Real Problem?
Several failures look like a panic on screen but have a different cause, and treating them as a kernel panic sends you down the wrong path entirely.
Softlockup and hardlockup
A softlockup is when one CPU spins in kernel mode without yielding long enough for another to run; the machine freezes and the CPU shows high usage but nothing crashes. The kernel detects it with the softlockup detector and prints watchdog: BUG: soft lockup - CPU# after the watchdog_thresh threshold, which defaults to 20 seconds in current kernels and was 10 seconds historically. A hardlockup is the same situation detected by the non-maskable interrupt watchdog, which fires even when interrupts are disabled.
By default a lockup prints a warning and the system keeps running. kernel.softlockup_panic and kernel.hardlockup_panic turn them into real panics, which is a setting worth knowing about rather than one to enable casually. The difference matters when you are searching: a frozen machine at high CPU is a lockup or a driver bug, not a classic panic, and it never prints “not syncing”.
OOM kills and init-system failures
An out-of-memory kill does not panic the kernel. The OOM killer terminates the largest process, the kernel keeps running, and dmesg records the decision. If a service dies and the machine reboots afterward, you have an OOM kill plus a separate problem, not a panic.
Similarly, a systemd unit failing at boot, a display manager crashing in a loop, or udev failing on one device produce a broken system without a panic. If you reached a login prompt or a shell at all, the kernel survived, and the fault is in user space.
Graphics stalls and hardware lockups
A desktop that freezes with the mouse pointer still moving across two monitors is usually a graphics driver stall. A machine that locks up with no output at all, and needs a hard reset, may be a PCIe or GPU fault rather than a panic, because no panic text was ever printed. When there is no text on screen, reach for the logs after the reboot before assuming a panic occurred.
Frequently Asked Questions
What is the root cause of a kernel panic?
The root cause is whatever left the kernel unable to continue safely: a fatal hardware fault such as failing RAM or a dying disk, a bug in a driver or kernel module, a kernel bug, a filesystem or init failure, damage from a failed kernel upgrade, or an explicit panic triggered by software. In practice the two most common are bad memory and a broken driver, and the panic text usually tells you which.
Can you recover from a kernel panic?
Yes, usually. The machine is halted, not destroyed, so the data on disk is generally intact. If it panics during boot after an update, boot the previous kernel from the bootloader menu and reinstall the failed package. If the root filesystem itself is damaged, run fsck from a live USB and restore anything unrecoverable from backup. Powering the machine off does not make a panic worse.
How serious is a kernel panic?
One panic on a desktop is usually a hardware or driver hiccup, not an emergency, though you should back up. Repeated panics are serious because the same fault keeps triggering. A panic that happens on every boot after an update is normally a broken package rather than failing hardware. A panic accompanied by I/O errors, machine check exceptions or visible disk trouble is serious and warrants backing up immediately.
Should I test RAM first when my machine panics?
For random, intermittent panics with no clear trigger, yes. Memory corruption produces faults that look random and leave no pattern, and memtest86+ for a full pass costs nothing but time. If your panics always follow the same action, such as a display change or a specific application, test the driver first, because the timing already points at software. Timing is the cheapest signal you have.
What does u0022Kernel panic – not syncingu0022 mean?
It means the kernel halted and could not flush its buffered filesystem data to disk before stopping. The text after u0022not syncingu0022 names the condition that forced the halt, such as a failed attempt to kill init. Data written since the last successful sync may be lost, but the filesystems themselves are not damaged by the panic. That is exactly why the kernel halts instead of continuing.
What information should I include when asking about a kernel panic?
Include the exact panic text from the top of the message, not a photo of the screen, plus the kernel version, the distribution and its version, the taint flags, the call trace, and the hardware involved. Say whether it panics at boot or mid-session, whether it happens every time, and what you changed just before the first occurrence. If you set up kdump or pstore, attach the vmcore or pstore dump.
Conclusion
Start by keeping the panic text, then decide when it happens. Panics on every boot after an update are a package problem, and you fix them from the bootloader menu. Random panics at unpredictable moments are usually RAM or a dying disk, and memtest86+ plus a SMART check settles that question quickly. Set up kdump or pstore before you go further, because the evidence for the next panic is worth more than any guess made after the fact.
