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

Question

I had Windows 10 and Manjaro on my laptop and everything was OK. Last day, I've installed Kali Linux in another partition. It has installed correctly and it works fine. But the problem is when I want to boot my Manjaro. I select Manjaro on the grub menu but this is the screen I see.

wn-block(0,0)
[    0.667378] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.47-1-MANJARO #1
[    0.667435] Hardware name: Acer Aspire E5-575G/Ironman_SK  , BIOS V1.04 04/26/2016
[    0.667493]  ffffc90000c8bde0 ffffffff813151d2 ffff880276a77000 ffffffff8190b950
[    0.667717]  ffffc90000c8be68 ffffffff8117ecd4 ffffffff00000010 ffffc90000c8be78
[    0.667940]  ffffc90000c8be10 327c3b64ed88e616 327c3b64ed88e616 ffffc90000c8be80
[    0.668162] Call Trace:
[    0.668213]  [<ffffffff813151d2>] dump_stack+0x63/0x81
[    0.668267]  [<ffffffff8117ecd4>] panic+0xe4/0x22d
[    0.668321]  [<ffffffff81v2a590>] mount_block_root+0x27c/0x2c7
[    0.668377]  [<ffffffff81b298be>] ? set_debug_rodata+0x12/0x12
[    0.668432]  [<ffffffff81b2a640>] mount_root+0x65/0x68
[    0.668486]  [<ffffffff81b2a772>] prepare_namespace+0x12f/0x167
[    0.668542]  [<ffffffff81b2a1ca>] kernel_init_freeable+0x1ec/0x205
[    0.668598]  [<ffffffff81610b30>] ? rest_init+0x90/0x90
[    0.668652]  [<ffffffff81610b3e>] kernel_init+0xe/0x100
[    0.668706]  [<ffffffff8161dfd5>] ret_from_fork+0x25/0x30
[    0.668786] Kernel Offset: disabled
[    0.668893] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
_

How can I fix the problem?

Solution 1

Full diagnosis procedure based on kernel messages

By using this QEMU emulation setup I tried to produce minimal examples of every possible failure type to help you debug your problem.

In that simple setup, QEMU emulates a system with:

• a single virtio disk which represents a hard disk or SDD of real hardware
• that virtio disk has a raw unpartitioned ext4 image in it. In normal operation, that device would appear under /dev/vda (v is the indicator letter for virtio, if it were partitioned the partitions would be /dev/vda1, /dev/vda2, etc.)

The possible errors you could get are:

1. Linux cannot read bytes from the disk.

   This could be either because the disk is broken, or because you didn't configure Linux with the ability to read from that hardware type.

   In my QEMU case I can reproduce this by removing the key options that allow the kernel to read that virtio disk:

   CONFIG_VIRTIO_BLK=y
   CONFIG_VIRTIO_PCI=y
   

   The resulting error message is looks like this

   <4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
   <4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
   <0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
   

   So here Linux tells us that it can't read from vda at all at: VFS: Cannot open root device "vda" or unknown-block(0,0): error -6.

   Then, at Please append a correct "root=" boot option; here are the available partitions: it gives a list of partitions it could read.

   In our case, the list is empty however, since the next line is completely unrelated.

2. Linux can read bytes from the disk, but it doesn't understand the filesystem to read files out of it.

   This is normally because you didn't configure the kernel to read that filesystem type.

   I can reach this case by removing the kernel's ability to read an ext4 filesystem:

   CONFIG_EXT4_FS=y
   

   With that removed, the error message is:

   <4>[    0.585296] List of all partitions:
   <4>[    0.585913] fe00          524288 vda
   <4>[    0.586123]  driver: virtio_blk
   <4>[    0.586471] No filesystem could mount root, tried:
   <4>[    0.586497]  squashfs
   <4>[    0.586724]
   <0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
   

   So Linux tells us that it managed to find a vda partition by reading the disk with the virtio_blk device.

   But then, it was not able to read that partition. It tried squashfs, which is the only other filesystem we have enabled, but that didn't work, because we have an ext4 partition.

3. You passed the wrong root= kernel command line option.

   This one is easy, just pass the correct one! The kernel even gives you a list of the ones it knows about!

   For example, if we pass a wrong:

   root=/dev/vda2
   

   which doesn't even exist, the kernel gives an error of type:

   <4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
   <4>[    0.609563] fe00          524288 vda
   <4>[    0.609723]  driver: virtio_blk
   <0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
   

   clearing telling us that "hey: there is no vda2, but there is a vda!"

   This example also clarifies well what the (0,0), (254,0) and (254,2) meant from previous cases:

   • (0,0): first number 0 means could not read from the disk at all
   • (254,2): 254 is some ID that got assigned to the disk. 2 is the partition withing that ID as in /dev/vda2. And partition 0 means a raw non-partitioned partition as in /dev/vda.

Tested on Linux 5.4.3.

Solution 2

VFS: unable to mount root fs on unknown-block(0 0) means the kernel was unable to mount the root filesystem. There are two common causes for this:

1. The kernel doesn't support the filesystem on the device. If you compiled your own kernel, this is usually because you specified the filesystem driver should be built as a module rather than a native part of the kernel; if you're using the distro's kernel, this is usually because you picked an exotic format for your root filesystem. In either case, don't do that.

2. The name of the root device passed to the kernel is wrong. This one can be tricky to fix: the best method I've found is to modify the kernel command line from the bootloader, making educated guesses about what the root= parameter should look like until I find something that works.

Solution 3

VFS: unable to mount root fs on unknown-block(0 0)_ _ _

1. long press on power button to shutdown your laptop.
2. select the “advanced” option.
3. select lowest version of generic (“recovery mode”)
4. click on “clean” “try to make free space”
5. and then “resume” “resume normal boot”

Solution 4

There is a third cause, which happened be my issue:

Typically in each grub menu item, there is a 'linux ... ' line and a 'initrd .... ' line.

Because I had run out of room in /boot, I had removed an initrd.... file, ran update-initramfs for a different kernel version, but neglected to run update-grub, which will update the appropriate entries.

I repaired this by manually adding the line in the boot menu during the boot sequence, then made it permanent once logged in and could run update-grub.

Solution 5

@HasanQ was closest to the right answer, but still incomplete.

It is to do with Arch-based Distros NOT loading intel-ucode and amd-ucode from within the kernel, but performing it separately, which can be seen quite easily from the respective entries in Grub Menu, if you press 'e' to edit and examine startup parameters - look at the bottom line.

This occurs across Debian-based Distros (eg Mint, Ubuntu), RPM-based Distros (eg Fedora, Mageia) and Gentoo-based Distros (Calulate and Sabayon). I have not tried it with Slackware. You do NOT have to use the Arch-based bootloader.

You can instead create a custom.cfg file which you can place wherever grub.cfg is, typically /boot/grub - no need to update grub, just reboot and choose the entry at bottom of menu.

You can read about it at linux dot org or at endeavouros forum.

Elsewhere, on Installed Manjaro or other Arch alongside other Distro, then Kernel Panic later, I have written the following:

If you are running just Manjaro (or other Arch-based Distro) on your computer, or even dual-booting with Windows, and you then choose to install an additional Distro that is not Arch-based, then this article is for you.

If you are dual-booting or multi-booting even one more Linux that is not Arch-based, chances are you are going to come across a Kernel Panic.

It will occur following updates and upgrades executed on the non-Arch distro, which are sufficient to cause that distro to assume the spot of Primary Partition, that is, top of your Grub Menu.

This article applies to GRUB only, although I would be interested to hear from rEFInd users and users of other bootloaders.

The packages updated and upgraded which will generate this change in order include but are not limited to some combination of the following:

• Your kernel
• Grub, grub-efi, grub-pc, grub-signed and so on
• Shim, shim-signed
• Some major firmware updates
• Other (you’ll find them, or they'll find you!)

You’ll reboot your computer, the other distro will now be in top spot and work fine, and then you key down to choose Manjaro and...

Kernel Panic

The Kernel Panic will dump you to a black and white (tty-style) screen with output looking similar to the following

Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0)

This will be followed by a CPU reference, hardware name, a call trace, a Kernel Offset, and end with

---[ end Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0) ]---

You cannot exit or get a response other than to power down and start again, and this time not choose Manjaro.

It has been said that the only way to prevent this circumstance is to be sure the Manjaro (or other Arch, Arch-based) Grub is in control.

That is not so.

It is simply a matter of generating a file called custom.cfg and storing it in your (/boot/grub) folder (could be /boot/grub2 in some distro families) and an entry or entries for that will appear at the end of your Grub Menu once you reboot. No need to update Grub. Just do it.

I will now show you how to do this.

I will take the shortest way to summarising it, because I know there are users out there in need of this, and then I will fill out more detail for those generally and genuinely interested. So it may be a Thread in instalments.

PREPARATION

1. If you are a user of Timeshift, BackInTime, Snapper or similar system restore tool, first take a snapshot/image of whatever working OS you have operating and safeguard that.

2. Get the UUID of the root partition of your Endeavour or other Arch-based distro and have it handy, you will need to enter it. This can be obtained by a number of methods, including, but not limited to the following-

   1. In Gparted, right click the root partition, click info
   2. In Terminal use blkid | grep -i <label of distro if labelled>
   3. Check for it in /etc/fstab
   4. Other means

3. Decide what text editor, whether CLI or GUI, you want to use to make a small text file, and be aware that the resulting file will need to be placed in (/boot/grub), or specifically, in the folder where your grub.cfg file is stored.

   This will require root privileges, for example sudo, or assuming root.to the non-Endeavour, non-Arch-based distro (for example boot into Linux Mint) that is in the primary partition (top) spot on your Grub Menu.

4. Boot to the non-Endeavour, non-Arch-based distro (for example boot into Linux Mint) that is in the primary partition (top) spot on your Grub Menu.

STEPS

A typical EXT4 UUID will be in the format of 32 digits and alphabetical characters, structured like this (8 then 4 then 4 then 4 then 12, separated by dashes)

7b52a802-aa6d-4aa2-aab5-5dffbe6833c6 

For this exercise I will use

nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn 

and you substitute the value by copying/pasting the result you got from Prep Step 2. 1.-4. above.

1. Either use touch to create the file custom.cfg and then your favourite text editor, or I just use nano as follows

2. sudo nano custom.cfg

   and enter this text, where the string of n’s is the UUID for your Endeavour or other Arch-based distro’s root partition

   menuentry "Manjaro - configfile" { 
   insmod part_gpt 
   part part_msdos 
   insmod ext2 
   search --no-floppy --fs-uuid --set=root nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn
   configfile /boot/grub/grub.cfg
   }
   

   The part in quotes in the first line is a choice for you, you could call it “My beloved Manjaro” if you wished.

   Other than that, make sure the syntax matches exactly, including those two curly brackets.

3. Save and exit, or exit and save, the file, with it in (/boot/grub) or wherever your grub.cfg file is.

4. Reboot (no need to update grub)

If you have followed the above correctly, when you see your GRUB menu it will have an additional entry at the end saying what was in that first line. That is your new entry point to Manjaro or your chosen Arch-based distro.

There will still be the other entry for Manjaro in the ordered GRUB menu list, but if you choose that you will still encounter the kernel panic, so practise picking the end one.

View more solutions

Comments

[Milad Heydari]

thanks for the responding. but I don't know what to do now. I had Manjaro and everything was ok but after installing Kali the grub screen has changed and when I want to boot Manjaro I get the error. But It is ok for Kali. @Mark

[Alessio]

kali has messed with your grub.cfg, and now the root= option for manjaro doesn't point to the majjaro root fs. easiest way to fix is to boot kali, list all the partitions (e.g. with lsblk or blkid), write the device names that have a filesystem (e.g. ext4, xfs) except those that you know are used by kali on a notepad and then reboot into grub. edit the manjaro entry and change the root= option on the linux line to one of the partitions. if that partition doesn't work, reboot and try again with another until you find it. when you boot manjaro, run sudo update-grub.

[Alessio]

if it's not already installed in manjaro, you should install the os-prober packager and run update-grub again. this should allow update-grub to detect the kali partition and create a boot entry for it.

[Kusalananda]

The user in the question does not seem to be running in a VM though.

[gregn3]

In my case I used the wrong kernel and initrd, the ones installed in the root /vmlinuz and /initrd.img didn't work, but the ones in /boot/ did work.

[Mark]

I find this unlikely: the kernel only needs a few megabytes of RAM to get to the point of mounting the root device.

[Algoman]

I had tried to boot a kernel without initrd. I had compiled that kernel with manjaros .config which contains CONFIG_EXT4_FS=m. So it would have needed the initrd to be able to use the root drive, because that was formatted as ext4. CONFIG_EXT4_FS=y solved it for me, thank you!

[Admin]

I can add a new one to the list of obscure causes of this: after a hard freeze, my server's BIOS switched the SATA ports from AHCI mode to legacy mode, and my kernel didn't have the legacy mode driver needed.