OVMF UEFI firmware causes Windows 10 to not boot after upgrade

[Krupp]

[Impact]
Windows 10 guests using IDE storage fail to boot (or boot *really* slowly)

[Test Case]
Boot a Windows 10 install ISO, using an emulated IDE drive on an i440fx model.

[Regression Risk]
The fix is a partial revert of a change that landed upstream between zesty & artful. Since there were no similar issues reported w/ the zesty release, it somewhat mitigates the risk that a regression is out there. The fix is ATA specific, so any regressions should be localized to guests that use ATA.

[dann frazier (dannf)]

Thanks for the report! I attempted to reproduce w/ a straight Win10 install, but I didn't have any problems. I suspect (as you imply) this maybe related to the GPU passthrough. Unfortunately, I don't have a way to reproduce that myself so, if you're willing, I could use some assistance running some tests.

First, let's confirm that pure upstream builds - built in the same environment - have the same results. Could you test the following builds?:

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.7bbe0b3ef

(How to do that depends on how you are booting your VM - if you're not sure, let me know what method you are using).

[Krupp (cjkrupp)]

Alright, I checked both of those from upstream:

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4
This one works correctly, no issues.

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.7bbe0b3ef
This one does not work, meaning that Windows appears to be trying to boot (has the dot ring rotating) but acts as if it cannot find some file required to boot. It will also boot a Windows 10 iso, but after a very long time (around 30 minutes). Linux iso and installs boot correctly (installed in UEFI mode). These same symptoms were present in my original post.

A little more info on my setup:

I am running a Ryzen 1800X with X370 chipset, host system kernel arguments (quiet splash amd_iommu=on pcie_acs_override=downstream $vt_handoff), virtual machines are KVM using Virtual Machine Manager.

When I have a little more free time, I will try to do a little more in depth research into the problem.

[dann frazier (dannf)]

Thanks for testing! The results are confounding though. It appears that, while the zesty package worked for you, the upstream base (7bbe0b3ef) for the zesty version did not. And, while the artful version fails for you, the upstream base (5dfba97c) for the artful version *did* work. Can you double-check those results just to be sure?

[Krupp (cjkrupp)]

Yea, you are right, I seemed to have flipped them.

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.7bbe0b3ef
This one works.

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4
This one does not work.

Sorry for the confusion.

[dann frazier (dannf)]

Ah, great! Then we have a path forward. I'll prepare you a series of builds of bisect source to try and identify the change that broke it. Here's the first one:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.8693aa6a1

[Krupp (cjkrupp)]

Alright, I gave that last one a test:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.8693aa6a1

This version works, however there is a small difference. During booting of OVMF_CODE.fd.8693aa6a1, it shows the white dot ring when booting windows as described above, but also shows the "Tianocore" logo above that. The other working version that I have been using, OVMF_CODE.fd.7bbe0b3e, also works, but displays the blue Windows 10 logo. Seems like an insignificant difference, but I think it may offer some clue. Apart from that difference, everything appears operational. I tried swapping versions multiple times in order to confirm the difference, and it acted as described each time.

[dann frazier (dannf)]

Ok, thanks. Here's the next one (note that the estimate for this bisect is 9 tests):
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.401d1343c

[Laszlo Ersek (Red Hat) (lersek)]

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 IndustryStandard
ce461ae240a7 OvmfPkg/QemuVideoDxe/VbeShim: rename Status to Segment0AllocationStatus
947f3737abf6 OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

edk2 commits related to LP#1714331 are:

198a46d768fb MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT,X_DSDT} mutual exclusion
78807f605082 MdeModulePkg/AcpiTableDxe: Not make FADT.{DSDT,X_DSDT} mutual exclusion
072060a6f81b OvmfPkg: Allow multiple add-pointer linker commands to same ACPI table

at least; in this order.

Regarding the change to the boot animation, that's due to commit 6e5e544f227f ("OvmfPkg: Install BGRT ACPI table", 2017-01-06).

[Krupp (cjkrupp)]

Okay, thanks Laszlo Ersek, good to know that behavior is expected then.

I tried out:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.401d1343c

This one works correctly.

[dann frazier (dannf)]

Thanks Laszlo! artful has the patches you mention as related to LP: #1714331, but not the patches you mention as related to LP: #1715700.

@Krupp: Can you test this build to see if the patches for LP: #1715700 fix it for you?
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4+lp1715700

If that build doesn't work, here's the next build in the bisect to test:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.e5251fecb

[Krupp (cjkrupp)]

Sure thing!

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4+lp1715700
The patched version still does not work.

http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.e5251fecb
The bisect works.

[dann frazier (dannf)]

On Mon, Oct 23, 2017 at 2:50 PM, Krupp <email address hidden> wrote:
> Sure thing!
>
> http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5dfba97c4+lp1715700
> The patched version still does not work.

:(

> http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.e5251fecb
> The bisect works.

OK - then here's the next one:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.821f24b12

[Krupp (cjkrupp)]

This one works correctly:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.821f24b12

[dann frazier (dannf)]

On Mon, Oct 23, 2017 at 3:13 PM, Krupp <email address hidden> wrote:
> This one works correctly:
> http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.821f24b12

Thanks. Next one:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.ae66c6f12

  -dann

[Krupp (cjkrupp)]

This one works correctly:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.ae66c6f12

[dann frazier (dannf)]

Thank you. Here's the next one:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5659ec3fa

Also, probably worth checking to see if latest upstream is still affected:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.d8e36289c

[Krupp (cjkrupp)]

Okay, I checked both of them twice and neither are working:
Bisect:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.5659ec3fa
Upstream:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.d8e36289c

Sorry I can't help more, I'm looking into how to bisect in git and maybe in the future I will be of more assistance.

[dann frazier (dannf)]

No worries, you're testing has been very helpful. Here's the next build - estimated 4 more left to test:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.9a04dcffb

[Krupp (cjkrupp)]

This one works correctly:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.9a04dcffb

[dann frazier (dannf)]

OK, next one:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.c50596a70

[Krupp (cjkrupp)]

This one works correctly:
http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.c50596a70

[Dr. David Alan Gilbert (dgilbert-h)]

Re Laszlo's comment #8 - it feels the opposite way around to lp 1715700 - in that I don't think downgrading OVMF helped; so perhaps something else is going on?

[Laszlo Ersek (Red Hat) (lersek)]

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 introduction of the issue
to the following commits:

  git log --oneline --reverse --no-decorate c50596a70143..5659ec3fa913 \
  | cat -n

     1 3d4361663276 MMC : Added missing __FUNCTION__ macro.
     2 ea21f1d98dcc SD : Updated CMD 6 implememtation.
     3 3281ebb4ae7d Nt32Pkg: Clean up DSC to remove unnecessary build
                     option in SecMain
     4 eed3f7130522 MdeModulePkg/AtaAtapiPassThru: cache
                     EnabledPciAttributes
     5 509daa658b79 MdeModulePkg/AtaAtapiPassThru: unmap DMA buffers
                     after disabling BM DMA
     6 6fb8ddd36bde MdeModulePkg/AtaAtapiPassThru: disable the device
                     at ExitBootServices()
     7 5659ec3fa913 OvmfPkg/VirtioBlkDxe: don't unmap VRING at
                     ExitBootServices()

I don't see how patches #1 through #3 could be relevant.

Patch #7 is a no-op in non-SEV guests.

Patches #4 through #6 are also from yours truly. I wonder if patch #6:

  https://github.com/tianocore/edk2/commit/6fb8ddd36bde

tickles something in QEMU 2.10 that makes the IDE controller unusable to
Windows.

I don't think that edk2 commit 6fb8ddd36bde is broken; disabling bus
master DMA at ExitBootServices() is valid. The commit been used on
physical ATA controllers as well, since its introduction.

Given that I can't see anything suspicious and/or invalid in the above
edk2 commit range, I suggest that -- after the current edk2 bisection is
completed -- we bisect QEMU between 2.8 and 2.10, using the package

  ovmf_0-20170911.5dfba97c-1_all.deb

In comment #1 Dann stated he could *not* reproduce the issue. Was that
perhaps because Krupp used IDE but Dann used virtio? Krupp, can you
please provide your exact QEMU command line and/or libvirt domain XML?
Thanks.

[dann frazier (dannf)]

On Tue, Oct 24, 2017 at 5:37 AM, Laszlo Ersek (Red Hat)
<email address hidden> wrote:
> In comment #1 Dann stated he could *not* reproduce the issue. Was that
> perhaps because Krupp used IDE but Dann used virtio?

I am in fact using virtio.

[Krupp (cjkrupp)]

I won't be able to work on it until quite a bit later today, but I can confirm that I am using IDE as the virtual hard drive. I will post the xml later tonight. Thanks for the help.

[dann frazier (dannf)]

Next one in the bisect:
  http://people.canonical.com/~dannf/lp1725560/OVMF_CODE.fd.3281ebb4a

[dann frazier (dannf)]

fwiw, I'm able to reproduce the slow-to-boot-ISO issue by using IDE. With that as a symptom, I completed the bisect and hit:

6fb8ddd36bde MdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices()

Prior to this commit, it took 34s for me to go from EFI shell to first install screen.
With this commit, it takes 8.5 minutes. I tried to complete an install in this mode but gave up after an hour w/ the installer hung at 10% in "preparing files for install."

[Aleksei Kovura (alex3kov)]

I'm also hitting freakishly long IDE boots with latest edk2/ovmf, QEMU 2.10.1 and win7 x64 guest.
A workaround for me was to to boot the VM with win7 iso, virtio iso and drive image all on ahci bus; then assign C: to windows partition and inject drivers into it from virtio cd with "dism /image:c:\ /add-driver /driver:e:\win7\amd64\viostor.inf". After that windows can boot off virtio interface.
When/if you guys need additional info - I can do tests/bisect, let me know.

[Krupp (cjkrupp)]

Would you like me to continue with the bisects or do anything else?

I've attached my XML configuration in case anyone is still interested.

[Laszlo Ersek (Red Hat) (lersek)]

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)

* OVMF: built from current upstream master (704b71d7e11f,
  "MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of
  SMM", 2017-10-10)

QEMU script:

> ISO=/mnt/data/isos/iso-windows/en_windows_10_enterprise_2015_ltsb_n_x64_dvd_6848316.iso
> CODE=/home/virt-images/OVMF_CODE.4m.fd
> TMPL=/home/virt-images/OVMF_VARS.4m.fd
>
> cp $TMPL vars18.fd
>
> /opt/qemu-installed/bin/qemu-system-x86_64 \
> -m 2048 \
> -M q35 \
> -enable-kvm \
> -device qxl-vga \
> -drive if=pflash,readonly,format=raw,file=$CODE \
> -drive if=pflash,format=raw,file=vars18.fd \
> -drive id=cdrom,if=none,readonly,format=raw,cache=writethrough,file=$ISO \
> -device ide-cd,drive=cdrom,bootindex=0 \
> -debugcon file:debug18.log \
> -global isa-debugcon.iobase=0x402 \
> -monitor stdio

Wall clock time from QEMU invocation to first install screen: 9 seconds.

Now, this script does not assign a GPU with vfio-pci, but I understand Dann
didn't do that either, yet he managed to reproduce the issue. Can someone
please paste a *minimal* QEMU command line reproducer , preferably without
vfio-pci; even more preferably with just an IDE CD-ROM? (To my
understanding, this is exactly how Dann reproduced the issue; see
comment#17.)

Also, from the comments thus far, it looks like edk2 commit 6fb8ddd36bde
makes a difference under QEMU 2.10. However, it is not clear to me if the
same edk2 commit makes a similar difference under QEMU 2.8. The original
report mentions a full system upgrade, which (I assume) upgraded both OVMF
and QEMU. Can someone -- who otherwise reproduces the issue -- please test
OVMF, built from upstream edk2, under QEMU 2.8?

Thanks.

[Laszlo Ersek (Red Hat) (lersek)]

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 to IDE (pc) only.

FWIW, edk2 commit 6fb8ddd36bde applies to both controllers.

[Laszlo Ersek (Red Hat) (lersek)]

Using the script from comment#30:

QEMU machine OVMF time from launch to
          type first install screen
-------- ------- --------------------- --------------------
v2.8.1.1 pc 704b71d7e11f 117 s
v2.8.1.1 pc 704b71d7e11f\6fb8ddd36bde 44 s

v2.8.1.1 q35 704b71d7e11f 9 s
v2.8.1.1 q35 704b71d7e11f\6fb8ddd36bde 9 s

v2.10.1 pc 704b71d7e11f 119 s
v2.10.1 pc 704b71d7e11f\6fb8ddd36bde 46 s

v2.10.1 q35 704b71d7e11f 10 s
v2.10.1 q35 704b71d7e11f\6fb8ddd36bde 9 s

Observe:

- The QEMU release plays no role

- on q35 the boot is generally much faster than i440fx

- q35 is unaffected by edk2 commit 6fb8ddd36bde

- on i440fx, reverting edk2 commit 6fb8ddd36bde on top of current master
  (704b71d7e11f) decreases the wall clock time from ~118s to ~45s.

To me this totally looks like a Windows bug; edk2 commit 6fb8ddd36bde does
the right thing. The patch disables PCI bus master DMA for the IDE/AHCI
controller in question at ExitBootServices(), i.e. when the OS gains control
of the system from the firmware. At that point ownership of the RAM is
transferred to the OS, and in-flight DMA has to be aborted (otherwise DMA
pending from the firmware could overwrite RAM that is now owned by the OS).
Whether a controller is passed -- from firmware to the OS -- with DMA
enabled vs. DMA disabled in the PCI command register, should have zero
consequence on how the OS drives the controller subsequently, with its own
native driver.

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 -- nothing happens.
It's as if Windows was waiting for some timer to expire.

[Laszlo Ersek (Red Hat) (lersek)]

In other news, LaunchPad is an abomination. Way to screw up my nicely laid out table in comment#32.

[Laszlo Ersek (Red Hat) (lersek)]

OK, given that the edk2 commit in question is correct, I asked specifically for bug-compat ideas on edk2-devel:

http://<email address hidden>

I'll also try to ask IDE and Windows experts for help with figuring out what Windows is waiting for, when it's apparently doing nothing.

As a mid-term mitigation / work-around, I suggest using virtio-block or virtio-scsi for hard disks, and virtio-scsi for CD-ROMs. Windows (7, 8, and 10) can be perfectly well installed from a virtio-scsi CD-ROM to a virtio-scsi or virtio-blk hard disk, as long as the guest has *another* CD-ROM, using IDE or AHCI, and this CD-ROM presents the virtio-win ISO. The only thing the Windows installer *really* has to read from an IDE/AHCI CD-ROM is the virtio-scsi/virtio-block driver, all the rest can work with virtio.

[dann frazier (dannf)]

On Wed, Oct 25, 2017 at 9:32 AM, Laszlo Ersek (Red Hat)
<email address hidden> wrote:
> 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-
> <email address hidden>
>
> I'll also try to ask IDE and Windows experts for help with figuring out
> what Windows is waiting for, when it's apparently doing nothing.
>
> As a mid-term mitigation / work-around, I suggest using virtio-block or
> virtio-scsi for hard disks, and virtio-scsi for CD-ROMs. Windows (7, 8,
> and 10) can be perfectly well installed from a virtio-scsi CD-ROM to a
> virtio-scsi or virtio-blk hard disk, as long as the guest has *another*
> CD-ROM, using IDE or AHCI, and this CD-ROM presents the virtio-win ISO.
> The only thing the Windows installer *really* has to read from an
> IDE/AHCI CD-ROM is the virtio-scsi/virtio-block driver, all the rest can
> work with virtio.

Great, thank you! I'll monitor that thread.

[Aleksei Kovura (alex3kov)]

> OK, given that the edk2 commit in question is correct, I asked specifically for bug-compat ideas on > edk2-devel:
> http://<email address hidden>

I'm getting 404 on this link, is this only for redhat subscribers or something?

[Laszlo Ersek (Red Hat) (lersek)]

(

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 message in question was posted to. (The only requirement is that mail-archive.com be subscribed to at least one of the lists that the message was sent to.) The URL format is

  http://mid.mail-archive.com/<Message-Id>

The trick is that such URLs can be constructed, on the email sender's side, ahead of mail-archive.com picking up the message (from at least one mailing list) and indexing it. The URL can be constructed without any delay because the sender knows the Message-Id of the message they just sent. Initially the link will appear dead, but after a while it will start working.

So using these links I can just send the email, generate the link right after, and forget about it, regardless of how slow or fast the archive is that day.

)

[Laszlo Ersek (Red Hat) (lersek)]

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 -- nothing
> happens. It's as if Windows was waiting for some timer to expire.

The time Windows spends in this stuck state is exactly 1 minute.

[Laszlo Ersek (Red Hat) (lersek)]

Posted:

[edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at
               ExitBootServices()
http://<email address hidden>
https://lists.01.org/pipermail/edk2-devel/2017-October/016535.html

I CC'd a few people for feedback -- please send your Tested-by's if
appropriate.

I couldn't CC Krupp because their profile page on LP does not disclose their
email address, and my privmsg to them (via LP) hadn't been answered until I
mailed out the patch.

Nonetheless, anyone can fetch the patch by using the repo / branch URL
marked in the Notes section of the patch email:

    Repo: https://github.com/lersek/edk2.git
    Branch: ata_disable_only_bmdma

Please note, if you decide to follow up on the email, the edk2-devel mailing
list drops messages from non-subscribers. I've been trying to change this
practice:

  https://bugzilla.tianocore.org/show_bug.cgi?id=451

but I haven't succeeded thus far. So, if you'd like to respond, please
subscribe to the list first (wait for your subscription to complete!), and
then respond. The list page is:

  https://lists.01.org/mailman/listinfo/edk2-devel

[Aleksei Kovura (alex3kov)]

I'll test it in the next few days.

[Laszlo Ersek (Red Hat) (lersek)]

Thanks everyone for the help; I pushed the patch in comment #40 as edk2 commit 76fd5a660d70.

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 0~20171027.76fd5a66-1

---------------
edk2 (0~20171027.76fd5a66-1) unstable; urgency=medium

  * New upstream release.
    - Fix Win10 guests booting from IDE drives. LP: #1725560.

 -- dann frazier <email address hidden> Fri, 27 Oct 2017 16:10:29 -0600

[Krupp (cjkrupp)]

I installed the new upstream release 0~20171027.76fd5a66-1 and everything is working great. Thanks for all the help and finding a solution so quickly!

[dann frazier (dannf)]

On Mon, Oct 30, 2017 at 8:36 PM, Krupp <email address hidden> wrote:
> I installed the new upstream release 0~20171027.76fd5a66-1 and
> everything is working great. Thanks for all the help and finding a
> solution so quickly!

For my part, you're welcome. Note that I have also uploaded a backport
for artful. When that is accepted, this bug will be updated with a
(final) request for testing.

[Brian Murray (brian-murray)]

Hello Krupp, or anyone else affected,

Accepted edk2 into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/edk2/0~20170911.5dfba97c-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Krupp (cjkrupp)]

Alright, here is what I did. I used the default Artful sources. I started with the updated upstream ovmf version 0~20171027.76fd5a66-1.

apt-get update
apt-get remove ovmf
apt-get install ovmf

dpkg -l ovmf | cat
ovmf 0~20170911.5dfba97c-1 all UEFI firmware for 64-bit x86 virtual machines

Tested package and confirmed not working.

This was without the proposed repository enabled. I initially did not notice the version was the same as what you posted.

Added proposed sources to /etc/apt/sources.list

apt-get update
apt-get remove ovmf
apt-get install ovmf

dpkg -l ovmf | cat
ovmf 0~20170911.5dfba97c-1 all UEFI firmware for 64-bit x86 virtual machines

It would seem that the package most likely moved quickly from proposed into the main repositories, however this package does not fix my issue.

Installed the upstream package:
dpkg -i ovmf_0-20171027.76fd5a66-1_all.deb

dpkg -l ovmf | cat
ovmf 0~20171027.76fd5a66-1 all UEFI firmware for 64-bit x86 virtual machines

This package is confirmed working.

If there is anything else I can do, let me know.

[Krupp (cjkrupp)]

I just wanted to clarify that the Artful proposed and main package version 0~20170911.5dfba97c-1 are not working. I wrote the above response in a strange order and I apologize.

[dann frazier (dannf)]

Ah, OK. I've moved this back to verification-needed.

Note that the version in artful-proposed is: 0~20170911.5dfba97c-1ubuntu0.1. It doesn't appear that you have tested that one yet.

[Krupp (cjkrupp)]

I tested it in the comment above. I guess what I was trying to show is that I expected version 0~20170911.5dfba97c-1 to be in the proposed repository, but by the time I got to test it, it came from the main repository. I verified that version 0~20170911.5dfba97c-1 does not work and have gone back to using the upstream version.

[dann frazier (dannf)]

To be clear, 0~20170911.5dfba97c-1ubuntu0.1 is the artful-proposed version. 0~20170911.5dfba97c-1 is the artful release version:
  See: http://launchpad.net/ubuntu/+source/edk2

The one with "the ubuntu0.1" suffix is the one with the fix.
Can you (re-?)confirm that you tested with 0~20170911.5dfba97c-1ubuntu0.1 ?

[Krupp (cjkrupp)]

Oh okay, didn't know the -1ubuntu0.1 made a difference, sorry. I tested 0~20170911.5dfba97c-1ubuntu0.1 and can confirm it is working correctly. Again, sorry for the confusion and thanks for the help.

[Max Ehrlich (queuecumber)]

I think I'm also getting hit with this bug, or else something very similar. I migrated this VM from a 17.04 install to a fresh 17.10 install. Since then I haven't been able to boot Windows successfully. It seems to be booting fine (I see the spinning white circle) but then I just get a black screen with a mouse, nothing else seems to boot (although I will say that the fact that I can move my mouse at all means Synergy has started, but I'm at a loss for how to get more debugging information out of Windows).

Main differences with what I'm seeing: I'm not using IDE, I am using VirtIO SCSI, and I have not been able to boot successfully from any of the OVMF firmwares that were provided in this thread. Even copying all the OVMF files from my 17.04 installation isnt fixing things (it causes windows to throw a 255 error whatever that means)

Another thing I want to note is that, as mentioned somewhere else in this thread, when booting the blue Windows logo is replaced by the tiano core logo. This happens even when windows is trying to disk check or start the system repair process. I think this is a *very* worrisome indicator of a problem in the firmware and I wouldn't be surprised if understanding how that happened lead to a larger problem that was causing some of these other issues.

[Krupp (cjkrupp)]

Did you try installing this as described above?:

https://launchpad.net/ubuntu/+archive/primary/+files/ovmf_0~20170911.5dfba97c-1ubuntu0.1_all.deb

The tianocore logo change doesn't really matter as they talked about above, it is an expected change.

Sounds like what I have been experiencing.

[Max Ehrlich (queuecumber)]

Yeah I've installed the 9/11 and 10/27 debs as well as several of the bisected OVMF_CODE.fd files you marked as working, no luck. I am currently trying a bunch of different fresh windows VM installs to see if I can narrow down a specific set of options that causes the problem. Or it's entirely possible something got messed up with the disk during my migrastion I suppose.

I did some more research on the logo change and indeed it seems like their trying to treat it as a OEM style boot logo for debugging purposes so I was probably misinterpreting it.

[dann frazier (dannf)]

@Max: Can you file a new bug? The fix here was in the IDE subsystem and, since you're not using IDE, you're bug is unlikely related.

Note that if you want to try the fix for this issue, be aware that there are *two* "9/11" debs:

  https://launchpad.net/ubuntu/+archive/primary/+files/ovmf_0~20170911.5dfba97c-1_all.deb

Which has the bug and

 https://launchpad.net/ubuntu/+archive/primary/+files/ovmf_0~20170911.5dfba97c-1ubuntu0.1_all.deb

Which has the fix.

I'll mark this has verified since it does resolve the problem @Krupp reported here.

[Laszlo Ersek (Red Hat) (lersek)]

@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 commented on LP#1723731 because I totally don't have the time to guide a user through component isolation, feature removal / cmdline trimming, and bisection; sorry.) Either way I agree with @dannf that it should be discussed elsewhere. Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 0~20170911.5dfba97c-1ubuntu0.1

---------------
edk2 (0~20170911.5dfba97c-1ubuntu0.1) artful; urgency=medium

  * d/p/MdeModulePkg-AtaAtapiPassThru-disable-only-BM-DMA-at.patch:
    Fix Win10 guests booting from IDE drives. LP: #1725560.

 -- dann frazier <email address hidden> Sat, 28 Oct 2017 09:22:31 -0600

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for edk2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.