null

Fix Kernel Panic: VFS Unable to Mount Root Filesystem

Linux & Unix Intermediate 👁 16 views 📅 May 25, 2026

Kernel panic with 'VFS: Unable to mount root fs' indicates the kernel cannot locate or mount the root filesystem. This guide covers causes and step-by-step recovery using initramfs repair, boot parameter adjustment, and filesystem checks.

Symptoms

Upon booting a Linux system, the console displays a kernel panic with the message: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0). The system halts and does not proceed to the login prompt. This error can occur after a kernel update, disk configuration change, or filesystem corruption.

Root Causes

  • Missing or corrupted initramfs/initrd – The initial RAM filesystem lacks necessary drivers or modules to mount the root partition.
  • Incorrect root= parameter in GRUB – The kernel command line specifies a wrong device or UUID for the root filesystem.
  • Filesystem corruption – The root partition has errors preventing mounting.
  • Missing storage driver – Kernel lacks driver for the disk controller (e.g., NVMe, SATA, RAID).
  • LVM or encryption changes – LVM volume group not activated or LUKS not unlocked.
  • UUID change – Disk UUID altered due to repartitioning or cloning.

Step-by-Step Fix

1. Boot into Rescue Mode

Restart the system and interrupt the boot process (e.g., press Shift or Esc for GRUB). Select the kernel entry, press e to edit, and add single or init=/bin/bash to the kernel line. Then press Ctrl+X or F10 to boot.

2. Check Root Device and UUID

At the rescue shell, run:

blkid

Note the UUID of the root partition (e.g., /dev/sda2). Compare with the root= parameter in GRUB. If mismatched, correct it.

3. Rebuild Initramfs

Chroot into the system (if needed) or directly rebuild:

# For Debian/Ubuntu (update-initramfs)
update-initramfs -u -k all

# For RHEL/CentOS (dracut)
dracut --force --regenerate-all

# For Arch (mkinitcpio)
mkinitcpio -p linux

4. Fix GRUB Configuration

Update GRUB to use the correct root UUID:

# Edit /etc/default/grub and set GRUB_CMDLINE_LINUX="root=UUID=correct-uuid"
# Then update GRUB
update-grub   # Debian/Ubuntu
grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/CentOS

5. Check Filesystem

Run a filesystem check on the root partition (unmount it first if possible):

fsck /dev/sda2   # replace with your root device

Answer y to fix errors.

6. Verify Storage Drivers

If using NVMe or RAID, ensure the initramfs includes the appropriate modules. For example, on Debian/Ubuntu, edit /etc/initramfs-tools/modules and add nvme, then rebuild initramfs.

Alternative Fixes

  • Use fallback initramfs – Some systems keep an older initramfs (e.g., /boot/initrd.img-*-old). Boot with that image.
  • Boot from live USB – Mount the root partition, chroot, and rebuild initramfs.
  • Reinstall kernel – If the kernel is corrupted, reinstall the kernel package via package manager.
  • Check for LVM – If using LVM, ensure lvm2 package is installed and initramfs includes lvm modules. Run vgchange -ay to activate volume groups.

Prevention

  • Always rebuild initramfs after kernel updates – Use the package manager's hooks or manually run the appropriate command.
  • Backup GRUB configuration – Keep a copy of /etc/default/grub and the generated /boot/grub/grub.cfg.
  • Use UUID instead of device names – Device names like /dev/sda1 can change; UUIDs are persistent.
  • Regular filesystem checks – Schedule fsck during boot or use tune2fs -c to set mount count checks.
  • Test kernel updates in a staging environment – Before applying to production, verify bootability.
  • Maintain a rescue kernel – Keep an older known-good kernel entry in GRUB.

By following these steps, you can recover from the VFS unable to mount root filesystem kernel panic and prevent future occurrences.

Was this solution helpful?