Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 24, 2020, at 1:32 PM, Chavdar Ivanov wrote: > On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: >> >> >> On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: >> >>> On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: I received a couple of messages off list that suggested a few things and it prompted me to try investigating further with just components found in NetBSD. This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the following: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>> >>> -accel nvmm >>> -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>> >>> the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but >>> perhaps this is a typo. Anyway. I have no idea about this particular >>> way of specifying the bios; anyway, with >>> >>> >>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>> >>> it boots just fine. Otherwise I get the same crash as you. >>> >>> -device ich9-ahci,id=sata \ -device ide-cd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso This produces an immediate “failed to start VCPU” and results in a core dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: >>> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-hd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img And it provides the same results - “failed to start VCPU” and a core dump. Removing the “-accel=nvmm” from both of the scripts allows the boot to proceed, but the OVMF code fails to find the CD or HD image and boot falls back to attempting to boot over the network. This appears to be a bug in the version of OVMF found in pkgsrc which is based on stable2018. Replacing the OVMF with binaries obtained from a build of stable202005 fixes the disk access issue and the boot then succeeds brining up the NetBSD installer. I then proceeded to do two installations of NetBSD under qem; one using the defaults for an MBR setup and one for a GPT setup. The resulting MBR disk doesn’t boot under qemu; the GPT disk does boot however. In the case of the MBR disk it appears the problem is that OVMF can’t find the disk or anything bootable on it. I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and PR-55582 for the OVMF issue. >> >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the >> NVMM crash and it does boot up the NetBSD CD ISO file. From there I was >> able to do two installations of NetBSD, one specifying an MBR partition >> setup and one with GPT taking the defaults for both. However, neither of >> the created disk image files will boot with the OVMFX64.fd file. Using a >> newer version from a stable202005 OVMF build and one from a build done in >> the last week or so does boot up the GPT created disk image but not the >> newly created MBR disk image. > > I haven't tried an MBR installation, but my GPT one boots just fine > with OVMFX86 - > > qemu-system-x86_64 \ >-m 3072 \ >-machine q35 \ >-accel nvmm \ >-device qemu-xhci \ >-device usb-tablet \ >-device usb-mouse \ >-k en-gb \ >-smp 2 \ >-net tap,fd=3 3<>/dev/tap1 \ >-boot menu=on \ >-vnc :1 \ >-net nic \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > This is the system I installed yesterday on a fresh zvol, it boots > fine. As I have said previously, the same system can't boot if I use X > server / gtk output - it boots only if I use vnc. So there is a > problem, but I can't figure out who to blame in this case Did a bit more digging on this and came up with a couple of things. It appears the MBR boot failure may be caused by not having the CSM code enabled in the version of OVMF being used. I had some limited success using a version of OVMF that was built with CSM support which builds in a copy of SeaBIOS. This type of build for OVMF doesn’t appear to be recommended though as it requires a lot of mode switching between 16 bit and 32/64 bit mode that
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 24, 2020, at 1:32 PM, Chavdar Ivanov wrote: > On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: >> >> >> On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: >> >>> On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: I received a couple of messages off list that suggested a few things and it prompted me to try investigating further with just components found in NetBSD. This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the following: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>> >>> -accel nvmm >>> -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>> >>> the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but >>> perhaps this is a typo. Anyway. I have no idea about this particular >>> way of specifying the bios; anyway, with >>> >>> >>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>> >>> it boots just fine. Otherwise I get the same crash as you. >>> >>> -device ich9-ahci,id=sata \ -device ide-cd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso This produces an immediate “failed to start VCPU” and results in a core dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: >>> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-hd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img And it provides the same results - “failed to start VCPU” and a core dump. Removing the “-accel=nvmm” from both of the scripts allows the boot to proceed, but the OVMF code fails to find the CD or HD image and boot falls back to attempting to boot over the network. This appears to be a bug in the version of OVMF found in pkgsrc which is based on stable2018. Replacing the OVMF with binaries obtained from a build of stable202005 fixes the disk access issue and the boot then succeeds brining up the NetBSD installer. I then proceeded to do two installations of NetBSD under qem; one using the defaults for an MBR setup and one for a GPT setup. The resulting MBR disk doesn’t boot under qemu; the GPT disk does boot however. In the case of the MBR disk it appears the problem is that OVMF can’t find the disk or anything bootable on it. I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and PR-55582 for the OVMF issue. >> >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the >> NVMM crash and it does boot up the NetBSD CD ISO file. From there I was >> able to do two installations of NetBSD, one specifying an MBR partition >> setup and one with GPT taking the defaults for both. However, neither of >> the created disk image files will boot with the OVMFX64.fd file. Using a >> newer version from a stable202005 OVMF build and one from a build done in >> the last week or so does boot up the GPT created disk image but not the >> newly created MBR disk image. > > I haven't tried an MBR installation, but my GPT one boots just fine > with OVMFX86 - > > qemu-system-x86_64 \ >-m 3072 \ >-machine q35 \ >-accel nvmm \ >-device qemu-xhci \ >-device usb-tablet \ >-device usb-mouse \ >-k en-gb \ >-smp 2 \ >-net tap,fd=3 3<>/dev/tap1 \ >-boot menu=on \ >-vnc :1 \ >-net nic \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > This is the system I installed yesterday on a fresh zvol, it boots > fine. As I have said previously, the same system can't boot if I use X > server / gtk output - it boots only if I use vnc. So there is a > problem, but I can't figure out who to blame in this case Did a bit more digging on this and came up with a couple of things. It appears the MBR boot failure may be caused by not having the CSM code enabled in the version of OVMF being used. I had some limited success using a version of OVMF that was built with CSM support which builds in a copy of SeaBIOS. This type of build for OVMF doesn’t appear to be recommended though as it requires a lot of mode switching between 16 bit and 32/64 bit mode that
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: > > > On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: > > > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: > >> > >> I received a couple of messages off list that suggested a few things and > >> it prompted me to try investigating further with just components found in > >> NetBSD. > >> > >> This test was run on a fairly recent NetBSD build of 9.99.70. I > >> downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried > >> booting them with qemu using -nvmm and the OVMF binaries currently in > >> pkgsrc with the following: > >> > >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > > > -accel nvmm > > > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > > perhaps this is a typo. Anyway. I have no idea about this particular > > way of specifying the bios; anyway, with > > > > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > > > it boots just fine. Otherwise I get the same crash as you. > > > > > >>-device ich9-ahci,id=sata \ > >>-device ide-cd,bus=sata.0,drive=disk \ > >>-drive > >> id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso > >> > >> This produces an immediate “failed to start VCPU” and results in a core > >> dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > > > >> > >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > >>-device ich9-ahci,id=sata \ > >>-device ide-hd,bus=sata.0,drive=disk \ > >>-drive > >> id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img > >> > >> And it provides the same results - “failed to start VCPU” and a core dump. > >> > >> Removing the “-accel=nvmm” from both of the scripts allows the boot to > >> proceed, but the OVMF code fails to find the CD or HD image and boot falls > >> back to attempting to boot over the network. This appears to be a bug in > >> the version of OVMF found in pkgsrc which is based on stable2018. > >> Replacing the OVMF with binaries obtained from a build of stable202005 > >> fixes the disk access issue and the boot then succeeds brining up the > >> NetBSD installer. > >> > >> I then proceeded to do two installations of NetBSD under qem; one using > >> the defaults for an MBR setup and one for a GPT setup. The resulting MBR > >> disk doesn’t boot under qemu; the GPT disk does boot however. In the case > >> of the MBR disk it appears the problem is that OVMF can’t find the disk or > >> anything bootable on it. > >> > >> I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and > >> PR-55582 for the OVMF issue. > >> > > Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the > NVMM crash and it does boot up the NetBSD CD ISO file. From there I was able > to do two installations of NetBSD, one specifying an MBR partition setup and > one with GPT taking the defaults for both. However, neither of the created > disk image files will boot with the OVMFX64.fd file. Using a newer version > from a stable202005 OVMF build and one from a build done in the last week or > so does boot up the GPT created disk image but not the newly created MBR disk > image. I haven't tried an MBR installation, but my GPT one boots just fine with OVMFX86 - qemu-system-x86_64 \ -m 3072 \ -machine q35 \ -accel nvmm \ -device qemu-xhci \ -device usb-tablet \ -device usb-mouse \ -k en-gb \ -smp 2 \ -net tap,fd=3 3<>/dev/tap1 \ -boot menu=on \ -vnc :1 \ -net nic \ -bios /usr/pkg/share/ovmf/OVMFX64.fd \ -drive format=raw,file=/dev/zvol/rdsk/tank/ztest This is the system I installed yesterday on a fresh zvol, it boots fine. As I have said previously, the same system can't boot if I use X server / gtk output - it boots only if I use vnc. So there is a problem, but I can't figure out who to blame in this case > > So it appears there is a bug in NVMM that causes an abort and dump when any > OVMF file is configured as a pflash device rather than a BIOS. From what I > can see the primary difference in the setup of the use of OVMF is how it > stores any EFI variables it might need or use. Using it as a BIOS option is > the most restrictive for storing and saving UEFI variables. (This may no > longer be true and current versions of OVMF may actually store EFI variables > in a NuVars file in the boot path though.) Using the OVMF file that contains > the read-only
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: >> >> I received a couple of messages off list that suggested a few things and it >> prompted me to try investigating further with just components found in >> NetBSD. >> >> This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded >> the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them >> with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the >> following: >> >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > -accel nvmm > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > perhaps this is a typo. Anyway. I have no idea about this particular > way of specifying the bios; anyway, with > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > it boots just fine. Otherwise I get the same crash as you. > > >>-device ich9-ahci,id=sata \ >>-device ide-cd,bus=sata.0,drive=disk \ >>-drive >> id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso >> >> This produces an immediate “failed to start VCPU” and results in a core >> dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > >> >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>-device ich9-ahci,id=sata \ >>-device ide-hd,bus=sata.0,drive=disk \ >>-drive >> id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img >> >> And it provides the same results - “failed to start VCPU” and a core dump. >> >> Removing the “-accel=nvmm” from both of the scripts allows the boot to >> proceed, but the OVMF code fails to find the CD or HD image and boot falls >> back to attempting to boot over the network. This appears to be a bug in >> the version of OVMF found in pkgsrc which is based on stable2018. Replacing >> the OVMF with binaries obtained from a build of stable202005 fixes the disk >> access issue and the boot then succeeds brining up the NetBSD installer. >> >> I then proceeded to do two installations of NetBSD under qem; one using the >> defaults for an MBR setup and one for a GPT setup. The resulting MBR disk >> doesn’t boot under qemu; the GPT disk does boot however. In the case of the >> MBR disk it appears the problem is that OVMF can’t find the disk or anything >> bootable on it. >> >> I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and >> PR-55582 for the OVMF issue. >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the NVMM crash and it does boot up the NetBSD CD ISO file. From there I was able to do two installations of NetBSD, one specifying an MBR partition setup and one with GPT taking the defaults for both. However, neither of the created disk image files will boot with the OVMFX64.fd file. Using a newer version from a stable202005 OVMF build and one from a build done in the last week or so does boot up the GPT created disk image but not the newly created MBR disk image. So it appears there is a bug in NVMM that causes an abort and dump when any OVMF file is configured as a pflash device rather than a BIOS. From what I can see the primary difference in the setup of the use of OVMF is how it stores any EFI variables it might need or use. Using it as a BIOS option is the most restrictive for storing and saving UEFI variables. (This may no longer be true and current versions of OVMF may actually store EFI variables in a NuVars file in the boot path though.) Using the OVMF file that contains the read-only code and the read-write variable space is less restrictive, and using a separate OVMF code and variable files provides the most flexibility but only the BIOS usage seems compatible withe NVMM at this point. And it seems there’s a bug in all versions of OVMF at this time that prevents some disk images from booting even though they will boot on real HW. Or there’s something strange about the way the NetBSD installer creates these disks that is incompatible with OVMF at present - or both. -bob
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Sun, 23 Aug 2020 at 21:01, Chavdar Ivanov wrote: > > On Sun, 23 Aug 2020 at 19:57, Chavdar Ivanov wrote: > > > > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: > > > > > > I received a couple of messages off list that suggested a few things and > > > it prompted me to try investigating further with just components found in > > > NetBSD. > > > > > > This test was run on a fairly recent NetBSD build of 9.99.70. I > > > downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and > > > tried booting them with qemu using -nvmm and the OVMF binaries currently > > > in pkgsrc with the following: > > > > > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > > > -accel nvmm > > > > > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 > > > \ > > > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > > perhaps this is a typo. Anyway. I have no idea about this particular > > way of specifying the bios; anyway, with > > > > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > > > it boots just fine. Otherwise I get the same crash as you. > > I meant - it doesn't crash, but it still can't boot from the ISO, as you said. > > I perform the installation using normal BIOS, then I switch. Doesn't > make sense, I know. > > > > > > > > -device ich9-ahci,id=sata \ > > > -device ide-cd,bus=sata.0,drive=disk \ > > > -drive > > > id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso > > > > > > This produces an immediate “failed to start VCPU” and results in a core > > > dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > > > > > > > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 > > > \ > > > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > > -device ich9-ahci,id=sata \ > > > -device ide-hd,bus=sata.0,drive=disk \ > > > -drive > > > id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img > > > > > > And it provides the same results - “failed to start VCPU” and a core dump. > > > > > > Removing the “-accel=nvmm” from both of the scripts allows the boot to > > > proceed, but the OVMF code fails to find the CD or HD image and boot > > > falls back to attempting to boot over the network. This appears to be a > > > bug in the version of OVMF found in pkgsrc which is based on stable2018. > > > Replacing the OVMF with binaries obtained from a build of stable202005 > > > fixes the disk access issue and the boot then succeeds brining up the > > > NetBSD installer. > > > > > > I then proceeded to do two installations of NetBSD under qem; one using > > > the defaults for an MBR setup and one for a GPT setup. The resulting MBR > > > disk doesn’t boot under qemu; the GPT disk does boot however. In the > > > case of the MBR disk it appears the problem is that OVMF can’t find the > > > disk or anything bootable on it. > > > > > > I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and > > > PR-55582 for the OVMF issue. > > > > > I was able to boot EFI and install yesterday's -current using qemu-system-x86_64 \ -m 3072 \ -machine q35 \ -accel nvmm \ -device qemu-xhci \ -device usb-tablet \ -k en-gb \ -smp 2 \ -cdrom /iso/NetBSD-9.99.71-amd64.iso \ -vnc :1 \ -net tap,fd=3 3<>/dev/tap1 \ -net nic \ -bios /usr/pkg/share/ovmf/OVMFX64.fd \ -drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > Chavdar > > > > -- > > > > > > -- > --
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Sun, 23 Aug 2020 at 19:57, Chavdar Ivanov wrote: > > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: > > > > I received a couple of messages off list that suggested a few things and it > > prompted me to try investigating further with just components found in > > NetBSD. > > > > This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded > > the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting > > them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with > > the following: > > > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > -accel nvmm > > > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > perhaps this is a typo. Anyway. I have no idea about this particular > way of specifying the bios; anyway, with > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > it boots just fine. Otherwise I get the same crash as you. I meant - it doesn't crash, but it still can't boot from the ISO, as you said. I perform the installation using normal BIOS, then I switch. Doesn't make sense, I know. > > > > -device ich9-ahci,id=sata \ > > -device ide-cd,bus=sata.0,drive=disk \ > > -drive > > id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso > > > > This produces an immediate “failed to start VCPU” and results in a core > > dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > > > > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > -device ich9-ahci,id=sata \ > > -device ide-hd,bus=sata.0,drive=disk \ > > -drive > > id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img > > > > And it provides the same results - “failed to start VCPU” and a core dump. > > > > Removing the “-accel=nvmm” from both of the scripts allows the boot to > > proceed, but the OVMF code fails to find the CD or HD image and boot falls > > back to attempting to boot over the network. This appears to be a bug in > > the version of OVMF found in pkgsrc which is based on stable2018. > > Replacing the OVMF with binaries obtained from a build of stable202005 > > fixes the disk access issue and the boot then succeeds brining up the > > NetBSD installer. > > > > I then proceeded to do two installations of NetBSD under qem; one using the > > defaults for an MBR setup and one for a GPT setup. The resulting MBR disk > > doesn’t boot under qemu; the GPT disk does boot however. In the case of > > the MBR disk it appears the problem is that OVMF can’t find the disk or > > anything bootable on it. > > > > I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and > > PR-55582 for the OVMF issue. > > > > Chavdar > > -- > --
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: > > I received a couple of messages off list that suggested a few things and it > prompted me to try investigating further with just components found in NetBSD. > > This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded > the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them > with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the > following: > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -accel nvmm > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but perhaps this is a typo. Anyway. I have no idea about this particular way of specifying the bios; anyway, with -bios /usr/pkg/share/ovmf/OVMFX64.fd \ it boots just fine. Otherwise I get the same crash as you. > -device ich9-ahci,id=sata \ > -device ide-cd,bus=sata.0,drive=disk \ > -drive > id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso > > This produces an immediate “failed to start VCPU” and results in a core dump. > Also tried the NetNSD-9.99.71-amd64-install.img file with: > > qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > -device ich9-ahci,id=sata \ > -device ide-hd,bus=sata.0,drive=disk \ > -drive > id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img > > And it provides the same results - “failed to start VCPU” and a core dump. > > Removing the “-accel=nvmm” from both of the scripts allows the boot to > proceed, but the OVMF code fails to find the CD or HD image and boot falls > back to attempting to boot over the network. This appears to be a bug in the > version of OVMF found in pkgsrc which is based on stable2018. Replacing the > OVMF with binaries obtained from a build of stable202005 fixes the disk > access issue and the boot then succeeds brining up the NetBSD installer. > > I then proceeded to do two installations of NetBSD under qem; one using the > defaults for an MBR setup and one for a GPT setup. The resulting MBR disk > doesn’t boot under qemu; the GPT disk does boot however. In the case of the > MBR disk it appears the problem is that OVMF can’t find the disk or anything > bootable on it. > > I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and > PR-55582 for the OVMF issue. > Chavdar --
Re: QEMU booting of non-NetBSD CDs and virtual HDs
I received a couple of messages off list that suggested a few things and it prompted me to try investigating further with just components found in NetBSD. This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the following: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-cd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso This produces an immediate “failed to start VCPU” and results in a core dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-hd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img And it provides the same results - “failed to start VCPU” and a core dump. Removing the “-accel=nvmm” from both of the scripts allows the boot to proceed, but the OVMF code fails to find the CD or HD image and boot falls back to attempting to boot over the network. This appears to be a bug in the version of OVMF found in pkgsrc which is based on stable2018. Replacing the OVMF with binaries obtained from a build of stable202005 fixes the disk access issue and the boot then succeeds brining up the NetBSD installer. I then proceeded to do two installations of NetBSD under qem; one using the defaults for an MBR setup and one for a GPT setup. The resulting MBR disk doesn’t boot under qemu; the GPT disk does boot however. In the case of the MBR disk it appears the problem is that OVMF can’t find the disk or anything bootable on it. I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and PR-55582 for the OVMF issue.
QEMU booting of non-NetBSD CDs and virtual HDs
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,fil
