I had a windows10 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.


And this is the Error:

not syncing vfs unable to mount root fs on unknown-block(0 0)

How can I fix the problem?


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.

| improve this answer | |
  • 1
    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 – Milad Heydari Jan 3 '18 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 '18 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 '18 at 2:14
  • 1
    ps: see unix.stackexchange.com/questions/399626/… – cas Jan 4 '18 at 2:16
  • 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 at 3:17

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |
  • The user in the question does not seem to be running in a VM though. – Kusalananda Dec 18 '19 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.