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

uname -r                      # running (working) kernel
ls /boot                      # find the version with no initrd/initramfs file
# Ubuntu 26.04 / Fedora (Dracut):
sudo dracut --force --kver 7.0.0-15-generic
# Debian, Ubuntu 24.04 and older, Mint 22:
sudo update-initramfs -c -k 6.8.0-85-generic
# Arch:
sudo mkinitcpio -P
# then (Debian/Ubuntu/Mint):
sudo update-grub

The screen ends with something like:

VFS: Cannot open root device "UUID=6f1c2a7e-..." or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

Version numbers in the commands on this page are examples. Use the exact versions from ls /boot on your system.

What the error means

The kernel started but could not mount the root filesystem, so it has nothing to run init from and halts. The numbers in brackets are the device's major and minor numbers. unknown-block(0,0) means no device was found at all, and an empty list after "here are the available partitions" confirms the kernel has no driver for your disk. On distribution kernels those drivers (NVMe, SATA, ext4, Btrfs, LUKS, LVM) live in the initramfs, so a missing or broken initramfs is the cause in the vast majority of cases. A non-zero pair such as unknown-block(259,2) instead means the disk was found but the filesystem could not be mounted: a wrong root= or a missing filesystem driver.

Cause 1: the initramfs was not generated (most common)

Typical after a kernel update when /boot was full, the machine lost power during the update, or a DKMS module build failed. Boot the older kernel: at the GRUB menu choose Advanced options and an earlier entry (hold Shift on BIOS systems or tap Esc on UEFI to show the menu). Then check:

ls -lh /boot

Example output:

initrd.img-6.8.0-84-generic
vmlinuz-6.8.0-84-generic
vmlinuz-6.8.0-85-generic        <- kernel with no matching initrd

If /boot is full (df -h /boot), remove old kernels first: sudo apt autoremove --purge on Debian/Ubuntu, or see No space left on device. Then rebuild the initramfs with your distro's tool.

Which initramfs tool does my distro use?

If you upgraded from Ubuntu 24.04 to 26.04 (upgrade guide), check which one is installed with dpkg -l dracut initramfs-tools | grep ^ii and use that. After rebuilding, refresh the boot menu so it gets an initrd line:

sudo update-grub                                   # Debian, Ubuntu, Mint
sudo grub2-mkconfig -o /boot/grub2/grub.cfg        # Fedora, openSUSE (BLS entries are picked up automatically)
sudo grub-mkconfig -o /boot/grub/grub.cfg          # Arch

Reboot into the new kernel. If dracut or update-initramfs print errors, read them: a failed DKMS module (NVIDIA, VirtualBox) is a common blocker and is fixed by removing or updating that module.

Cause 2: wrong root= or a changed UUID

If you cloned the disk, reformatted, or moved partitions, the root=UUID=... on the kernel command line may no longer exist. At GRUB press e and compare the root= value with the real UUID (from a live USB, lsblk -f). You can edit it in place and boot with Ctrl+X to test, as explained in kernel boot parameters. Make it permanent by regenerating the GRUB config from the booted system, and fix /etc/fstab too, otherwise you land in emergency mode next.

Cause 3: missing driver in the initramfs

When the initramfs exists but lacks the driver for the disk controller or filesystem, you get the same panic, often after switching the BIOS from AHCI to RAID/RST, moving the disk to new hardware, or a host-only initramfs built on another machine. Fixes:

• Switch the SATA mode back to AHCI in firmware settings (Intel RST/VMD hides NVMe drives from Linux on many laptops).
• Dracut: rebuild a generic image with sudo dracut --force --no-hostonly --kver <version>, or add the module with --add-drivers "nvme vmd".
• Arch: add the module to MODULES=() or make sure block (and encrypt/sd-encrypt, lvm2 if used) is in HOOKS in /etc/mkinitcpio.conf, then mkinitcpio -P.

Repair from a live USB (no working kernel)

If every kernel panics, boot a live USB of the same distro and chroot into the installed system. Replace device names with yours from lsblk -f:

sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi     # EFI partition, if UEFI
# separate /boot? mount it at /mnt/boot before the EFI partition
for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt
# inside the chroot, run the rebuild command for your distro, then update-grub
exit

On Arch use arch-chroot /mnt, which handles the bind mounts. Btrfs users must mount the root subvolume, e.g. mount -o subvol=root /dev/nvme0n1p3 /mnt on Fedora or subvol=@ on Ubuntu. If GRUB itself is broken, continue with reinstalling GRUB from a live USB.

Distro-specific notes

• Ubuntu 26.04: Dracut replaced initramfs-tools, so older answers that say update-initramfs do not apply to fresh 26.04 installs. The image is still named /boot/initrd.img-<version>.
• Debian 13 / Mint 22: update-initramfs -c -k <version> creates a missing image; -u only updates an existing one.
• Fedora: kernels are BLS entries in /boot/loader/entries; sudo kernel-install add <version> /lib/modules/<version>/vmlinuz regenerates both entry and initramfs.
• Arch: install linux-lts as a fallback kernel so you always have something that boots.

How to prevent it

• Keep at least two kernels installed and do not remove the running one.
• Keep /boot under 80% full; on Fedora leave installonly_limit=3 in /etc/dnf/dnf.conf.
• Do not interrupt updates. If one is cut off, run sudo dpkg --configure -a (Debian/Ubuntu) before rebooting.
• Read the end of the update output: initramfs or DKMS errors are printed there before you reboot into a broken kernel.

Frequently asked questions