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.
