17.6.5. not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Let’s learn how to diagnose problems with the root filesystem not being found. TODO add a sample panic error message for each error type:
This is the diagnosis procedure.
First, if we remove the following options from the our kernel build:
CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_PCI=y
we get a message 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)
From the message, we notice that the kernel sees a disk of some sort (vda means a virtio disk), but it could not open it.
This means that the kernel cannot properly read any bytes from the disk.
And afterwards, it has an useless message here are the available partitions:, but of course we have no available partitions, the list is empty, because the kernel cannot even read bytes from the disk, so it definitely cannot understand its filesystems.
This can indicate basically two things:
-
on real hardware, it could mean that the hardware is broken. Kind of hard on emulators ;-)
-
you didn’t configure the kernel with the option that enables it to read from that kind of disk.
In our case, disks are virtio devices that QEMU exposes to the guest kernel. This is why removing the options:
CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_PCI=y
led to this error.
Now, let’s restore the previously removed virtio options, and instead remove:
CONFIG_EXT4_FS=y
This time, the kernel will be able to read bytes from the device. But it won’t be able to read files from the filesystem, because our filesystem is in ext4 format.
Therefore, this time the error message looks like this:
<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)
In this case, we see that the kernel did manage to read from the vda disk! It even told us how: by using the driver: virtio_blk.
However, it then went through the list of all filesystem types it knows how to read files from, in our case just squashf, and none of those worked, because our partition is an ext4 partition.
Finally, the last possible error is that we simply passed the wrong root= kernel CLI option. For example, if we hack our command to pass:
root=/dev/vda2
which does not even exist since /dev/vda is a raw non-partitioned ext4 image, then boot fails with a message:
<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)
This one is easy, because the kernel tells us clearly which partitions it would have been able to understand. In our case /dev/vda.
Once all those problems are solved, in the working setup, we finally see something like:
<6>[ 0.636129] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null) <6>[ 0.636700] VFS: Mounted root (ext4 filesystem) on device 254:0.
Tested on LKMC 863a373a30cd3c7982e3e453c4153f85133b17a9, Linux kernel 5.4.3.
Bibliography: