Fix Linux Kernel Panic: VFS Unable to Mount Root Filesystem

Symptoms

During boot, the system displays a kernel panic with the message: VFS: Unable to mount root fs on unknown-block(0,0) or similar. The boot process halts, and the system drops to a shell (if configured) or hangs indefinitely. This error typically appears after a kernel update, filesystem corruption, or configuration change.

Root Causes

1. Missing or corrupted initramfs/initrd – The initial ramdisk that contains necessary kernel modules for mounting the root filesystem is absent or damaged.
2. Incorrect root= parameter in kernel command line – The bootloader (GRUB) passes a wrong device or UUID for the root partition.
3. Missing filesystem driver – The kernel lacks the module for the root filesystem type (e.g., ext4, btrfs, xfs) in the initramfs.
4. Filesystem corruption – The root partition has severe errors preventing mounting.
5. Hardware changes – Disk controller or drive reordering changes the device name (e.g., /dev/sda to /dev/sdb).
6. UUID mismatch – The UUID in /etc/fstab or GRUB configuration does not match the actual partition UUID.

Step-by-Step Fix

1. Boot into Recovery/Rescue Mode

From the GRUB menu, select the recovery mode option (if available) or edit the boot entry (press 'e') and add single or init=/bin/bash to the kernel line. If using a live CD/USB, boot from it to access the system.

2. Identify the Root Partition

Run lsblk or fdisk -l to list all disks and partitions. Note the correct root partition (e.g., /dev/sda2 or /dev/nvme0n1p2). Check its UUID with blkid /dev/sdXY.

3. Mount the Root Filesystem

If in live environment, mount the root partition to /mnt:
mount /dev/sdXY /mnt
Mount other necessary filesystems:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

4. Chroot into the System

chroot /mnt /bin/bash
Now you are inside the broken system.

5. Rebuild Initramfs

Depending on your distribution:
For Debian/Ubuntu: update-initramfs -u -k all
For RHEL/CentOS/Fedora: dracut -f --regenerate-all
For Arch: mkinitcpio -p linux (or your kernel variant)

6. Verify GRUB Configuration

Check /etc/default/grub for the GRUB_CMDLINE_LINUX line. Ensure root=UUID=... matches the actual UUID. Update if needed. Then run:
update-grub (Debian/Ubuntu) or grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL).

7. Check Filesystem Integrity

Unmount the root partition (umount /mnt) and run:
fsck -y /dev/sdXY
Repair any errors found.

8. Reboot

Exit chroot (exit), unmount all (umount -R /mnt), and reboot.

Alternative Fixes

• Use fallback initramfs – Some distributions keep a fallback initramfs (e.g., /boot/initramfs-linux-fallback.img). Boot with that image from GRUB.
• Manually specify root device – At GRUB, edit the kernel line to use root=/dev/sdXY (e.g., root=/dev/sda2) instead of UUID.
• Reinstall kernel – If initramfs rebuild fails, reinstall the kernel package: apt install --reinstall linux-image-$(uname -r) (Debian) or yum reinstall kernel (RHEL).
• Check for missing kernel modules – If using a custom kernel or filesystem (e.g., btrfs), ensure the module is included in initramfs. Add it to /etc/mkinitcpio.conf (Arch) or /etc/dracut.conf.d/.

Prevention

• Always keep a backup kernel and initramfs – Do not delete old kernels until new ones are proven stable.
• Test kernel updates in a non-production environment first.
• Use UUID instead of device names in /etc/fstab and GRUB configuration to avoid issues with device reordering.
• Regularly run filesystem checks (fsck) on root partition during maintenance windows.
• Maintain a live USB for emergency recovery.
• Enable serial console logging to capture boot messages for easier debugging.

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