Kernel panic: not syncing, explained and recovered

A kernel panic is the Linux kernel's last resort: it encountered a condition where continuing could corrupt data, so it stops everything. The screen freezes with a stack trace and the words Kernel panic - not syncing: followed by the specific reason. That reason is the diagnosis. The most common completion on desktop and server machines is VFS: Unable to mount root fs, which means the kernel booted fine but could not find or read the root filesystem, a very different problem from a hardware panic, and usually recoverable in minutes.

Read the reason line and the lines above it

  1. “VFS: Unable to mount root fs on unknown-block(...)” points at the root filesystem path: the root= boot parameter names a device or UUID that no longer matches (partition changes, a cloned disk), the initramfs lacks the driver for the storage controller, or the initramfs itself is missing or stale after a kernel update.
  2. Panics naming a driver or filesystem module with a call trace through it point at that component, often after a kernel or driver change; the previous kernel usually still boots.
  3. Panics with no consistent pattern, at random moments, on a system that also misbehaves elsewhere, raise the hardware question, memory first.

The recovery sequence

  1. Boot the previous kernel: in the GRUB menu choose “Advanced options” and the earlier kernel entry. If it boots, the system is usable and the problem is confined to the new kernel or its initramfs; this single test splits the problem space in half.
  2. Rebuild the initramfs for the failing kernel: from the working boot, sudo update-initramfs -u -k <version> (Debian/Ubuntu) or sudo dracut --force (Fedora/RHEL), then sudo update-grub and retry. A stale initramfs after storage or partition changes is the classic root cause.
  3. Verify the root parameter: compare the root=UUID=... in the boot configuration with the actual partition UUIDs from blkid; a mismatch after cloning or repartitioning is fixed by correcting the entry and regenerating the configuration.
  4. If no kernel boots, work from live media: check the disks' health (smartctl), run a filesystem check on the unmounted root (fsck), and confirm the EFI/boot partitions still contain what the firmware expects.

Common questions

Did the panic damage my files? The panic itself halts the machine precisely to avoid damage; the “not syncing” wording means the kernel refuses to flush caches it cannot trust. Files being written at that instant can be incomplete, and a filesystem check on the next proper boot is prudent, but wholesale loss is not the expectation.

It started right after a kernel update, is the new kernel broken? More likely its initramfs or boot entry is wrong for your machine than the kernel being globally broken. Booting the previous kernel and rebuilding the initramfs resolves most post-update panics; keeping the old kernel installed until the new one proves itself is standard practice.

Caps Lock is blinking, what does that mean? On many systems the keyboard LEDs blink as the panic indicator when the screen output is unavailable. It conveys the same fact (the kernel has panicked) and nothing more specific; the reason must be read from the screen or logs after a successful boot.

Related errors

GRUB rescue prompt · Segmentation fault · dpkg returned an error code