Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Fix Kernel Panic: VFS Unable to Mount Root Filesystem
Kernel panic with VFS unable to mount root filesystem occurs when the kernel cannot locate or mount the root partition. This is often due to missing drivers, incorrect boot parameters, or corrupted initramfs.
Symptoms
The system fails to boot and displays a kernel panic message similar to:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)This is typically accompanied by a blank screen or a frozen state after the kernel loads. The error may appear immediately after selecting a kernel in GRUB or during the initramfs stage.
Root Causes
- Missing or corrupted initramfs: The initial RAM filesystem does not contain the necessary kernel modules (e.g., storage controller drivers) to mount the root partition.
- Incorrect boot parameters: The root= parameter in GRUB points to a non-existent or incorrect device (e.g., wrong UUID or device name).
- Missing storage driver: The kernel lacks the driver for the disk controller (e.g., SATA, NVMe, or SCSI) in the initramfs.
- Filesystem corruption: The root filesystem is damaged and cannot be mounted.
- Kernel update issues: After a kernel upgrade, the initramfs was not regenerated or the new kernel lacks support for the hardware.
Step-by-Step Fix
1. Boot into Recovery Mode or Live USB
- Restart the system and press Shift (or Esc on some systems) to access the GRUB menu.
- Select an older working kernel or choose Advanced options → Recovery mode.
- If recovery mode fails, boot from a Linux Live USB (e.g., Ubuntu Live) to repair the installation.
2. Identify the Root Partition
In the live environment, open a terminal and run:
sudo fdisk -lor
lsblk -fNote the device name (e.g.,
/dev/sda1) and its UUID. Example output: NAME FSTYPE UUID MOUNTPOINT
sda1 ext4 a1b2c3d4-... /mnt
3. Mount the Root Partition
sudo mount /dev/sda1 /mnt
If you have a separate boot partition, mount it as well:
sudo mount /dev/sda2 /mnt/boot
4. Chroot into the System
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
5. Rebuild Initramfs
First, check the current kernel version:
uname -rThen regenerate initramfs:
update-initramfs -u -k allOr for a specific kernel:
update-initramfs -u -k 5.15.0-91-genericOn RHEL/CentOS/Fedora, use:
dracut -f
6. Update GRUB Configuration
update-grub(On RHEL/CentOS:
grub2-mkconfig -o /boot/grub2/grub.cfg)7. Verify Boot Parameters
Check /etc/default/grub for the GRUB_CMDLINE_LINUX line. Ensure root=UUID=... matches the UUID of your root partition. Example:
GRUB_CMDLINE_LINUX="root=UUID=a1b2c3d4-..."If using device names, ensure they are consistent (e.g.,
root=/dev/sda1).8. Exit and Reboot
exit
sudo umount -R /mnt
sudo reboot
Alternative Fixes
- Check filesystem integrity: Boot from Live USB and run
fsck /dev/sda1to repair corruption. - Add missing driver modules: If the storage controller driver is missing, add it to
/etc/initramfs-tools/modules(e.g.,nvmefor NVMe drives) and rebuild initramfs. - Use fallback kernel: If the latest kernel fails, boot an older kernel from GRUB and remove the problematic one.
- Reinstall kernel:
apt install --reinstall linux-image-$(uname -r)(Debian/Ubuntu) oryum reinstall kernel(RHEL/CentOS).
Prevention
- Always regenerate initramfs after kernel updates:
update-initramfs -u. - Keep a working backup kernel in GRUB (e.g., keep at least two kernels).
- Use UUIDs in
/etc/fstaband GRUB instead of device names (/dev/sda) to avoid reordering issues. - Regularly check filesystem health with
fsck. - Test kernel updates in a non-production environment first.
This error is common but fixable with proper recovery steps. Always ensure your initramfs includes the correct drivers for your storage hardware.
Was this solution helpful?