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
