I tried to use febootstrap to make a roofs image for qemu-kvm.

I frist generated a roofs with command

febootstrap -i coreutils -i vim centos79 centos_7.9 https://mirrors.163.com/centos/7/os/x86_64/

After that, I got a directory as following

> tree centos_7.9/ -L 1
centos_7.9/
├── bin -> usr/bin
├── boot
├── dev
├── etc
├── home
├── lib -> usr/lib
├── lib64 -> usr/lib64
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin -> usr/sbin
├── srv
├── sys
├── tmp
├── usr
└── var

Then, I created a qemu image and copied all file from centos_7.9 to the image.

qemu-img create centos79.img 1g
mkfs.ext4 centos79.img
mkdir mnt_dir
sudo mount -o loop centos79.img mnt_dir
cp centos_7.9/* mnt_dir
umount mnt_dir

However, when I run

qemu-system-x86_64 -kernel /boot/vmlinuz-`uname -r` \
-hda=centos79.img \
-append "root=/dev/sda console=ttyS0" \
-enable-kvm -nographic

or

qemu-system-x86_64 -kernel /boot/vmlinuz-`uname -r` \
-drive file=centos79.img \
-append "root=/dev/hda console=ttyS0" \
-enable-kvm -nographic


It reported that

[ 1.766919] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.767906] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-3.1.0.kwai+ #10
[ 1.767906] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
[ 1.767906] Call Trace:
[ 1.767906] dump_stack_lvl+0x34/0x48
[ 1.767906] panic+0xfb/0x2cd
[ 1.767906] mount_block_root+0x28c/0x29f
[ 1.767906] prepare_namespace+0x13b/0x16a
[ 1.767906] kernel_init_freeable+0x17f/0x1a4
[ 1.767906] ? rest_init+0xc0/0xc0
[ 1.767906] kernel_init+0x16/0x130
[ 1.767906] ret_from_fork+0x22/0x30
[ 1.767906] Kernel Offset: disabled
[ 1.767906] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---


What should I do to fix this?

Perhaps this is not the best place to ask, since the issue rather seems to be with implementing the virtual machine and/or creating the image..

However, that issue seems to be an issue of your VM Kernel not finding the (root) storage correctly (bootloader issue?). Block 0,0 seems a little bit suspicious too, as normally it should not look for the root there, but more likely some other "major,minor" location. There are tools (ex.lsblk) to find the correct (relative or set) major,minor location of your expected (root) partition. If the number does not match that, the mapping is somehow wrong. 0,0 seems like the mapping is wrong (unmapped root).
You have to find the major,minor in the context of the VM, you have to run that inside the VM somehow (enable boot choice in qemu and run a "livecd"). Perhaps it's even easier to test this with a live distro in the first place? Slackware might be a good choice for that, and you could perhaps get it tested by running with the ncurses graphics option for QEMU.

1 members found this post helpful.