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.

[    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?

  • 1
    Might be unrelated to your environment, but I encountered the same issue while trying to boot up from an SD card over an FPGA-based development board. I realized that the issue was caused by the physical lock switch of the SD card. Silly me :/ Dec 8, 2022 at 8:21

14 Answers 14


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.

  • 2
    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 Jan 3, 2018 at 23:48
  • 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.
    – cas
    Jan 4, 2018 at 2:13
  • 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.
    – cas
    Jan 4, 2018 at 2:14
  • 1
    ps: see unix.stackexchange.com/questions/399626/…
    – cas
    Jan 4, 2018 at 2:16
  • 1
    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.
    – gregn3
    Jan 5, 2020 at 3:17

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:


    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:


    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:


    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.

  • 1
    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!
    – Algoman
    Apr 4, 2021 at 13:05

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”
  • How long will it take to resume normal boot?
    – anilbey
    Sep 22, 2022 at 19:06

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.


@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.


  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.


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)


For this exercise I will use


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.


I guess i found another solution.

I had the exact same problem with Debian instead of Kali. I had a fresh Windows 10 install, second Manjaro, and third Debian. The solution is at the Bottom.

How i found out about the solution:

After i installed Debian, grub changed to the grub of Debian, instead of Manjaro, how it should be. But i got the error like in the picture posted in the question above.

However with "Super Grub2 Disk" on an USB i was able to boot into Manjaro.

When i boot from "Super Grub2 Disk" it shows me the entries of the old Manjaro and new Debian grub menus. Using the old Manjaro entry in the Manjaro grub still works. So i can boot into Manjaro like that.

I also can look at each entry and edit them. I looked at the Manjaro entry in both grubs. They seem quite different, but the UUID and root commands and file type definition look the same (As far as i can say, i am no expert or advanced user).

"Super Grub2 Disk" tells me that i have one grub on sda5 and one on sda6, which seems right, because sda5 is Manjaro and sda6 Debian.

Seems like the grub of Debian (and maybe Kali) sadly isn't working right. (I really wonder why)

So the solution for me was to boot into Manjaro (via "Super Grub2 Disk") and run sudo grub-install /dev/sda5 to simply get the Manjaro grub version back. and use sudo update-grub so it updates to also show Debian as boot entry. (sda5 may be replaced with the correct partition of Manjaro, so it could be sda1 sdb1 or something like that)

(just in case somebody has the same issue, to run the command in Debian, without sudo installed. Use su - (instead of typical su) to use the commands without the sudo. I am not sure what this does, but it seems like you as a User become root privileges.)

I had a disk using MBR and a laptop without EFI or GPT support, so i can't change to boot to another grub in the BIOS. My other laptop can do this. So simple changing to the old Manjaro grub in the BIOS (and updating grub in Manjaro as mentioned earlier) should do the trick.

I would say it would be a good solution to tell the MBR which grub to use, and grub which boot entries it should have, by writing to the corresponding configuration, to gain control of the boot process and finally prevent future errors. But i am not yet advanced enough to do that.


The real answer to this problem (specifically for people using Manjaro) from what I've heard is to only use Manjaro's version of GRUB to boot. Make sure you're booting from your Manjaro partition and not the Kali Linux partition, because apparently Manjaro uses some special grub configuration/microcode/special something required for it to boot.


There are various things that are able to cause this kind of kernel panic. Since you are using grub2, I strongly suggest you run the grub shell commands manually(You can always refer to commands in your /boot/grub/grub.cfg file) Typically, you have commands like this:

    set prefix=...
    set root=...
    # you can test if values above are set correctly by simply run `ls` here
    # and see whether errors show up
    linux /...
    initrd /...

run commands above one by one and if any goes wrong, the returned error message will give you a clue on what is wrong in your system. Then google the error message to find the solution.


I had the same problem after kernel update. Please mount relevant ISO or CD/DVD disk and do the rescue. For example, I mounted the CentOS7 DVD and do this:

mount --bind /proc /mnt/sysimage/proc
mount --bind /dev  /mnt/sysimage/dev
mount --bind /sys  /mnt/sysimage/sys
chroot /mnt/sysimage

Тhen finding the last initramfs from /boot and regenerate it, well in this case:

dracut -f /boot/initramfs-2.6.32-754.14.2.el6.x86_64.img initramfs-2.6.32-754.14.2.el6.x86_64

After reboot, everything works wine.


Apparently this can happen if you do not allocate enough memory for you VM as well. I figured out I had my memory set to 320 mb and not 32gb.

  • The user in the question does not seem to be running in a VM though.
    – Kusalananda
    Dec 18, 2019 at 18:42
  • I find this unlikely: the kernel only needs a few megabytes of RAM to get to the point of mounting the root device.
    – Mark
    Oct 5, 2020 at 20:48

it solved after changed the base memory from 128mb to 2GB


Just encountered this issue today when i accepted a kernel upgrade.
Solved it by freeing boot partition disk space (for those who have a /boot partition)

It may work otherwise for others depending on how they had their disk partitions set up.
Just free space if it is full where kernel files exist or delete older kernels and update grub


  1. Check if your /boot is used over 90% using the df -h terminal command
  2. Reboot your PC and at the Grub menu, Select the Advanced options ...
  3. Select the second kernel from the top of the list and boot with it. Log in and open the terminal as root
  4. Enter this command to list all kernels: dpkg --list | grep linux-image. In the second column of the output are the names of the kernel images. example linux-image-4.19.0-10-amd64 or linux-image-4.19.0-10-generic. Take note of the the old images you want to delete (except the first top 2 and the last entry in the list, as per my experience).
  5. Use this command to purge the images: apt-get purge linux-image-4.19.0-5-amd64. Replace linux-image-4.19.0-5-amd64 with the image you want to purge from the list. Repeat this step for each image earmarked for purging.
  6. Update Grub with terminal command: update-grub2
  7. Reboot PC with terminal command: reboot.
  8. At Grub, allow the newest linux kernel to boot.

    Save the day

Few cases the kernel may fails to handle the initrdless boot. Disable the GRUB_FORCE_PARTUUID options, thus it boots with initrd


have seen this error in the past network booting with ipxe.

then i forgot about it until i tried another kernel that had this error this post also describes it.

ipxe lets you configure a console splash screen, and --keep the custom splash screen throughout the kernel boot. however for some kernels, the splash screen causes issues including this VFS error.

if you get this error using ipxe with 'console' command and --keep argument, best idea is to remove keep and try again.

there are some more nuances/workarounds to this i vaguely recall from past, if i remember i will come back and update.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .