Fix Kernel Panic: VFS Unable to Mount Root Filesystem
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
- Boot from a live USB/CD – Use any Linux live environment (e.g., Ubuntu Live, SystemRescue).
- Identify the root partition – Run
lsblkorfdisk -lto list disks. Look for your Linux root partition (e.g., /dev/sda2). - Mount the root partition –
mount /dev/sda2 /mnt(replace sda2 with your partition). - Chroot into the system –
mount --bind /dev /mnt/dev && mount --bind /proc /mnt/proc && mount --bind /sys /mnt/sys && chroot /mnt - Rebuild initramfs – Run
update-initramfs -u -k all(Debian/Ubuntu) ordracut -f --regenerate-all(RHEL/Fedora). This ensures all necessary modules are included. - Check GRUB configuration – Verify
/etc/default/grubhas correctGRUB_CMDLINE_LINUX. Regenerate GRUB withupdate-grub(Debian) orgrub2-mkconfig -o /boot/grub2/grub.cfg(RHEL). - Verify /etc/fstab – Ensure the root entry uses the correct UUID or device name. Use
blkid /dev/sda2to get UUID and update fstab if needed. - Exit chroot and reboot – Type
exitthenreboot. 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=...toroot=/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/sda2from live environment to fix corruption. - Reinstall GRUB – If bootloader is corrupt, use
grub-install /dev/sdaafter chrooting.
Prevention
- Always update initramfs after kernel changes – Run
update-initramfs -uafter installing or updating the kernel. - Use UUID in /etc/fstab – Avoid device names like /dev/sda1 which can change. Use
blkidto 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?