Re: OVMF.fd and placement of EfiBootServicesData

[spam collector <spamcollector@cableone.net>]

----- Original Message -----
> From: "Laszlo Ersek" <lersek@redhat.com>
> To: "spam collector" <spamcollector@cableone.net>
> Cc: edk2-devel@ml01.01.org
> Sent: Thursday, October 6, 2016 12:39:39 AM
> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
> 
> > Remember that I am running this in WinXPSP3.
> 
> First, I can't "remember" it, because this is the first time you state
> that. :)

I apologize for that.  I thought I had mentioned it.
 
> Second, WinXPSP3 as host machine, really?... :)

What do you mean, "really?"  In my opinion, WinXP was the last usable, 
worth having OS from Microsoft.  As soon as they went to the platform
they have now, they lost all hope of ever getting anything back.
I haven't had to reboot this WinXP machine due to the OS for years.
It is less resource hungry, and much faster than the modern computers
I have around.  I would rather sit at this 10 year old machine running
WinXP any day of the week including Sunday over any of the more modern
Windows machine I have or seen.  Just my opinion though.  I, by no means,
intend to start a war over which Windows OS is better, nor do I want
to start a war over, "You should move to a Linux based machine."
If it isn't broke, I am not fixing it.

For that matter, I am not expecting a reply to that. :-)
 
> > Also, the version of
> > OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed
> > that that page has been recently changed.
> 
> That's a coincidence, but not a random one. Users have been repeatedly
> confused by the r15214 binary, which at this point was more than 2.5
> years old. Just before your query, I noticed
> <https://bugs.launchpad.net/qemu/+bug/1622582> (and marked it invalid);
> the reporter of that issue was also tripped up by the ancient r15214
> build. So I asked Jordan to please update the page you reference, with a
> link to Gerd's RPMs, which are bleeding edge builds.

Noted.

> >>
> >>   usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd
> >>   usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd
> >>   usr/share/edk2.git/ovmf-*/UefiShell.iso

As per another message in this thread, I changed the Subsystem value 
from the 0x0B to 0x0A and it now boots as expected.  There is still
OVMF stuff in the way :-), but boots as expected to that point.
 
> > Also, please note that the hard drive image is a VHD image, a
> > raw image with a single sector at the end for the VHD info so that
> > Oracles VM Box will boot it.  This means that the backup GPT header
> > is *not* the last sector of the disk.
> 
> As far as I know, QEMU supports VHDX. However, you pass a VHD image to
> -drive with format=raw. That looks very broken. I guess I'd suggest
> matching the actual image format with the format=... property. If you
> pass format=raw, the VHD metadata at the end of the image will be
> visible to the guest (as garbage).

The latest version of the Windows port of QEMU and OVMF as listed
above, boot and treat the drive as expected, ignoring the last sector.
i.e.: OVMF uses the value in the GPT header to find the backup instead
of finding the last sector.  It doesn't complain that it isn't the
last sector.

This image is just a test image that I can use with both QEMU and
Oracle's VMBox so I don't have to have two separate images.

I believe I have all of the information and the new/correct files
and can boot my code with these new files.

Thank you so much for your help and advice.  I appreciate the
effort you placed on my behalf.  

Thanks,
Ben