Description of problem: When booting a Windows ISO with the 20230301 edk2, the iso does not move beyond the TianoCore splash screen Version-Release number of selected component (if applicable): 20230301gitf80f052277c8-1.fc38 How reproducible: Easily reproducible Steps to Reproduce: 1. Open Terminal 2. qemu-system-x86_64 -m 4G -smp 4 --enable-kvm -cdrom /path/to/Win11_22H2_English_x64v1.iso -bios /usr/share/OVMF/OVMF_CODE.fd 3. Press button to boot CD Actual results: Sits on TianoCore splashscreen Expected results: Boot to installation screen Additional info: Rolling back to edk2-ovmf-20220826gitba0e0e4c6a17-1 allows boot Edit: Corrected OVMF in command run from OVMF_CODE.secboot.fd to OVMF_CODE.fd
> How reproducible: > Easily reproducible > > Steps to Reproduce: > 1. Open Terminal > 2. qemu-system-x86_64 -m 4G -smp 4 --enable-kvm -cdrom > /path/to/Win11_22H2_English_x64v1.iso -bios > /usr/share/OVMF/OVMF_CODE.secboot.fd > 3. Press button to boot CD > > Actual results: > Sits on TianoCore splashscreen Surely not. The secboot ovmf builds do (a) require q35, and (b) require pflash storage for efi variables. When you mis-configure things as described you don't even reach the splash screen. If you expect me to take the time checking out the bug report, then please invest the time to write up the exact reproducer steps.
Apologies, the wrong ovmf was listed in the command. I am using the non-secboot OVMF_CODE.fd [updated above]. q35 it's not required unless using SMM in the configuration. I am not utilizing it so there is no need for this flag and it's additional arguments.
> Actual results: > Sits on TianoCore splashscreen Hmm. For me it is just much slower for some reason, when waiting long enougth the installer actually starts.
(In reply to Gerd Hoffmann from comment #3) > > Actual results: > > Sits on TianoCore splashscreen > > Hmm. For me it is just much slower for some reason, > when waiting long enougth the installer actually starts. Oops, no. It's a matter of storage configuration, not of the edk2 version. pc + -cdrom -> IDE cdrom -> very slow boot. q35 + -cdrom -> SATA cdrom -> needs ~ 5sec here. virtio-scsi + scsi cdrom -> less than a second. IDE probably uses PIO mode, which implies there are *lots* of vmexits to handle I/O.
(In reply to Gerd Hoffmann from comment #4) > (In reply to Gerd Hoffmann from comment #3) > > > Actual results: > > > Sits on TianoCore splashscreen > > > > Hmm. For me it is just much slower for some reason, > > when waiting long enougth the installer actually starts. > > Oops, no. It's a matter of storage configuration, not of the edk2 version. > > pc + -cdrom -> IDE cdrom -> very slow boot. > q35 + -cdrom -> SATA cdrom -> needs ~ 5sec here. > virtio-scsi + scsi cdrom -> less than a second. > > IDE probably uses PIO mode, which implies there are *lots* of vmexits to > handle I/O. I went ahead and tried with q35 but still no dice, still hangs after "Press any button to continue". I tried a few other flags, cpu, vga, spice, cdrom to see it maybe it was something else breaking things but nothing really seemed to change. I tried pointing to the ovmf-4m version but that one threw a could not load PC BIOS error (same on the older working package and I suspect a permission issue). Doing some more research didn't bring about any new information beyond downgrading or using a different distro's package to get things working: https://github.com/tianocore/edk2/discussions/3221#discussioncomment-5501246 https://unix.stackexchange.com/questions/741019/windows-11-kvm-guest-hangs-on-install-in-fedora-37 When I have a bit more time I'll work on compiling from source (both the package's source and edk source directly) to see if I experience the same issue.
> -cdrom /path/to/Win11_22H2_English_x64v1.iso Oh, 22H2. That's probably the same thing as bug 2189136 then. Try https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ (in a hour or so, compiling still ...).
Created attachment 1962443 [details] edk2 debug output qemu edk2 debug output -debugcon file:debug.log -global isa-debugcon.iobase=0x402
(In reply to Gerd Hoffmann from comment #6) > > -cdrom /path/to/Win11_22H2_English_x64v1.iso > > Oh, 22H2. That's probably the same thing as bug 2189136 then. > > Try https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ > (in a hour or so, compiling still ...). Yup, I was able to confirm it is the same issue, debug file attached; and the test build works.
bug 2189136 contains more details on the issue *** This bug has been marked as a duplicate of bug 2189136 ***
FEDORA-2023-adf7efd2ce has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-adf7efd2ce
FEDORA-2023-adf7efd2ce has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-1c98da35aa has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1c98da35aa
FEDORA-2023-1aabe4d460 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1aabe4d460
FEDORA-2023-1c98da35aa has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1c98da35aa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1c98da35aa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1aabe4d460 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1aabe4d460` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1aabe4d460 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1c98da35aa has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-ca393d660a has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ca393d660a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ca393d660a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ca393d660a has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.