Fix Kernel Panic: VFS Unable to Mount Root Filesystem

Symptoms

The system fails to boot and displays a kernel panic with the message: VFS: Unable to mount root fs on unknown-block(0,0) or similar. The boot process stops at an emergency shell or hangs indefinitely. This error can occur after a kernel update, hardware change, or filesystem corruption.

Root Causes

• Missing or corrupted initramfs: The initial RAM filesystem (initramfs) lacks the necessary modules to access the root device (e.g., storage driver, filesystem driver).
• Kernel module not loaded: The kernel does not have the driver for the storage controller (e.g., SATA, NVMe, SCSI) compiled in or available in initramfs.
• Wrong root= parameter in GRUB: The kernel command line specifies an incorrect root device (e.g., root=/dev/sda1 but the device name changed).
• Filesystem corruption: The root filesystem is damaged and cannot be mounted.
• LVM or encryption issues: Logical volumes or encrypted partitions are not unlocked or activated before mounting root.

Step-by-Step Fix

1. Boot into a recovery environment: Use a live USB/DVD of the same Linux distribution to boot the system.
2. Identify the root partition: Run lsblk or fdisk -l to list disks. Look for the partition containing / (e.g., /dev/sda2 or /dev/nvme0n1p2).
3. Mount the root filesystem:

   mount /dev/sda2 /mnt

   If using LVM, activate volume groups first: vgchange -ay then mount the logical volume.
4. Chroot into the system:

   mount --bind /dev /mnt/dev
   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   chroot /mnt

5. Rebuild initramfs: For distributions using dracut: dracut -f. For Debian/Ubuntu: update-initramfs -u -k all. This regenerates the initramfs with current kernel modules.
6. Reinstall GRUB (if needed):

   grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/CentOS
   grub-mkconfig -o /boot/grub/grub.cfg      # Debian/Ubuntu

7. Check kernel command line: Edit /etc/default/grub and ensure GRUB_CMDLINE_LINUX contains the correct root device (e.g., root=UUID=...). Use blkid to get the UUID.
8. Reboot: Exit chroot, unmount all, and reboot: exit; umount -R /mnt; reboot.

Alternative Fixes

• Use fallback kernel: At GRUB menu, select an older kernel version that worked previously.
• Manual kernel module loading: At the emergency shell, try modprobe the storage driver (e.g., modprobe ahci or modprobe nvme) then exit to continue boot.
• Filesystem check: Boot from live media and run fsck /dev/sda2 to repair filesystem errors.
• Reinstall kernel: In chroot, reinstall the kernel package: dnf reinstall kernel-core (RHEL) or apt install --reinstall linux-image-$(uname -r) (Debian).

Prevention

• Always keep a backup kernel: Do not remove old kernels until the new one boots successfully.
• Use UUID in GRUB: Avoid device names like /dev/sda1 which can change; use blkid to set root=UUID=....
• Test updates in a staging environment: Before applying kernel updates on production systems, test on a non-critical machine.
• Regularly rebuild initramfs: After hardware changes (e.g., adding new storage controller), regenerate initramfs.
• Enable serial console logging: Capture boot messages to diagnose future panics faster.

This error is common but recoverable with the steps above. If the problem persists, verify hardware connections and consider replacing the storage device.