Fix Kernel Panic VFS Unable to Mount Root Filesystem

Symptoms

During Linux boot, the system displays a kernel panic with the message: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) or similar. The boot process stops, and you may see a blinking cursor or a frozen screen. This often occurs after a kernel update, disk changes, or filesystem corruption.

Root Causes

Missing filesystem driver: The kernel lacks the necessary module (e.g., ext4, xfs, btrfs) to mount the root partition.
Corrupted or missing initramfs/initrd: The initial RAM disk does not contain the required modules or is damaged.
Incorrect boot parameters: The root= parameter in GRUB points to a wrong device or UUID.
Filesystem corruption: The root partition has errors preventing mounting.
Hardware changes: Disk controller, drive connection, or storage device changed (e.g., from SATA to NVMe).

Step-by-Step Fix

1. Boot into Recovery Mode or Live USB

Use a Linux live USB or the recovery/rescue mode from your bootloader (e.g., GRUB advanced options). Boot to a shell as root.

2. Identify the Root Partition

Run lsblk -f or blkid to list all block devices and their UUIDs. Note the UUID or device name (e.g., /dev/sda2) of your root filesystem.

3. Check and Repair Filesystem

Unmount the root partition if mounted (use umount /dev/sdX2). Run fsck -y /dev/sdX2 to check and repair errors. Replace /dev/sdX2 with your root device.

4. Mount Root and Chroot

Mount the root partition to /mnt: mount /dev/sdX2 /mnt. If you have separate boot or EFI partitions, mount them too: mount /dev/sdX1 /mnt/boot (or /mnt/boot/efi). Then chroot: chroot /mnt.

5. Rebuild Initramfs

Depending on your distribution:

Debian/Ubuntu: update-initramfs -u -k all
RHEL/CentOS/Fedora: dracut -f --regenerate-all or mkinitrd -f /boot/initramfs-$(uname -r).img $(uname -r)
Arch Linux: mkinitcpio -p linux

6. Update GRUB Configuration

Run update-grub (Debian/Ubuntu) or grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL). Ensure the root= parameter in /etc/default/grub uses the correct UUID from step 2.

7. Verify Boot Parameters

Check /etc/default/grub for GRUB_CMDLINE_LINUX. It should contain root=UUID=your-uuid. If using device names, use UUID instead for reliability.

8. Exit Chroot and Reboot

Type exit to leave chroot, then umount -R /mnt and reboot. Remove the live USB.

Alternative Fixes

Use fallback initramfs: In GRUB, select an older kernel or the fallback initramfs entry (e.g., initramfs-fallback.img).
Manual kernel module loading: At GRUB prompt, edit the boot entry and add modprobe.blacklist=nouveau or rd.driver.pre= to force load modules.
Reinstall kernel: If the kernel itself is corrupted, reinstall it via package manager from chroot.
Check disk connections: For hardware changes, ensure SATA cables are secure or NVMe drives are detected in BIOS.

Prevention

Always keep a backup kernel: Never remove all old kernels. Keep at least one known-working version.
Test updates in a VM: Before updating kernel or initramfs on production systems, test in a safe environment.
Use UUIDs in boot config: Avoid device names like /dev/sda1 as they can change. Use blkid to get UUIDs.
Regular filesystem checks: Schedule fsck periodically or at boot (tune2fs -c 20 /dev/sdX2).
Monitor disk health: Use smartctl to check for failing drives.
Document hardware changes: When adding or removing disks, update /etc/fstab and boot parameters accordingly.

By following these steps, you can diagnose and fix the 'VFS unable to mount root' kernel panic and restore normal boot. If problems persist, consider verifying hardware integrity or seeking community support with your distribution's logs.