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

When the dreaded message appears on the screen “Kernel panic – not syncing: VFS: unable to mount root fs on unknown-block(0,0)” It's normal to get nervous. 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 different scenarios: when installing a new distro (such as Linux Mint), when updating Ubuntu, when booting a CentOS server, or when starting a virtual machine with Ubuntu or another distributionAlthough the contexts may 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 break down, in detail and in the clearest language possible, what this error means and how to fix it in each real-world scenario.

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

When the kernel starts up, one of its first jobs is Locate and mount the partition that will contain the root file system “/”To do this, you need to know which device it is on (for example, /dev/sda2), what type of file system 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)” This 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 corrupted initramfs image, changes in UUID or disk mapping, drivers that fail to load, bootloader (GRUB) errors or even partition and partition table configuration problems.

One important point that usually reassures many people is that A kernel panic does not in itself imply data lossThe boot phase has failed, but the partitions, in the vast majority of cases, remain intact, waiting for us to boot a rescue environment or a functional 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 characteristics. 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. Knowing these scenarios helps to understand what might have gone wrong and what steps to take. One of the most frequent 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 driveCheck in Windows that the computer uses UEFI firmware, enter the BIOS, select the bootable USB drive, and enter the Mint live session. So far, everything seems normal. The problem arises when, during installation, a manual partition is created with creating a new partition table on /dev/sda (1 TB), a 512 MB EFI partition on /dev/sda1, 2 GB swap, a root (/) partition of about 10 GB in ext4, and /home using the rest of the disk.

In that specific scenario, it is also selected /dev/sda1 (the EFI partition) as the device for installing the bootloaderThe installation finishes, options such as codec installation are selected, and the user is created. Then, instead of restarting, it is decided to run a program in the live session. “apt update” and “apt upgrade” to exit with the system already updated. Upon restarting, instead of booting correctly, the infamous kernel panic appears, and the user is trapped between the BIOS and Mint's boot options.

Another typical scenario occurs after upgrading Ubuntu to a higher versionIn theory, it should be a transparent process: the new kernel is downloaded, the necessary files are generated, and GRUB is updated. However, sometimes the generation step of the The initramfs of the newly installed kernel fails or does not execute correctlyThe system seems to update without problems, but upon restarting, the error “Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)” appears, and there is 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 updatesOn some servers, after a `yum update` or similar command, the new kernel can become corrupted or improperly installed. When attempting to boot, the system experiences a kernel panic and crashes. In these environments, the priority is obviously to restore service as quickly as possible, so there are specific procedures in place. rescue mode and reinstallation of the kernel package.

Finally, we must not forget the Virtual machines (VM) with Ubuntu or other distrosSometimes, 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 always fails with the same error.

Main technical causes of the root fs mount failure

Underlying all these cases are a number of recurring technical reasons. 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 loadedThe initramfs is an image that contains a minimal file system with the modules and tools necessary to mount the actual root.

If the initramfs is missing, corrupted, or does not contain the appropriate modules to access the disk where the root partition is located, the kernel will never mount “/”That's why many tutorials on this error emphasize "regenerating the initramfs" and ensuring that GRUB correctly picks up that image for the affected boot entry.

Another common cause has to do with GRUB bootloader problemsIncorrectly configured paths, changed UUIDs, entries pointing to an incorrect disk or partition, or installations where the EFI partition has been mounted incorrectly. In the example of Linux Mint with manual partitioning, a very common error is Installing GRUB on the wrong EFI partition, or not respecting the UEFI/Legacy settingsThis causes the firmware or GRUB to not boot the correct kernel or to do so without the appropriate parameters.

On CentOS servers and similar environments, in addition to initramfs, other factors can also be affected. corrupted kernel packages or inconsistencies in the RPM databaseIf the package database is corrupted, the package manager may leave the kernel incomplete or with essential files missing, leading to a kernel panic at the next reboot.

In virtual machines, in addition to the problems already mentioned, the configuration of virtual disks, controllers (IDE, SATA, SCSI, VirtIO) and virtual hardware changesIf we change the VM's disk controller type and the kernel doesn't have the appropriate module in its initramfs, the exact same thing can happen at boot time: He doesn't see the disc and it ends up with an unknown-block(0,0).

In all cases there is one constant: The kernel fails to detect a valid block device with a usable root filesystemThe key to the repair will be to restore that path between kernel and root: fix initramfs, reinstall kernel, correct GRUB configuration, or adjust visible partitions and devices.

Solution in Ubuntu: regenerate initramfs and update GRUB

When the problem appears after upgrade Ubuntu to a newer version or install a more modern kernelOne 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 the system to boot.

The first thing to do is access the GRUB menuTo 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” a list of all installed kernel versionsThe idea is to select an older version that is known to have worked before the update. Usually, the newest entry is the one that causes a 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, you need to open a terminal. From there, proceed to regenerate the initramfs of the kernel that was failingThe typical command in Ubuntu would be something like:

sudo update-initramfs -c -k

Replacing for the exact string of the problematic version, for example 4.15.0-36-generic or the one that appears in the error message or in the output of uname -r If it needs to be checked. This command creates (or recreates) the initramfs image for that specific kernel version, including the modules and utilities needed to mount the root.

After regenerating the initramfs, it is essential update GRUB to ensure 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 world of servers, especially with CentOS 6.x (and similar versions of RHEL)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 diskThis 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 does not appear directly, you can enter rescue mode by typing the following at the boot prompt:

boot: linux rescue

From there, the assistant will ask you to choose language and keyboard layoutIt will also offer the option to activate the network, for example via DHCP. Activating the network can be useful if you 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 to /mnt/sysimageWhen starting a shell within this environment, the next step is to log into the system as if we had actually booted it, 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 typical problem is that the RPM database is corruptThis prevents the kernel packages from being managed properly. 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 reinstall the kernel packagewhich is usually the cause of a kernel panic 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, stop the rescue environment, and restart the server normally. If everything went well, The server should start without kernel panic and without data loss.

Boot problems in virtual machines with Ubuntu

In the case of virtual machines, the message of “end kernel panic: not sync: VFS: unable to mount root fs on unknown-block(0,0)” This error usually occurs 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 into 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 the root directory and for the system to boot normally again.

When it comes to a VM, you also have to check the hypervisor configuration (VirtualBox, VMware, KVM, Hyper-V, etc.)Changes in disk controller type (e.g., switching from SATA to VirtIO) or disk allocation can cause the kernel to fail to find the correct device if its initramfs does not contain the necessary modules for that particular disk controller.

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

If the problem persists after regenerating initramfs and updating GRUB, you can resort to boot the VM from an ISO in live modeMount the virtual disk of the affected machine and manually check 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 BIOS in UEFI mode and manual partitioningMany users fall into minor configuration errors that result in a kernel panic when mounting the root directory. The typical process involves creating a new partition table on /dev/sda (deleting all previous contents), defining an EFI partition, swap, root, and /home, and then selecting the EFI partition as the bootloader installation destination.

Although this sounds correct in principle, there are several sensitive points. For example, the The EFI partition must be of type “EFI System Partition” (ESP), formatted as FAT32, and mounted at /boot/efiIf it is simply created as an ordinary partition in the installer, without properly marking it as EFI, GRUB may not install correctly and the UEFI firmware may not recognize it as a valid boot partition.

Another critical detail is to make sure that The device selected for the boot loader is either the entire disk (e.g., /dev/sda) or the correct EFI partitionAccording to the specific distribution and installer, manually selecting /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.

The fact Perform an “apt update” and “apt upgrade” from the live session before the first reboot This isn't the best approach either, 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 time you try to boot it, it reaches a kernel panic, one possible solution is Restart a live session from the USB drive, mount the already 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 BootUEFI vs Legacy/CSM mode or boot orderAlthough the kernel message mentions "SGX disabled", that line is usually irrelevant to the specific VFS problem; what's important 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 if an external device is needed to access the disk and recover filesThe answer depends on the level of urgency and whether the system still has a working kernel to boot from, either in "Advanced options" or through an old GRUB entry.

If the computer can still boot with an older kernel version (as in the case of a VM with Ubuntu or some desktop installations), the most convenient option is take advantage of that working kernel to make full backups Before touching anything more serious, you can connect an external USB drive and copy /home or any critical directory, or even use cloning tools if you want to save a complete system image.

When there is no kernel that boots and the system always goes into kernel panic, then it is worthwhile. Boot from an external medium: USB drive with a live distro, rescue ISO, 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 medium also serves to repair the installation on siteThis involves running commands like 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 using a previous kernel is inaccessible.

It is important to emphasize that The kernel panic, by itself, does not destroy data or delete partitions.It is a kernel security mechanism that shuts down 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: booting from an old kernel or rescue environment, regenerating the initramfs, reinstalling the kernel, or correcting the GRUB configuration and partitionsThis allows the system to reassemble 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.