not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
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] [] dump_stack+0x63/0x81 [ 0.668267] [] panic+0xe4/0x22d [ 0.668321] [] mount_block_root+0x27c/0x2c7 [ 0.668377] [] ? set_debug_rodata+0x12/0x12 [ 0.668432] [] mount_root+0x65/0x68 [ 0.668486] [] prepare_namespace+0x12f/0x167 [ 0.668542] [] kernel_init_freeable+0x1ec/0x205 [ 0.668598] [] ? rest_init+0x90/0x90 [ 0.668652] [] kernel_init+0xe/0x100 [ 0.668706] [] 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) _ 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 :/
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:
- 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.
- 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.
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
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 .
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.
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.
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:
- 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 [ 0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6 [ 0.542035] Please append a correct "root=" boot option; here are the available partitions: [ 0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 0.585296] List of all partitions: [ 0.585913] fe00 524288 vda [ 0.586123] driver: virtio_blk [ 0.586471] No filesystem could mount root, tried: [ 0.586497] squashfs [ 0.586724] [ 0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0) [ 0.608475] Please append a correct "root=" boot option; here are the available partitions: [ 0.609563] fe00 524288 vda [ 0.609723] driver: virtio_blk [ 0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2) - (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 .
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!
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.
VFS: unable to mount root fs on unknown-block(0 0)_ _ _
- long press on power button to shutdown your laptop.
- select the “advanced” option.
- select lowest version of generic (“recovery mode”)
- click on “clean” “try to make free space”
- and then “resume” “resume normal boot”
@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.
- 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!)
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
- 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.
- 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-
- In Gparted, right click the root partition, click info
- In Terminal use blkid | grep -i
- Check for it in /etc/fstab
- Other means
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-5dffbe6833c6For this exercise I will use
nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn- Either use touch to create the file custom.cfg and then your favourite text editor, or I just use nano as follows
- 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 >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.