qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] Booting a guest with OVMF
Date: Tue, 10 Jun 2014 17:18:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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. 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, 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.

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

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

(I assume that #1 and #2 use the same disk image, and #3 uses a
different one).

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>

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.

Thanks
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]