[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Booting a guest with OVMF
From: |
Kashyap Chamarthy |
Subject: |
Re: [Qemu-devel] Booting a guest with OVMF |
Date: |
Tue, 10 Jun 2014 21:40:48 +0530 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
Re: [Qemu-devel] Booting a guest with OVMF, Laszlo Ersek, 2014/06/11