[Bug 1585008] Re: Windows 7 guests hang on bootup when qxl video is used

This is a dupe of LP#1581936 and LP#1591724. The issue is fixed by upstream QEMU commit 94ef4f337fb6. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1585008 Title: Windows 7 guests hang on bootup

[Bug 1624096] Re: yakkety: backport (or rebase to) fix eliminating a double-close in shim

Also, I should mention in passing -- again -- that Launchpad is completely retarded for truncating comments in the full bug view. It doesn't offer any option to see both the full bug and full comments. How stupid is that?! Are people who take the time to explain things in detail really considered

[Bug 1624096] Re: yakkety: backport (or rebase to) fix eliminating a double-close in shim

@Jason, there are two separate topics in your question. First, controlling the boot order from the QEMU command line (i.e., filtering and/or reordering the persistent UEFI boot options that (a) exist from earlier in the varstore, plus (b) OVMF's platform BDS regenerates at every boot). For this,

[Bug 1624096] Re: yakkety: backport (or rebase to) fix eliminating a double-close in shim

@Jason -- according to the upstream fix (7052e7530755) that Yakkety is currently missing, the upstream regression comes from upstream commit 4794822. That commit (i.e., the regression) is between the 0.9 release and 14a5905. According to

[Bug 1624096] Re: yakkety: backport (or rebase to) fix eliminating a double-close in shim

@Jason -- your script looks alright to me. Can you attach the OVMF debug log captured with the script? (Although, if the debug mask configured at build time in the DSC files don't enable the DEBUG_VERBOSE bit, I won't see everything in the log that I would like to see.) More importantly, can you

[Bug 1624096] Re: yakkety: desktop and server ISOs wont boot under QEMU in UEFI mode

Add all three of the following options to your QEMU command line: -debugcon file:debug.log \ -global isa-debugcon.iobase=0x402 \ -serial stdio In the OVMF debug log, you will see that your boot loader is launched: [Bds]Booting UEFI QEMU DVD-ROM QM3 FatDiskIo: Cache Page

[Bug 1624096] Re: yakkety: desktop and server ISOs wont boot under QEMU in UEFI mode

I found the error in shim. It is a double-close (on error handling) of the root directory of the filesystem. I'll submit a patch soon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1624096 Title:

[Bug 1624096] Re: yakkety: desktop and server ISOs wont boot under QEMU in UEFI mode

Actually, I don't need to write any new patches, upstream shim has the problem fixed already: commit 7052e75307553edc8f04eb529b0d37844fbcc30b Author: Benjamin Antin Date: Mon Jul 18 12:28:12 2016 -0700 Don't close file twice in should_use_fallback

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

You are probably hitting one of LP#1715700 and LP#1714331. (Upgrading from "Zesty" (17.04) to "Artful" (17.10) seems to imply a QEMU upgrade from 2.8 to 2.10.) LP#1715700 was fixed in edk2 commit range b68c793144e8..947f3737abf6: ba1d245f1d3d OvmfPkg/CsmSupportLib: move PAM register addresses to

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

In comment 17, Krupp confirmed that even current-ish upstream (d8e36289cef7, "EmbeddedPkg: add driver to set graphical/serial console preference", 2017-10-20) was broken for them; so I was definitely off with my LP#1715700 parallel. Sorry about that. The bisection thus far has narrowed down the

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 to not boot after upgrade

@Max: most important is to isolate the component whose upgrade causes the regression for you. OVMF, QEMU, libvirt (possibly, but unlikely), and host kernel (=KVM). Once isolated, the component should be bisectable. See also LP#1723731 -- the issue you are seeing might be a duplicate. (I haven't

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Hold on, the machine type could have an impact. I switched my script in comment#30 from q35 to pc, and the IDE CD-ROM boot slowed to a crawl. I've always assumed that this difference was simply due to q35 having AHCI/SATA and pc having only plain IDE, but maybe there is a perf regression specific

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Thanks everyone for the investigation thus far. I cannot reproduce the issue (using an IDE CD-ROM): * QEMU: tested both the v2.10.1 release, and current upstream master (3d7196d43bfe, "Merge remote-tracking branch 'remotes/kraxel/tags/usb-20171023-pull-request' into staging", 2017-10-24) *

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

** Attachment added: "undamaged table from comment#32" https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560/+attachment/4994611/+files/lp-1725560-c-32-table.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

OK, given that the edk2 commit in question is correct, I asked specifically for bug-compat ideas on edk2-devel: http://mid.mail-archive.com/5bf829cb-4517-a579-ba7c- 745c4ee89...@redhat.com I'll also try to ask IDE and Windows experts for help with figuring out what Windows is waiting for, when

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Using the script from comment#30: QEMU machine OVMF time from launch to typefirst install screen --- - v2.8.1.1 pc 704b71d7e11f

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

In other news, LaunchPad is an abomination. Way to screw up my nicely laid out table in comment#32. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1725560 Title: OVMF UEFI firmware causes Windows 10

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

( Aleksei: no, mail-archive.com is a public mailing list archive, it does not require subscription. After the demise of GMANE, I started using references to mail- archive.com because similarly to GMANE, it also provides lookup by Message-Id -- regardless of the specific mailing list(s) that the

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Posted: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices() http://mid.mail-archive.com/20171026154819.20865-1-lersek@redhat.com https://lists.01.org/pipermail/edk2-devel/2017-October/016535.html I CC'd a few people for feedback -- please send

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Re: comment 32: > BTW, I've also noticed that a large chunk of the delay, with i440fx, is > not even spent loading data from the IDE CD-ROM. IDE emulation means host > CPU load, but in this case, Windows just sits there with the empty > purplish/bluish screen, and there is zero host CPU load --

[Bug 1725560] Re: OVMF UEFI firmware causes Windows 10 w/ GPU passthrough to not boot after upgrade

Thanks everyone for the help; I pushed the patch in comment #40 as edk2 commit 76fd5a660d70. ** Changed in: edk2 (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1789319] Re: Unable to load shimx64.efi using iPXE over UEFI

I may be able to provide some information here, about iPXE. (Corrections welcome, obviously!) iPXE can be built in a number of ways. Two of those are: (1) as a UEFI *driver* that is presented in a NIC's PCI ROM BAR (i.e., as part of a PCI expansion ROM), (2) as a UEFI *application* that can be

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Per comment #32, fixed in upstream iPXE commit 2ae5d4338, setting ticket status for iPXE to "Fix Committed". ** Changed in: ipxe Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Sorry about the malformed table in comment 33 -- that's not my doing. I laid it out correctly; Launchpad messed it up by squeezing whitespace. Here it is again, using dots rather than spaces. Ubuntu.release..edk2.HTTPS.enabled..iPXE.HTTPS.enabled..iPXE.TPL.regression

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Hello Christian, For *some* form of UEFI HTTPS boot, you have to enable *at least one* of the {edk2, iPXE} HTTPS stacks. I'm unfamiliar with the Ubuntu releases, but my understanding is the following: Ubuntu release edk2 HTTPS enabled iPXE HTTPS enabled iPXE TPL regression --

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Vlad, you could subscribe to ipxe-devel at , wait until it's confirmed (I think it's automatic, so no moderator approval is needed for subscribing), and then resend your message. You can even stay subscribed -- if you don't want to get the

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Christian, what you describe seems to be exactly what I propose. Namely: - build "82540em.rom" with HTTPS enabled, - build "82540em.efirom" with CONFIG=qemu, and HTTPS disabled, - create a combined option ROM image from the above two, using "catrom.pl". Thanks Laszlo -- You received this bug

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Christian, > But it seems for legacy roms like 82540em.rom CONFIG=qemu being set or not > doesn't make a > difference. (1) That's my understanding as well; from the following original iPXE commits anyway: - a15c0d7e868a ("[efi] Allow user experience to be downgraded", 2015-07-22), -

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Christian, you can enable DOWNLOAD_PROTO_HTTPS in the traditional BIOS image built from iPXE, and disable it in the UEFI driver built from iPXE. You can still combine both drivers into a combined option ROM. For SeaBIOS guests, there's not going to be any change. For UEFI guests, see my

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

I used qemu-system-x86_64 \ -enable-kvm \ -monitor stdio \ -drive if=pflash,snapshot=on,format=raw,file=OVMF.fd \ -global e1000.romfile=82540em.combined.rom \ -debugcon file:debug.log \ -global isa-debugcon.iobase=0x402 where "OVMF.fd" was built from edk2 at then-master (14c7ed8b51f6

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Vladislav, The OVMF debug log ends like this (with UEFI protocol GUIDs decoded as their textual identifiers in edk2): > [Security] 3rd party image[6D19D18] can be loaded after EndOfDxe: > PciRoot(0x0)/Pci(0x3,0x0)/Offset(0x16400,0x4B1FF). > InstallProtocolInterface: [EfiLoadedImageProtocol]

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Please add -debugcon file:debug.log -global isa-debugcon.iobase=0x402 to the QEMU cmdline, and attach "debug.log". Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title:

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Hi Vlad, the ipxe-qemu package in Ubuntu (1.0.0+git-20190109.133f4c4-0ubuntu3) is built with DOWNLOAD_PROTO_HTTPS enabled (in "src/config/general.h"). According to the Ubuntu changelog, this is a new feature added in "1.0.0+git-20190109.133f4c4-0ubuntu1". With DOWNLOAD_PROTO_HTTPS enabled, I can

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

** Summary changed: - qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios + unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

(From the UEFI executable name "82540em.efi" in the log, I initially suspected an assigned physical NIC with a buggy flashed-on oprom. But grepping the iPXE tree for "82540em" yields a match, and QEMU loads the iPXE oproms by default into the emulated NICs' ROM BARs.) -- You received this bug

[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled

Hi Michael, thank you for the fix, and for mentioning it here. I didn't ignore your comment 32 when I was writing what would become comments 33 and 34 -- I think we must have been writing our comments in parallel, and I simply didn't see yours. Christian, now you should be able to resolve this LP