On Mon, Aug 26, 2013 at 12:46:32PM +0800, Michael Chang wrote:
> On Fri, Aug 23, 2013 at 08:33:31PM +0200, Laszlo Ersek wrote:
> > On 08/23/13 11:27, Michael Chang wrote:
> > > On Thu, Aug 22, 2013 at 06:05:58PM -0700, Jordan Justen wrote:
> > >> On Mon, Aug 19, 2013 at 3:00 AM, Michael Chang <[email protected]> wrote:
> > >>> On Sat, Aug 17, 2013 at 11:16:16PM -0700, Jordan Justen wrote:
> > >>>> The volatile 'NvVars' variable indicates that the variables do
> > >>>> not need to be loaded from the file again. After we write the
> > >>>> variables out to the file, there is clearly no need to load
> > >>>> them back from the file.
> > >>>>
> > >>>> Contributed-under: TianoCore Contribution Agreement 1.0
> > >>>> Signed-off-by: Jordan Justen <[email protected]>
> > >>>> Cc: Michael Chang <[email protected]>
> > >>>> Cc: Laszlo Ersek <[email protected]>
> > >>>> ---
> > >>>> Michael,
> > >>>>
> > >>>> Does this patch fix the issue you highlighted (way back) on June
> > >>>> 21st in your patch:
> > >>>> * OvmfPkg/NvVarsFileLib: handle the inital file not found
> > >>>
> > >>> It seems not fix the problem if I use regular openSUSE 12.3
> > >>> installation to a new virtual disk or chooses to recreate the ESP
> > >>> if it already exists.
> > >>>
> > >>> However the manual test step works, if without your patch it fails. I
> > >>> list the steps for reference.
> > >>>
> > >>> Fistly to simulate the initial (disk) condition.
> > >>>
> > >>> Delete NvVars File
> > >>> $ rm /boot/efi/NvVars
> > >>> Delete openSUSE boot entry
> > >>> $ efibootmgr -b 0005 -B
> > >>> Delete NvVars variables
> > >>> $ cd /sys/firmware/efi/vars
> > >>> $ cat NvVars-<GUID ..>/raw_var > del_var
> > >>> Power off
> > >>> $ poweroff
> > >>>
> > >>> Now we can start vm to install the bootloader, use efi shell to
> > >>> launch the installed grub2. In the booted system, use
> > >>> $ grub2-install
> > >>>
> > >>> Check if boot variable are written correctly
> > >>> $ efibootmgr -v
> > >>>
> > >>> Reboot and check if opensuse shows in the EFI boot manager ..
> > >>>
> > >>> So there could be some other corner cases, but I cannot tell it now.
> > >>> I can continue to investigate it or do you have any other better
> > >>> idea?
> > >>
> > >> Do these failing scenarios work with your original patch?
> > >
> > > My patch fails as well.
> >
> > I agree.
> >
> > The problematic sequence is this:
> > 1. LoadNvVarsFromFs() doesn't find L"NvVars" in RAM
> > 2. LoadNvVarsFromFs() doesn't find file store --> doesn't set L"NvVars"
> > 3. SaveNvVarsToFs() *succeeds*
> > 4. ExitBootServices()
> > 5. RT variable change, in RAM only
> > 6. warm reboot
> > 7. LoadNvVarsFromFs() doesn't find L"NvVars" in RAM (due to step 2)
> > 8. LoadNvVarsFromFs() loads the file store (due to step 3),
> > overwriting/losing step 5
> >
> > This sequence (bug) doesn't apply when we start out with an
> > unpartitioned disk, because step 3 doesn't work there.
> >
> > The sequence (bug) doesn't apply either when we start with a formatted
> > EFI System Partition that contains the file store, because step 2
> > succeeds then, and step 7 and step 8 don't happen.
> >
> > The sequence (bug) applies when we start with a formatted EFI System
> > Partition that has no file store. Under those circumstances Jordan's
> > patch prevents the bug too. And it is pretty much to the point: step 3
> > is the immediate cause of the lossage in step 8, and the patch prevents
> > steps 7 and 8 right in step 3, by setting L"NvVars".
> >
> > For Jordan's patch (...too, because I acked Michael's as well):
> >
> > Reviewed-by: Laszlo Ersek <[email protected]>
> >
> > (The commit message does not reflect the above steps precisely, but
> > let's not obsess about this any longer!)
> >
> >
> > > I think the problem is I'm using virt-intall, and there might be some
> > > tricks on how libvirt restarts domain after installation finished that
> > > may actually restart from power-down ? Laszlo did you aware any issue
> > > reported for libvirt before ?
> >
> > If you power off the VM at step 6, you lose all changes from step 5
> > right there, independently of your original "partitioning / file store
> > status".
> >
> > Regarding virt-install... Check out '--print-step' in the virt-install
> > manual: virt-install distinguishes three steps (three first boots) of a VM.
> >
> > --print-step
> > Acts similarly to --print-xml, except requires specifying which
> > install step to print XML for. Possible values are 1, 2, 3, or
> > all. Stage 1 is typically booting from the install media, and
> > stage 2 is typically the final guest config booting off hardisk.
> > Stage 3 is only relevant for windows installs, which by default
> > have a second install stage. This option implies --quiet.
> >
> > I guess this distinction between steps is mainly important so that the
> > install media can be ejected in a "safe way".
>
> Many thanks for enlightening me this. It was --livecd option which
> makes the difference on my test. I confirmed that with --livecd the
> issue solved with Jordan's patch.
>
> I think things just like what you've described, without --livecd the
> installation media has to be ejected thus virtual machine may be
> powered down after step1 in order to start step2 without it's
> participating.
>
> Jordan, there's nothings suspend for me now, so here is my
> acknowledgement at your disposal.
>
> Tested-by: Michael Chang <[email protected]>
Hm..while I was testing another patch, occasionally I found that efi
boot entries were duplicating on every reboot. After several cycles I
have the following boot entries ..
BootCurrent: 0005
BootOrder: 0005
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0002* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0003* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot0004* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
Boot0005* opensuse
HD(1,800,4e000,1dc0cd72-7066-4f25-9d2c-1beb4da6dfcf)File(\EFI\opensuse\grubx64.efi)
Boot0006* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0007* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0008* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0009* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot000A* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
Boot000B* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot000C* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot000D* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot000E* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot000F* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
Boot0010* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0011* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0012* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0013* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot0014* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
Boot0015* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0016* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0017* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0018* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot0019* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
Boot001A* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot001B* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot001C* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot001D* EFI Network ACPI(a0341d0,0)PCI(3,0)MAC(525400c2a452,1)
Boot001E* EFI Internal Shell MM(b,3fa7e000,3ffbdfff)
After reverting this patch (git commit 6bc7a08) the problem was gone.
Quite irony I was the one who acknowledged the test result. :/
Trying to go further and debugging it, a (clueless) patch attached
which's working for me to fix the problem. The puzzle work is
obviously too much for me.
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index ba6af2c..be1bb79 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -1148,7 +1148,7 @@ Returns:
DEBUG ((EFI_D_INFO, "BdsLibConnectAll\n"));
BdsLibConnectAll ();
- BdsLibEnumerateAllBootOption (BootOptionList);
+ //BdsLibEnumerateAllBootOption (BootOptionList);
SetBootOrderFromQemu (BootOptionList);
My guess is BdsLibConnectAll () reads NvVars and then
BdsLibEnumerateAllBootOption (BootOptionList) appends even more, and
finally they were saved. This logics repeats every time and the Boot
varaibles grows ..
Thanks,
Michael
>
> >
> > However, when I install an OVMF guest, I don't allow virt-install to
> > actually start the VM. I documented my method in
> > <http://www.linux-kvm.org/page/OVMF>.
> >
> > In a nutshell, I only prepare a domain XML file with virt-install
> > (--print-step=1).
> >
> > Then I post-process the XML (because these things are not directly
> > supported by virt-install on my RHEL-6 laptop):
> > - setting OVMF.fd as boot firmware binary,
> > - setting a wrapper script around qemu-kvm as emulator,
> > - potentially setting the main disk type to virtio-scsi.
> >
> > Then I virsh-define the VM from the template XML, perhaps effect further
> > changes in virt-manager (which are easiest to do there), and finally I
> > start the VM in the usual way.
> >
> > I need the wrapper script around qemu-kvm because I want to control
> > aspects of the VM that libvirt (in RHEL-6) doesn't enable me to, or not
> > in a way that I wanted to. And libvirt + wrapper script is way more
> > convenient than the raw qemu command line.
>
> Well. I did have your above post in my bookmark for a while, it's
> really useful reference for anyone who's getting start on testing
> OVMF, again thanks a lot for your great work and share. :)
>
> >
> >
> > Closing note... Even with Jordan's patch in place (or with Michael's,
> > makes no difference in this regard), the OS installer can *still* store
> > a wrong device path in the boot option (step 5) before the warm reboot
> > (step 6). So, even if
> > - this issue is fixed, and
> > - the reboot is warm too, and
> > - the installer media has been removed (or the qemu boot order lists it
> > as second),
> > the user may still not see an automatic reboot into the OS just
> > installed, if the device path is borked.
> >
> > ... This is exactly what happens with the RHEL-6 / Fedora(-19?)
> > installer, on virtio (-blk or -scsi) target disk :)
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=998611
>
> Weird, I use virtio-blk and boot from lvm volume, not seeing any
> problem so far.
>
> Thanks,
> Michael
>
> >
> > Thanks
> > Laszlo
> > .
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
