Re: [Qemu-devel] Booting a guest with OVMF

[Kashyap Chamarthy]

On Tue, Jun 10, 2014 at 05:18:21PM +0200, Laszlo Ersek wrote:
> On 06/10/14 15:04, Kashyap Chamarthy wrote:
> > Heya,
> >
> > Laszlo pointed out OVMF packages for Fedora from here[1]. I tried a
> > simple test using this[2] by installing Fedora onto a USB stick.
> >
> > Once Fedora is installed on the USB stick (/dev/sdb), and I attempt to
> > boot into the USB device as below, I get the Fedora serial console
> > login prompt just fine through a QEMU vnc display:
> >
> >     $ sudo qemu-system-x86_64 -machine accel=kvm -m 256 -bios \
> >       /usr/share/OVMF/OVMFX64.fd  /dev/sdb)
> >
> >
> > However, when I try with the below QEMU invocation, I get "Boot
> > Failed. EFI Floppy":
> >
> >     $ sudo qemu-system-x86_64 -machine accel=kvm -m 512 -nographic \
> >       -nodefconfig -nodefaults  -serial stdio \
> >       -bios /usr/share/OVMF/OVMFX64.fd /dev/sdb
> >     Boot Failed. EFI Floppy
> >     Boot Failed. EFI Floppy 1
> >
> >
> > Next, I tried booting into a Fedora disk image with the below QEMU
> > invocation, and I get a UEFI interactive shell as below (after "Boot
> > Failed. EFI Floppy"):
> >
> >     $ sudo qemu-system-x86_64 -machine accel=kvm -m 512 -nographic \
> >       -nodefconfig -nodefaults  -serial stdio -bios 
> > /usr/share/OVMF/OVMFX64.fd \
> >       -drive 
> > file=/var/lib/libvirt/images/Fedora-x86_64-20-20140407-sda.qcow2,if=ide,format=qcow2,cache=none
> >     UEFI Interactive Shell v2.0
> >     EDK II
> >     UEFI v2.40 (EDK II, 0x00010000)
> >     Mapping table
> >          BLK2: Alias(s):
> >               PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
> >          BLK3: Alias(s):
> >               
> > PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0x00014C24,0x7A1,0x3FF83D)
> >          BLK0: Alias(s):
> >               PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
> >          BLK1: Alias(s):
> >               PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
> >
> >     Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
> >     Shell>
> >
> >
> > Is this expected behavior?
> >
> >
> >   [1] 
> > http://copr-be.cloud.fedoraproject.org/results/bonzini/ovmf/fedora-20-x86_64/edk2-20140328svn15376-4.fc20/
> >   [2] http://people.freedesktop.org/~kay/installer/README
> >
> 
> Document [2] seems to imply that the disk image you write out to the USB
> stick is a preinstalled (fixed media) Fedora system. 

The USB stick is created with Fedora Rawhide image using this
script: http://people.freedesktop.org/~kay/installer/installer.sh

    $ sudo ./installer.sh /dev/sdb

Then, invoke QEMU.

> When you start that
> first, you have no UEFI boot option for it, so the Fedora fallback
> mechanism is activated
> <http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>,
> which recreates the boot option for it.
> 
> In your case, since you use "-bios" -- rather than "-pflash" with a
> per-VM writeable copy of OVMF.fd -- the boot options are stored (faked)
> in a binary file on your EFI system partition (on your USB stick). This
> is not optimal, but doesn't immediately explain while case #2 and case
> #3 don't work.
> 
> I need to know the following:
> 
> (a) If you ran cases #1, #2, #3 consecutively using the same USB stick /
> disk image, 

This is the case - I ran all the above three QEMU invocations
consecutively using the same USB stick.

> or if you ran each test with a pristine disk image. This can
> be important because case #1 (the fallback mechanism) modifies UEFI boot
> options, which (in your case) are stored in the disk image itself.

If desired, tomorrow morning (I'll be on a better internet connection) I
can try each of the above QEMU invocations with a pristine install of
Fedora Rawhide onto the USB disk.

> (Note that you should really use "-pflash" instead of "-bios", and
> create a per-VM private, writeable copy of OVMF.fd for -pflash.)

Hmm, I just tried w/ "-pflash" on the existing USB stick (_without_
re-installing Fedora on it):

    $ sudo qemu-system-x86_64 -machine accel=kvm -m 512 -nographic \
    -nodefconfig -nodefaults  -serial stdio -pflash \
    /usr/share/OVMF/OVMFX64.fd /dev/sdb

And, also on a Fedora-20 disk image (same image as in the third
invocation from my original email; this is a properly created disk image
via kickstart).

In both the above trials, still the UEFI shell is thrown.

> (b) The URLs of the exact disk images you use in #1/#2 and in #3.

This is the script I used to create the USB disk image in #1 and #2
(directions in README) -
http://people.freedesktop.org/~kay/installer/installer.sh

This is disk image #3:

    
http://download.fedoraproject.org/pub/fedora/linux/updates/20/Images/x86_64/Fedora-x86_64-20-20140407-sda.qcow2
 
> (I assume that #1 and #2 use the same disk image, and #3 uses a
> different one).

Yes.

> 
> In general, OVMF reorders UEFI boot options based on qemu's boot order
> specification. The -nodefaults cmdline option (without further
> explicit cmdline options) might have a bad effect on that. I always
> use OVMF with libvirt (plus a small wrapper script around qemu) --
> libvirt always passes -nodefaults, but it also specifies everything
> else explicitly.
> 
> FWIW, I tried to reproduce your case #3 as follows, and it works for
> me: - I grabbed one of my preexistent OVMF guests (Fedora 20).  - I
> created a qcow2 overlay (so that nothing gets written back to my
> "normal" disk image):
> 
>   qemu-img create -f qcow2 -o backing_file=ovmf.f20.zimg overlay.qcow2
> 
> - Started qemu as follows (RHEL-7), using my recently built OVMF:
> 
>   /usr/libexec/qemu-kvm -machine accel=kvm -m 512 -nographic \
>   -nodefconfig -nodefaults  -serial stdio \ -bios
>   /home/virt-images/OVMF.fd \ -drive
>   file=/home/virt-images/overlay.qcow2,if=ide,format=qcow2
> 
> It boots to grub2 correctly:
> 
>   Boot Failed. EFI Floppy Boot Failed. EFI Floppy 1 Booting in
>   insecure mode System BootOrder not found.  Initializing defaults.
>   device path:
>   
> "Acpi(PNP0A03,0)/Pci(1|1)/Ata(Primary,Master)/HD(Part1,Sig14DD1CC5-D576-4BBF-8858-BAF877C8DF61)/\EFI\fedora\shim.efi"
>   Creating boot entry "Boot0004" with label "Fedora" for file
>   "\EFI\fedora\shim.efi" Booting in insecure mode <grub2 menu appears>

Thanks for testing.

If you have time, can you also please confirm it works for you with the
above Fedora-20 cloud image? That way, at-least in one test, we're both
using the same disk image.
 
> You can witness fallback.efi work above.
> 
> My take (without having seen your disk images) is that either your
> disk images are FUBAR, or there's something wrong with your OVMF
> firmware.  TBH I doubt the latter, I checked the OVMF commits since
> SVN r15376 (which you use), and nothing seems to justify this
> difference. So I think there's a problem with your disk images.

Let's see if my above information gives you any new clues.

Thanks for your detailed response, Laszlo.

-- 
/kashyap