On 09/05/13 10:46, Michael Chang wrote: > On Thu, Sep 05, 2013 at 03:20:05AM +0200, Laszlo Ersek wrote: >> On 08/28/13 20:12, Laszlo Ersek wrote: >>> The prefix matching logic in Match() >>> [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options >>> to specify full (absolute) device paths. However, partial (relative) >>> device paths starting with a HD() node are valid for booting. By not >>> recognizing them, QemuBootOrder.c misses (and deletes) valid boot options >>> that would otherwise match the user's preference. >>> >>> Just like BdsLibBootViaBootOption() expands such paths with the >>> BdsExpandPartitionPartialDevicePathToFull() function for booting, do the >>> same in QemuBootOrder.c for prefix matching. >> >> Ping. >> >> (I tested it with RHEL-6/Fedora-19/Win2k8r2sp1 installers.) > > Hi Laszlo, > > I tested it and I'd say it works, but ... > > It seems to remove all enumerated devices from BootOrder which I'd > like to keep some of them. The resulting boot manager entries I have > is the one specified in qemu boot order .. > > opensuse > > Instead of > > opensuse > EFI DVD/CDROM > EFI FLOPPY > EFI FLOPPY1 > EFI NETWORK > EFI Internal Shell > > Those entries seem derived from BdsLibEnumerateAllBootOption(). I'm > not sure whether this is intended behavoir or something I was missing. > I really need the EFI Shell frequently and believe that many people > do, but don't know how to specify it as qemu boot order .. :(
This is not directly caused by this patch, it just exposes to you how QemuBootOrder works in general. I assume you either used not to specify bootindices at all (in which case QemuBootOrder doesn't touch the BootOrder variable), or you had no matches at all between the "bootorder" fw_cfg file and the enumerated / configured BootXXXX options. In this latter case QemuBootOrder doesn't touch BootOrder either. Now, this patch may have changed that for you -- you could now have a match between the "bootorder" fw_cfg file, and the now-expanded HD(...) devpath that the OpenSUSE installer generated with efibootmgr. So, yes, in this case QemuBootOrder kills off everything unmatched from the BootOrder variable. I had given some thought to this earlier, and it is a specification question. For now, "entry completely absent from the bootorder fw_cfg file" means "I don't want to boot from there -- otherwise I'd put it on the list". Unfortunately, stuff that is memory mapped from the flash device (like the EFI shell) is simply unexpressible via qemu bootindices -- and even if they were expressible, they still might not be representable as OpenFirmware device paths. I'm uncertain how to clean this up, from the design/spec side -- I guess I could add code to tack the EFI shell boot option to the end of BootOrder, *if* QemuBootOrder rewrites that variable. But it sounds quite ad-hoc, plus will everyone agree that it should be the last one? Thanks Laszlo ------------------------------------------------------------------------------ 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 edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
