Fix Kernel Panic: VFS Unable to Mount Root Filesystem

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

Kernel panic with 'VFS: Unable to mount root fs' occurs when Linux cannot find or mount the root filesystem during boot. This guide covers causes and step-by-step recovery using a live CD.

Symptoms

Upon booting a Linux system, the screen displays a kernel panic with a message similar to: VFS: Unable to mount root fs on unknown-block(0,0) or VFS: Cannot open root device "sda2" or unknown-block(8,2). The system hangs and does not proceed to the login prompt.

Root Causes

  • Missing or corrupted initramfs/initrd – The initial RAM disk lacks necessary filesystem drivers (e.g., ext4, xfs, btrfs) or the root device module.
  • Incorrect root= parameter in GRUB – The kernel command line points to a wrong partition or UUID.
  • Filesystem driver not compiled into kernel or initramfs – For example, using a custom kernel without built-in support for the root filesystem type.
  • Hardware change – Disk controller or drive moved to a different port, changing device names (e.g., /dev/sda to /dev/sdb).
  • Corrupted filesystem or partition table – The root partition is damaged or missing.
  • LVM or encryption issues – LVM volume not activated or LUKS not unlocked before root mount.

Step-by-Step Fix

  1. Boot from a live USB/CD – Use any Linux live environment (e.g., Ubuntu Live, SystemRescue).
  2. Identify the root partition – Run lsblk or fdisk -l to list disks. Look for your Linux root partition (e.g., /dev/sda2).
  3. Mount the root partitionmount /dev/sda2 /mnt (replace sda2 with your partition).
  4. Chroot into the systemmount --bind /dev /mnt/dev && mount --bind /proc /mnt/proc && mount --bind /sys /mnt/sys && chroot /mnt
  5. Rebuild initramfs – Run update-initramfs -u -k all (Debian/Ubuntu) or dracut -f --regenerate-all (RHEL/Fedora). This ensures all necessary modules are included.
  6. Check GRUB configuration – Verify /etc/default/grub has correct GRUB_CMDLINE_LINUX. Regenerate GRUB with update-grub (Debian) or grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL).
  7. Verify /etc/fstab – Ensure the root entry uses the correct UUID or device name. Use blkid /dev/sda2 to get UUID and update fstab if needed.
  8. Exit chroot and reboot – Type exit then reboot. Remove the live media.

Alternative Fixes

  • Boot with fallback initramfs – In GRUB, select an older kernel or a recovery mode entry.
  • Manually specify root device – At GRUB prompt, press e to edit boot parameters. Change root=UUID=... to root=/dev/sda2 (or correct device).
  • Add missing driver – If using a custom kernel, rebuild with the filesystem driver compiled in (not as a module).
  • Repair filesystem – Run fsck /dev/sda2 from live environment to fix corruption.
  • Reinstall GRUB – If bootloader is corrupt, use grub-install /dev/sda after chrooting.

Prevention

  • Always update initramfs after kernel changes – Run update-initramfs -u after installing or updating the kernel.
  • Use UUID in /etc/fstab – Avoid device names like /dev/sda1 which can change. Use blkid to get persistent UUID.
  • Test kernel updates in a VM or non-production system first – Especially if using custom kernels or modules.
  • Keep a backup of /boot – Regularly backup kernel, initramfs, and GRUB config.
  • Monitor disk health – Use SMART tools to detect failing drives before they cause boot issues.

This guide covers the most common scenarios. If the problem persists, check kernel logs via dmesg from the live environment for specific driver errors.

Was this solution helpful?