initrdlinux-kernelqemu
I had compiled a linux kernel and I wanted to debug it in QEMU. I created a file to boot from by doing the commands
$ qemu-img create -f raw disk.img 200M
$ mkfs.ext2 -F disk.img
# mkdir /mnt/rootfs
# mount -o loop disk.img /mnt/rootfs
Then I did qemu -kernel bzImage -initrd disk.img and got the screen below which says:
Kernel panic - not syncing: VFS: unable to mount root fs on unknown block
What have I done wrong and what can I do to fix it?
cmp command after dd.You are having boot problems that look very much like bad data on the USB. Therefore, please use a USB writing method that re-checks the written data.
dd on its own, does not re-check the written data. Please re-check the data manually using cmp, by following the exact instructions in the next section. Unfortunately I couldn't think of any easier method.
GNOME Disks can be used to write a USB (the Fedora install instructions tell you how). But it doesn't seem to re-check the written data.
The official Fedora install instructions "default" to Fedora Media Writer. At least the version of Fedora Media Writer I have, does automatically re-check the written data after writing it to the USB. I don't know an easy way to install Fedora Media Writer on your Ubuntu OS :-(.
https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html
Ubuntu's "Startup Disk Creator" did not work at all for me. I think it is only willing to write Ubuntu ISOs, not Fedora ones.
cmp command after ddIn principle this could be a simple cmp command. Very sadly, there are some difficulties that will return useless results, so I need to explain these.
I believe cmp might also show differences if you ever allowed the written USB to be mounted on a Linux system :-(. This is likely to happen if you ever plugged it in again to a Linux system after writing it! (Or successfully boot the Fedora Live USB??) You have to be careful with it!
So you want to run dd to write the data, and then cmp command to verify the USB data, without re-plugging the USB (or rebooting) in between.
First run your dd command. Remember to take great care and don't wipe your internal hard drive :).
Then remember you should run sync, to make sure the data is finished writing.
Then, you will be able to run echo 3 | sudo tee /proc/sys/vm/drop_caches. This step is required, to make sure that cmp won't just be reading back from caches in system RAM.
Then you can run
# cmp Fedora-Workstation-Live-28.iso /dev/sdb
I.e. where sdb is the name of your USB device, and the .iso file is the name of your ISO file. This command could show IO errors, or differences, if the problem is that your USB stick needs replacing.
In principle you might want to go further, and test the USB keeps its data correctly after it is removed and loses power. So this would require an alternative method which disables the auto-mount of your graphical login. It can be very hard to know how to disable auto-mount temporarily :-(. I think the simplest way is to log in on a text console and run your commands from there. Make sure you do not switch back to a graphical login before you have finished! For some information about logging in on a text console, see here.
From the evidence so far, it looks like the initramfs read from your USB is damaged. You could try to verify the USB data, on the same system that you wrote the USB. This could be useful to confirm some sort of problem writing to your USB.
For completeness, the full list of possibilities is :-
I found other unsolved mysteries described with the same error message and very similar conditions:
[1.81660] ---[end Kernel] panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0).
Unfortunately, this isn't the real, specific error.
I have double-checked; Fedora-Workstation-Live 28 uses an initramfs. This is sometimes also called a type of initrd.
This error would be shown if you set up a boot with both a kernel and an initramfs, but some error prevents the initramfs being loaded.
For example, one way to trigger this error, would be if you pressed a special key at the boot menu to start a temporary edit of the boot options. In theory you might have started editing the boot options, and unintentionally removed an initrd option. So I have to mention this as a possibility :). Note this type of edit is temporary. So you can just boot again, and make sure you're not making an edit that disables the initramfs :).
In this case the kernel may "fall through" to an old-style boot without an initramfs, but then it doesn't have any "block device" that it was specified to mount as the root fs. "(0,0)" means "unknown"; this device number is never a valid block device.
But I don't think that's what you (and some others) did.
Therefore, I think there is probably a more specific error earlier in the boot process. Unfortunately, if there was an error message, it is possible you can't see it because it scrolled off the top of the screen, if there were too many messages since then :).
An image search for "unable to mount root fs on unknown-block(0,0)." shows that is very common for the kernel call trace to fill the screen. When this happens you cannot see if there is any previous error message.
I found an example of such an error, posted regarding a different Linux:
https://bbs.archlinux.org/viewtopic.php?id=220178
Initramfs unpacking failed: junk in compressed archive
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
...
--- [end Kernel] panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0).
EDIT: called it :-). "Initramfs unpacking failed:" was the real error. "XZ-compressed data is corrupt" makes it clear the initramfs is not being read correctly from the USB
When copying the boot sector, you also copied the partition table in it. Depending on the versions of fdisk and the exact options used when partitioning both the original sda and the image file, the partition limits may or may not have been exactly in the same places. If they weren't... your loop mounts used the partition offsets your fdisk created, but at boot, the VM would have been using the partition offsets copied from the original sda.
You copied the MBR with dd, but the contents of /boot with rsync. The MBR includes block-level offsets to identify the locations of further bootloader components (<filesystem>_stage1.5 or stage2 for GRUB Legacy). It is highly unlikely that these files would have been exactly at the same block locations after a rsync-based copy.
You probably missed completely some parts of the bootloader. GRUB Legacy can embed parts of itself to the beginning of a partition, into an area that is outside the filesystem; GRUB2 almost always writes the majority of its core image to the disk blocks just after the MBR, but before the beginning of the first partition. Copying just the 512 first bytes of the disk gets only the traditional MBR, but misses these things. I think this is the most likely reason your boot failed.
Depending on which virtualization method you're planning, you probably should have used mount --bind /dev /mnt/img/dev and likewise for /proc and /sys, then chrooted into the image environment and used its grub-install to properly rewrite the boot loader into the image file with correct block offsets.
Another possible approach would have been to boot the original system in single user mode or otherwise stop as many daemons on the original system as possible (i.e. quiesce the system), and then just dd the whole system disk into an image as a single operation. This way, you'll certainly have to run fsck when booting the resulting image for the first time, but you'd avoid all the complexities with the MBR and bootloaders.
Best Answer
The kernel is telling you, that it doesn't know which device holds the root file system. Your loop mount isn't necessary. (Unmount it before continuing).
Try a command like
qemu -kernel bzImage -hda disk.img -append root=/dev/sdaThe
-hda disk.imgparameter tells qemu to simulate a disk device based on yourdisk.img.The
-append root=/dev/sdaswitch is used by qemu to tell the kernel about it's root device. This is done by appending theroot=/dev/sdato the kernel commandline. You can compare this to the kernel commandline of your own kernel by doingcat /proc/cmdline(This is safe). You should see there arootparameter, too.