Linux  ·  critical  ·  Core system faults

Kernel panic — "VFS: Unable to mount root fs on unknown-block(0,0)"

The kernel loaded but could not mount the root filesystem, usually because the initramfs does not contain the driver needed to see the disk.

What you see

Boot stops at a kernel panic naming unknown-block(0,0). Often immediately after a kernel update, a disk controller change, or a migration to different virtual hardware.

What is actually wrong

A missing or broken initramfs, a root= parameter naming a device that no longer exists, or an initramfs built without the storage or LVM modules this hardware needs.

Codes and articles

VFS: Unable to mount root fsunknown-block(0,0)Kernel panic - not syncingNo init found

Fixes (2)

Boot the previous kernel and rebuild the new one's initramfs
GRUB menu, then shell30 minuteslow riskreversible

It started after a kernel update and an older kernel is still installed.

  1. At the GRUB menu choose Advanced options and select the previous kernel. Hold Shift or press Esc during boot if the menu is hidden.

  2. Once booted, confirm which kernel you are on and which are installed.

    Shell
    uname -rls /boot/vmlinuz-*
  3. Check the broken kernel's initramfs exists and is a sensible size.

    Shell
    ls -lh /boot/initramfs-* /boot/initrd.img-* 2>/dev/null

    A zero-length or missing initramfs is a common result of a kernel update that ran out of space in /boot, and it produces exactly this panic.

  4. Check /boot has room, and clear old kernels if not.

    Shell
    df -h /boot
  5. Rebuild it. On RHEL-family:

    Shell
    sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
  6. On Debian-family:

    Shell
    sudo update-initramfs -c -k allsudo update-grub
  7. Reboot into the newer kernel.

Confirm it workedThe machine boots on the newest kernel.
Shell
uname -r
If you need to undo itBoot the older kernel again from GRUB — it is untouched by this.
Rebuild the initramfs with all drivers from a rescue environment
Rescue/live media with chroot45–90 minutesmedium riskreversible

Hardware or the virtual platform changed, so the initramfs lacks the driver for the new controller.

  1. Boot rescue media matching the distribution and version.

  2. Find and mount the root filesystem, activating LVM first if it is used.

    Shell
    lsblk -fsudo vgchange -aysudo mount /dev/mapper/vg-root /mnt
  3. Mount /boot and the EFI partition if separate.

    Shell
    sudo mount /dev/sda1 /mnt/bootsudo mount /dev/sda2 /mnt/boot/efi
  4. Bind the virtual filesystems and chroot in.

    Shell
    for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; donesudo chroot /mnt /bin/bash
  5. Rebuild the initramfs with every driver rather than the host-only subset.

    Shell
    dracut -f --no-hostonly --add-drivers 'virtio_blk virtio_scsi virtio_pci ahci nvme' /boot/initramfs-$(ls /lib/modules | tail -1).img $(ls /lib/modules | tail -1)

    --no-hostonly builds a generic initramfs that carries drivers for hardware this machine does not currently have. It is larger and it boots on platforms the host-only build cannot see.

  6. On Debian-family, set MODULES=most in /etc/initramfs-tools/initramfs.conf, then rebuild.

    Shell
    update-initramfs -c -k all && update-grub
  7. Confirm root= in the GRUB config matches a device that exists.

    Shell
    grep -E 'linux|root=' /boot/grub2/grub.cfg | headblkid
  8. Exit, unmount and reboot.

    Shell
    exitsudo umount -R /mntsudo reboot
Confirm it workedThe system boots to a login prompt.
Shell
systemctl is-system-running
If you need to undo itThe old initramfs files are still in /boot under their own kernel versions — select one from the GRUB menu.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.