QEMU booting of non-NetBSD CDs and virtual HDs

[Robert Nestor <rnestor%mac.com@localhost>]

Further adventures with QEMU booting of non-NetBSD CDs and virtual HDs.

I've had some success, but have also uncovered a couple of bugs, one minor and two rather significant. To keep things simple here, I've only addressed the problems I've seen in trying to boot the rEFInd CD and MSDOS image files. The rEFInd CD image is available from:
  http://sourceforge.net/projects/refind/files/0.12.0/refind-cd-0.12.0.zip
this will unzip to an ISO image and inside that image is the MSDOS bootable file refind-bin-0.12.0.img

The minor bug is in "makefs".  When creating an MSDOS disk it doesn't mark the "a" partition in the BSD label as MSDOS.  This makes it impossible to mount the resulting image file.  Also it doesn't label the MBR partition as type (FAT12, FAT16, FAT32, EFI, etc) or mark it as active when creating a boot disk.  This may cause problems trying to boot the resulting disk image in QEMU. (Or at least fdisk doesn't think these parameters are set and QEMU/OVMF have problems finding the disk after successfully booting from it.)

The OVMF code in the pkgsrc tree is very dated and has problems booting some CDs, mainly the rEFInd one and possibly others.  The version in the pkgsrc tree is stable20181116; a newer version is available that does support booting from many non-BSD CDs. That version is stable202006. So this package should probably be updated.

NVMM has a problem booting the rEFInd CD image. It fails with a "failure to start VCPU" message.  Without -accel=nvmm in the qemu startup the boot succeeds (up to the same point as in Linux). This doesn't happen when trying to boot up a NetBSD CD image though, so there’s probably something missing or wrong in NVMM.

From what I can tell, both the NetBSD CD image and the rEFInd CD images are created in a similar fashion. There's an MSDOS bootable image file that is created to supprort UEFI booting and that file is used as the CD boot file.  Both MSDOS image files have the same problems described above as the "makefs" issue, but this doesn't affect NetBSD CD booting as it does booting the rEFInd CD image.  I suspect it's because the NetBSD boot code doesn't have to deal with the MSDOS  filesystem once it's loaded but the rEFInd code does.  Since both CDs boot successfully on real HW but rEFInd doesn't completely boot up under QEMU, this may be due to the OVMF code being a lot more strict about filesystems than the actual firmware on most PCs. I've been unsuccessful testing this assumption though as I can't seem to be able to "correct" the MSDOS image file.

So with a copy of the OVMF binary from the stable202006 release that I extracted from an Arch Linux package, the rEFInd CD image and the MSDOS image boot file both boot up under qemu to the point where they display the splash screen and then hang.  There's some indication at this point that the boot code can't find the MSDOS disk though, so this may be caused by the disk image not being completely built correctly, i.e.  the BSD partition isn't "MSDOS" and the MBR doesn't correctly identify the
first partition as active, bootable and of a known type (4, even though makefs seems to be specifying this in the build of the image).

I've tested this on both NetBSD and MintLinux.  On Linux I've done this both with and without KVM, and except for the error I see with NVMM on NetBSD, both systems work the same, i.e. I get to the rEFInd splash screen and no further.  Under NetBSD I've been able to use vndconfig to mount the disk (or CD) image file and correct the partition type on the MSDOS image using disklabel. I haven't been able to adjust the other parameters with fdisk though, so I'm not sure if they're causing the filesystem access problems OVMF is seeing or not. So this could being caused by an undocumented bug in OVMF or the problems I've encountered with makefs.

The script I use for booting under qemu:
#!/bin/sh
# this is the rEFInd CD image file downloaded from sourceforge
disk0=refind-cd-0.12.0.iso
# this is the MSDOS image file contained within the rEFInd CD image
disk1=Refind/refind-bin-0.12.0.img
# this is an MSDOS image file created from the rEFInd distribution on the CD
disk2=refind.img
#
if [ "`uname`" = "Linux" ]; then
    accel="-enable-kvm -accel kvm -vga qxl"
else
#    accel="-accel nvmm -vga cirrus"
    accel="-vga cirrus"
fi
# this is the OVMF binary extracted from the Arch Linux package of
#  the edk2-ovmf stable202005 build (released 2020/06/03)
# note: using the readonly OVMF_CODE and r/w OVMF_VARs files in place
#  of the combined OVMF file makes no difference
ovmf=edk2/usr/share/edk2-ovmf/x64/OVMF.fd
# note: specifying the image file as a disk or CD doesn't seem to matter
qemu-system-x86_64 -m 4096 ${accel} -boot order=dc,menu=on \
    -device qemu-xhci -device usb-tablet -machine q35 -smbios type=2 \
    -drive if=pflash,format=raw,file=${ovmf} \
    -device ide-hd,bus=ide.0,drive=disk0 \
    -drive id=disk0,if=none,media=disk,format=raw,index=0,file=${disk0}

This is the script I use to build a new MSDOS image using the one found on the rEFInd CD. I did this mainly to verify how I thought the MSDOS image was being constructed.
#!/bin/sh
if [ "`uname`" != "NetBSD" ]; then
    echo "This must be done in NetBSD"
    exit 1
fi
rm -fr efiboot.img efiboot
mkdir -p -m 0755 efiboot/EFI
vndconfig -c vnd0 Refind/refind-bin-0.12.0.img
mount_msdos -l /dev/vnd0a /mnt
cp -r /mnt/* efiboot/
umount /mnt
vndconfig -u vnd0
makefs -M 1m -m 6m -B 1234   -t msdos -o F=16,c=1 refind.img efiboot

I haven't filed any PRs on these issues but will if someone can verify my findings/observations first, and think they're valid bugs.