From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuOdf-0004qp-47 for qemu-devel@nongnu.org; Tue, 10 Jun 2014 12:11:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuOda-0000Nf-8Y for qemu-devel@nongnu.org; Tue, 10 Jun 2014 12:11:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuOdZ-0000NV-Vv for qemu-devel@nongnu.org; Tue, 10 Jun 2014 12:11:02 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5AGB0mB028945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 10 Jun 2014 12:11:01 -0400 Date: Tue, 10 Jun 2014 21:40:48 +0530 From: Kashyap Chamarthy Message-ID: <20140610161048.GM8813@tesla> References: <20140610125650.GJ8813@tesla> <539721BD.8010700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539721BD.8010700@redhat.com> Subject: Re: [Qemu-devel] Booting a guest with OVMF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: pbonzini@redhat.com, Peter Jones , qemu-devel@nongnu.org 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 > , > 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 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