A kernel panic is the Linux kernel stopping because it hit an error it can’t safely recover from. On a server this means an outage, and if it happens at boot, the server won’t come back on its own. Here’s how to find out why and how to recover.

What a panic looks like

On the console (on a VPS, the VNC console in your control panel) you’ll see something like:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

or

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

The text after not syncing: is the most important clue. Below it, a call trace shows which kernel functions were running.

Not every crash is a panic. An oops is a kernel error the system may survive (it logs a trace and continues, possibly unstable). Some settings turn oopses into panics.

Common causes

Panic message / situation Likely cause
Unable to mount root fs Missing or broken initramfs, wrong root= in GRUB, missing storage driver after a kernel update
Attempted to kill init /sbin/init (systemd) crashed or is missing — corrupted root filesystem, broken libc after interrupted update
Right after a kernel update Bad kernel build, incompatible third-party module (e.g. DKMS driver failed to build)
Random panics under load Faulty RAM or CPU (on physical servers), buggy driver, overheating
Out of memory and no killable processes Memory exhausted with vm.panic_on_oom set

Recover a server that won’t boot

1. Boot the previous kernel

Most distributions keep older kernels. Open the console, reboot, and in the GRUB menu choose Advanced options → an older kernel. If the server boots, the new kernel or its initramfs is the problem.

2. Rebuild the initramfs and GRUB config

Once booted (old kernel or rescue mode):

# Debian/Ubuntu
update-initramfs -u -k all
update-grub

# AlmaLinux/Rocky
dracut -f --regenerate-all
grub2-mkconfig -o /boot/grub2/grub.cfg

3. Use rescue mode if nothing boots

Boot a rescue system (from your provider’s control panel or a live ISO), then mount and enter the installed system:

mount /dev/vda1 /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt
# now fix: reinstall the kernel, rebuild initramfs, check /etc/fstab
apt install --reinstall linux-image-amd64   # Debian example

4. Check the filesystem

If the root filesystem is damaged, run fsck on it unmounted from rescue mode. See filesystem journaling.

5. Check /etc/fstab

A wrong UUID or a missing disk in /etc/fstab usually drops you to an emergency shell rather than panicking, but it’s a common reason a server won’t finish booting. Add nofail to non-essential mounts.

Find the cause after the fact

If the server rebooted after a panic, logs from the previous boot may show what happened:

journalctl -b -1 -k -p err      # kernel errors from the previous boot
journalctl --list-boots

For this to work, the journal must be persistent: mkdir -p /var/log/journal && systemctl restart systemd-journald.

Panics often happen too fast to be written to disk. Options to capture them:

  • kdump — reserves memory for a second kernel that saves a crash dump. Install kdump-tools (Debian/Ubuntu) or kexec-tools (RHEL family) and add crashkernel= to the kernel command line.
  • netconsole — sends kernel messages over the network to another machine.
  • Screenshot the console — on a VPS, the VNC console often still shows the last message.

Automatically reboot after a panic

So a server doesn’t sit frozen:

# /etc/sysctl.d/90-panic.conf
kernel.panic = 10            # reboot 10 seconds after a panic

Prevent it

  • Reboot into new kernels during a maintenance window, and keep at least one older kernel installed.
  • Watch DKMS module builds after kernel updates.
  • Keep backups so a damaged system can be rebuilt quickly — see Debian backup and disaster recovery.

On a KVM VPS, your server runs its own kernel, so these steps apply exactly as on physical hardware — and the VNC console in the control panel lets you watch the boot and pick an older kernel.

  • Linux
  • Troubleshooting
  • Kernel