Solution to kernel panic VFS unable to mount root fs on unknown-block(0,0)

When the dreaded message “Kernel panic – not syncing: VFS: unable to mount root fs on unknown-block(0,0)” appears on your screen , it's normal to panic. Suddenly, your Linux system won't boot, the console freezes with a wall of text, and it seems like you've lost everything. The good news is that, in most cases, you haven't lost any data, and the situation can be fixed if you calmly follow a few steps.

This problem can occur in various scenarios: when installing a new Linux distribution (such as Linux Mint), when updating Ubuntu, when booting a CentOS server, or when starting a virtual machine with Ubuntu or another distribution . Although the contexts differ, the kernel error is similar, and the causes usually revolve around the same issue: the kernel cannot mount the root filesystem. In this article, we will explain, in detail and in the clearest possible language, what this error means and how to fix it in each specific case.

What does the error “kernel panic – VFS: unable to mount root fs on unknown-block(0,0)” mean?

When the kernel boots, one of its first tasks is to locate and mount the partition that will contain the root filesystem “/” . To do this, it needs to know which device it is on (for example, /dev/sda2), what type of filesystem it uses (ext4, xfs, etc.), and have the necessary modules to access that device (disk controllers, controller drivers, etc.).

The message “VFS: unable to mount root fs on unknown-block(0,0)” indicates that the kernel's virtual file system (VFS) was unable to mount the root directory. The “unknown-block(0,0)” shows that it couldn't even correctly identify the block device from which it should boot. In other words, for the kernel, the disk containing your “/” is practically invisible or inaccessible at that moment.

This failure can be due to several causes: missing or corrupt initramfs image, changes in the UUID or disk mapping, drivers that do not load, errors in the boot loader (GRUB) or even partition and partition table configuration problems.

An important point that often reassures many people is that a kernel panic doesn't necessarily imply data loss . What has failed is the boot process, but the partitions, in the vast majority of cases, remain intact, waiting for us to boot a rescue environment or a working kernel to access them.

Many error screens also display secondary messages such as “SGX disabled” or warnings from other modules, which can be misleading. These lines are usually not the root cause of the problem, but simply informational messages about processor or system features. The key is always in the phrase related to VFS and the root mount.

Typical cases: Linux Mint installation, Ubuntu upgrade, CentOS, and virtual machines

This kernel panic error usually occurs in very specific situations. Understanding these scenarios helps you figure out what might have gone wrong and what steps to take. One of the most common cases is trying to boot a newly installed system, such as Linux Mint 21.2 Cinnamon, for the first time after manually creating the partitions.

A real-world example: A user on a Windows laptop decides to install Linux Mint using BalenaEtcher to burn the ISO to a 16 GB USB drive . They check in Windows that the computer uses UEFI firmware, enter the BIOS, select the bootable USB drive, and boot into the Mint live session. So far, everything seems normal. The problem arises when, during the installation, a manual partitioning is performed, creating a new partition table on /dev/sda (1 TB), a 512 MB EFI partition on /dev/sda1, 2 GB of swap space, a 10 GB root partition (/) formatted as ext4, and /home using the remaining disk space.

In that specific scenario, /dev/sda1 (the EFI partition) is also selected as the device for installing the boot loader . The installation finishes, options such as installing codecs are selected, and the user is created. Then, instead of restarting, the user decides to run "apt update" and "apt upgrade" in the live session to exit with the updated system. Upon restarting, instead of booting correctly, the infamous kernel panic occurs, and the user is stuck between the BIOS and Mint's boot options.

Another typical scenario occurs after upgrading Ubuntu to a newer version . In theory, this should be a seamless process: the new kernel is downloaded, the necessary files are generated, and GRUB is updated. However, sometimes the step of generating the initramfs for the newly installed kernel fails or doesn't execute correctly . The system appears to upgrade without issue, but upon rebooting, the error “Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)” appears, and there's no way to boot into the new kernel.

There are also very common cases in server environments, for example, in CentOS 6.x after applying updates . On some servers, after a `yum update` or similar command, the new kernel can become corrupted or incorrectly installed. When attempting to boot, the system experiences a kernel panic and stops. In these environments, the priority is obviously to restore service as quickly as possible, so there are specific procedures involving rescue mode and reinstalling the kernel package.

Finally, we mustn't forget virtual machines (VMs) running Ubuntu or other distributions . Sometimes, when starting the VM, the system displays the message “end kernel panic: not syncing: VFS: unable to mount root fs on unknown-block(0,0)” and freezes completely. In these cases, it's usually possible to boot using only an older kernel by accessing “Advanced options for Ubuntu” from the VM's GRUB menu, while the newer kernel will always fail with the same error.

Main technical causes of the root fs mount failure

Underlying all these cases are a number of recurring technical issues. One of the most common causes, especially after Ubuntu updates or new kernels, is the absence or corruption of the initramfs corresponding to the kernel version being loaded . The initramfs is an image containing a minimal filesystem with the modules and tools necessary to mount the actual root directory.

If the initramfs is missing, corrupted, or doesn't contain the necessary modules to access the disk where the root partition is located, the kernel will never be able to mount "/" . That's why many tutorials on this error emphasize "regenerating the initramfs" and ensuring that GRUB correctly recognizes the image for the affected boot entry.

Another common cause involves problems with the GRUB bootloader : misconfigured paths, changed UUIDs, entries pointing to an incorrect disk or partition, or installations where the EFI partition has been incorrectly mounted. In the example of Linux Mint with manual partitioning, a very common mistake is installing GRUB on the wrong EFI partition, or failing to respect the UEFI/Legacy configuration , which causes the firmware or GRUB to boot either the incorrect kernel or without the proper parameters.

On CentOS servers and similar environments, in addition to initramfs, corrupted kernel packages or inconsistencies in the RPM database can also cause problems . If the package database is corrupted, the package manager may leave the kernel incomplete or with essential files missing, leading to a kernel panic on the next reboot.

In virtual machines, in addition to the problems already mentioned, you must consider the configuration of virtual disks, controllers (IDE, SATA, SCSI, VirtIO), and virtual hardware changes . If you modify the VM's disk controller type and the kernel doesn't have the appropriate module in its initramfs, the same thing can happen at boot time: the disk isn't detected , and the system is stuck with an unknown-block(0,0).

In all cases, there's a constant: the kernel fails to detect a valid block device containing the usable root filesystem . The key to repairing this lies in restoring the path between the kernel and root: fixing initramfs, reinstalling the kernel, correcting the GRUB configuration, or adjusting the visible partitions and devices.

Solution in Ubuntu: regenerate initramfs and update GRUB

When the problem arises after updating Ubuntu to a newer version or installing a more modern kernel , one of the most effective solutions is to regenerate the initramfs image of the affected kernel and update the boot loader. This process relies on the fact that there is usually still a working older kernel that allows you to log into the system.

The first step is to access the GRUB menu . To do this, restart your computer and, immediately after the BIOS/UEFI boots, repeatedly press the Shift key (on many BIOS systems) or Esc key (on some UEFI systems) until the GRUB screen appears. There you will see a main entry such as “Ubuntu” and another called “Advanced options for Ubuntu”.

Within “Advanced options for Ubuntu” is a list of all installed kernel versions . The idea is to select an older version that you know worked before the update. Usually, the newest entry is the one causing the kernel panic, so it's best to choose the one immediately preceding it (for example, if 5.15.x fails, try 5.13.x). Select that entry and press Enter to boot into it.

Once the system boots successfully with the old kernel, open a terminal. From there, proceed to regenerate the initramfs of the kernel that was failing . The typical command in Ubuntu would be something like:

sudo update-initramfs -c -k

Replacing `<kernel-version>` with the exact string of the problematic version, for example, 4.15.0-36-generic , or the version shown in the error message or in the output of `uname -r` if needed. This command creates (or recreates) the initramfs image for that specific kernel version, including the modules and utilities necessary to mount the root directory.

After regenerating the initramfs, it is essential to update GRUB so that it correctly detects the new image and adjusts the boot parameters. To do this, run:

sudo update-grub

This command will scan the system, find the different kernel versions, rebuild the GRUB menu, and correctly link each kernel with its corresponding initramfs. Once the process is complete, simply restart your computer normally, without changing anything in GRUB, to check if the system now boots with the new kernel without a kernel panic.

CentOS server recovery in rescue mode

In the server world, especially with CentOS 6.x (and similar RHEL versions) , a kernel panic after an update can be quite alarming, but there's a fairly straightforward solution using rescue mode. The general idea is to boot from external media, mount the installed system, chroot into it, and repair the kernel and package database if necessary.

The first step is to boot the server from a rescue disk , which can be a CD/DVD or an ISO mounted from the server's administration console (iLO, iDRAC, remote KVM, etc.). When booting from this media, instead of choosing a normal installation, select the "Rescue installed system" option or something similar. If this option doesn't appear directly, you can enter rescue mode by typing the following at the boot prompt:

boot: linux rescue

From there, the wizard will ask you to choose your language and keyboard layout , and will offer the option to activate the network, for example, via DHCP. Activating the network can be useful if you will need to download packages or access external repositories during the repair process.

Once the rescue environment has detected the installed system, it will mount the root partition at /mnt/sysimage . After booting into a shell within this environment, the next step is to log into the system as if it had actually booted, using the command:

chroot /mnt/sysimage

From this point forward, all commands executed will affect the actual server system, not the rescue environment. This is where repairing with yum comes in. A common problem is a corrupted RPM database , which prevents kernel packages from being managed correctly. To check this, you can first try the following:

yum clean

If this command returns errors related to opening the databases, you need to delete them manually. To do this, access the directory where they are stored:

cd /var/lib/rpm

And the temporary database files are deleted:

rm -f __db.00*

After this deletion, another attempt is made to clean up yum, this time more thoroughly:

yum clean all

If it's working now, it means the RPM database has been rebuilt successfully. The next key step is to reinstall the kernel package , which is often the source of kernel panics when files are corrupted or missing. To do this, run:

yum reinstall kernel

This command will force the download and installation of all current kernel files, including the kernel binary itself, the initramfs, and any related dependencies. Once the reinstallation is complete, exit the chroot environment, stop the rescue environment, and restart the server normally. If everything went well, the server should boot without a kernel panic and without data loss.

Boot problems in virtual machines with Ubuntu

In the case of virtual machines, the message “end kernel panic: not sync: VFS: unable to mount root fs on unknown-block(0,0)” usually appears when starting the VM, leaving the system completely frozen. This situation can be very frustrating because the only way to access the system is through an older kernel version, selected from the “Advanced options for Ubuntu” menu in GRUB.

If the VM allows booting with an older kernel, the strategy is very similar to that described for bare-metal Ubuntu: boot with the working kernel, regenerate the initramfs of the problematic kernel, and update GRUB . This is usually enough for the new kernel to regain its ability to mount root and for the system to boot normally again.

When dealing with a VM, you also need to check the hypervisor configuration (VirtualBox, VMware, KVM, Hyper-V, etc.) . Changes in the disk controller type (for example, switching from SATA to VirtIO) or in disk allocation can prevent the kernel from finding the correct device if its initramfs doesn't contain the necessary modules for that specific disk controller.

Some forums mention that the problem occurs "even though virtualization is already enabled" in the host BIOS, which can be misleading. The truth is that, with very few exceptions, processor virtualization options (VT-x, AMD-V) are not directly related to the kernel VFS error . Enabling them only guarantees that the VM will run with better performance, but the kernel panic is usually more closely linked to the VM's internal configuration (disks, controllers) or the kernel/initramfs itself within the guest distribution.

If the problem persists after regenerating initramfs and updating GRUB, you can try booting the VM from a live ISO , mounting the virtual disk of the affected machine, and manually checking the GRUB configuration files, the contents of /boot, and the presence of the initramfs files corresponding to each installed kernel version.

Errors when installing Linux Mint with manual partitioning and UEFI

Returning to the case of installing Linux Mint 21.2 Cinnamon with a UEFI BIOS and manual partitioning , many users make minor configuration errors that result in a kernel panic when mounting the root directory. The typical process involves creating a new partition table in /dev/sda (erasing all previous contents), defining an EFI partition, swap, root, and /home, and then selecting the EFI partition as the bootloader installation destination.

While this sounds correct in principle, there are several tricky points. For example, the EFI partition must be of type “EFI System Partition” (ESP), formatted as FAT32, and mounted at /boot/efi . If it's simply created as a regular partition in the installer, without being properly marked as EFI, GRUB may not install correctly, and the UEFI firmware may not recognize it as a valid boot partition.

Another critical detail is ensuring that the device selected for the bootloader is the entire disk (e.g., /dev/sda) or the correct EFI partition , as recommended by the specific distribution and installer. In some cases, manually choosing /dev/sda1 as the destination when the distribution expected to install GRUB on /dev/sda can cause the system to fail to generate the correct boot structure, resulting in a broken boot process upon reboot.

Running `apt update` and `apt upgrade` from the live session before the first reboot is also not recommended, because you're updating the live environment, not necessarily the system already installed on the disk. This can cause confusion and, under certain circumstances, even affect packages that might impact the installer or the boot files.

When, after installation, the computer gets stuck in a loop between BIOS and Mint boot options, and every boot attempt results in a kernel panic, one solution is to boot from a live USB drive, mount the installed system, and check the EFI partition, the contents of /boot/efi, the fstab configuration, and the GRUB entries . In some cases, it will be faster and cleaner to repeat the installation, ensuring that the GPT partition table and the EFI partition are configured correctly from the start.

You can also check the BIOS/UEFI for options that might affect booting, such as MOK and Secure Boot , UEFI vs. Legacy/CSM mode, or the boot order . Even if the kernel message mentions "SGX disabled," that line is usually irrelevant to the specific VFS problem; the important thing is that the firmware finds and launches the correct GRUB and that it points to the appropriate kernel and initramfs.

When to use an external device or a live system to recover data

In all these scenarios, a very common concern is whether an external device is needed to access the disk and recover files . The answer depends on the urgency and whether the system still has a working kernel to boot from, either in "Advanced Options" or via an older GRUB entry.

If the system can still boot with an older kernel version (as in the case of a VM with Ubuntu or some desktop installations), the best approach is to use that working kernel to create full backups before making any more significant changes. You can connect an external USB drive and copy /home or any other critical directory, or even use cloning tools if you want to save a complete system image.

When no kernel can boot and the system repeatedly enters a kernel panic, then it's advisable to boot from an external medium: a USB drive with a live distribution, a rescue ISO, a CD/DVD, etc. From this live environment, you can mount the internal hard drive, access the partitions (usually ext4 or others), and extract the desired data, either to an external drive, over the network, or however you prefer.

This same live environment can also be used to repair the installation in place , by running commands such as chroot, reinstalling the kernel, regenerating initramfs, or repairing GRUB. In fact, many guides recommend this approach, especially when the system is severely damaged or when the installed environment cannot be accessed using a previous kernel.

It's important to emphasize that a kernel panic, by itself, does not destroy data or delete partitions . It's a kernel security mechanism that halts the system when it encounters serious errors that compromise its integrity. The priority should be to avoid forced shutdowns or unusual disk manipulations, and if there is important data, focus first on securing backups before attempting any repairs.

Knowing all this, this type of error ceases to be an "end of the world" and becomes a technical setback that can almost always be resolved: by booting from an old kernel or from a rescue environment, regenerating the initramfs, reinstalling the kernel or correcting the GRUB configuration and partitions , the system can be remounted to its root and boot normally without losing information.

Related articles:

"Unknown filesystem" error in GRUB: causes, real cases and how to fix it step by step

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.