Thursday, April 14, 2022

[SOLVED] How to find the root device name of a debootstrap image

Issue

I'm creating a ubuntu 20.04 QEMU image with debootstrap (debootstrap --arch amd64 focal .). However, when I tried to boot it with a compiled Linux kernel, it failed to boot:

[    0.678611] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    0.681639] Call Trace:
...
[    0.685135]  ret_from_fork+0x35/0x40
[    0.685712] Kernel Offset: disabled
[    0.686182] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

I'm using the following command:

sudo qemu-system-x86_64 \
    -enable-kvm -cpu host -smp 2 -m 4096 -no-reboot -nographic \
    -drive id=root,media=disk,file=ubuntu2004.img \
    -net nic,macaddr=00:da:bc:de:00:13 -net tap,ifname=tap0,script=no \
    -kernel kernel/arch/x86/boot/bzImage \
    -append "root=/dev/sda1 console=ttyS0"

So I'm guessing the error comes from the wrong root device name (/dev/sda1 in my case). Is there any way to find the correct root device name?

Update from @Peter Maydell's comment:

[    0.302200] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
[    0.302413] Please append a correct "root=" boot option; here are the available partitions:
[    0.302824] fe00         4194304 vda 
[    0.302856]  driver: virtio_blk
[    0.303152] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Where vda should be the root device name.


Solution

This kind of "unable to mount root fs on unknown-block" error has several possible causes:

  • You asked the kernel to use the wrong device as the rootfs (or you didn't specify, and the built-in default is the wrong one)
  • You asked the kernel to use the right device as the rootfs, but the kernel doesn't have a device driver for it compiled in. (This might include more complicated cases like "the device is a PCI device and the kernel doesn't have the PCI controller driver compiled in.")
  • You asked the kernel to use the right device as the rootfs, and the kernel does have a driver for it, but it couldn't find the hardware, perhaps because the QEMU command line is incorrect

An important clue in figuring out which is the problem is to look at the part of the kernel log just before the "Kernel panic" part of the log. The kernel should print a list of "available partitions", which are the devices that it has a driver for and which are present. If that list contains a plausible looking device name, as in your case (where "vda" is listed as provided by the "virtio_blk" driver) then you now know what the root device name should be, and all you need to do is fix the kernel command line, eg "root=vda". Note that this list is a list of available partitions, so if your disk image has multiple partitions they should show up in the list as "vda1", "vda2", etc. (In this case it looks like your image is a single filesystem, not a disk image with multiple partitions, so only "vda" is in the list.)

If the kernel's list of available partitions doesn't include anything that looks like the disk you were expecting, then either the kernel is missing the driver, or the QEMU command line doesn't have the option to provide the device. This is a little harder to debug, but there may be useful information earlier in the kernel bootup log where the kernel probes for hardware -- for instance there should be logging when the PCI controller is probed. You can also of course double-check the config file for your kernel to see if the right CONFIG options are set.

If you're using a standard distro kernel then these usually have all the usual devices built-in, and your first check should be your QEMU command line. If you built your own kernel from source, check your config, especially if you were trying to achieve a "minimal" kernel with only the desired drivers present.



Answered By - Peter Maydell
Answer Checked By - Clifford M. (WPSolving Volunteer)
at