[Qemu-devel] Booting a guest with OVMF

[Qemu-devel] Booting a guest with OVMF

[Kashyap Chamarthy]

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

-- 
/kashyap

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

[Laszlo Ersek]

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

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

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

[Laszlo Ersek]

On 06/10/14 18:10, Kashyap Chamarthy wrote:
> 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.

That script is exactly what I don't want to run :) Can you upload the
result somewhere?

> This is disk image #3:
> 
>     http://download.fedoraproject.org/pub/fedora/linux/updates/20/Images/x86_64/Fedora-x86_64-20-20140407-sda.qcow2

OK, I'll try to check this out.

Thanks
Laszlo

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

[Kashyap Chamarthy]

On Tue, Jun 10, 2014 at 06:26:50PM +0200, Laszlo Ersek wrote:
> On 06/10/14 18:10, Kashyap Chamarthy wrote:

[. . .]

> > 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.
> 
> That script is exactly what I don't want to run :) Can you upload the
> result somewhere?

Yes, I can, but will have to wait till tomorrow -- the contents of the
script came down to 1.6G after trying to make an ISO as below.

    $ sudo dd bs=1k if=/dev/sdb2 of=fed-min2.iso conv=sparse

(Thanks to Rich W. Jones for the 'sparse' option tip).

> > This is disk image #3:
> > 
> >     http://download.fedoraproject.org/pub/fedora/linux/updates/20/Images/x86_64/Fedora-x86_64-20-20140407-sda.qcow2
> 
> OK, I'll try to check this out.
> 
> Thanks
> Laszlo

-- 
/kashyap

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

[Laszlo Ersek]

On 06/10/14 19:16, Kashyap Chamarthy wrote:
> On Tue, Jun 10, 2014 at 06:26:50PM +0200, Laszlo Ersek wrote:
>> On 06/10/14 18:10, Kashyap Chamarthy wrote:
> 
> [. . .]
> 
>>> 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.
>>
>> That script is exactly what I don't want to run :) Can you upload the
>> result somewhere?
> 
> Yes, I can, but will have to wait till tomorrow -- the contents of the
> script came down to 1.6G after trying to make an ISO as below.
> 
>     $ sudo dd bs=1k if=/dev/sdb2 of=fed-min2.iso conv=sparse

(1) I think you should just format the disk image into a regular file,
rather than dumping it to a USB stick, and then dumping it back from there.

(2) Even if you opt for the USB "detour", the above dd command line is
incorrect. You selected a specific partition on the USB stick as input
block device. That's wrong, we need to see the entire disk (partition
table, EFI system partition etc).

Thanks
Laszlo

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

[Kashyap Chamarthy]

On Tue, Jun 10, 2014 at 07:30:58PM +0200, Laszlo Ersek wrote:
> On 06/10/14 19:16, Kashyap Chamarthy wrote:

[. . .]

> > 
> > Yes, I can, but will have to wait till tomorrow -- the contents of the
> > script came down to 1.6G after trying to make an ISO as below.
> > 
> >     $ sudo dd bs=1k if=/dev/sdb2 of=fed-min2.iso conv=sparse
> 
> (1) I think you should just format the disk image into a regular file,
> rather than dumping it to a USB stick, 

Assuming I'm reading you correctly, the above script writes the OS
content directly to USB stick, I didn't dump to it from a disk image
file.

> and then dumping it back from there.
> 
> (2) Even if you opt for the USB "detour", the above dd command line is
> incorrect. You selected a specific partition on the USB stick as input
> block device. That's wrong, we need to see the entire disk (partition
> table, EFI system partition etc).

You're right (sdb1 has "EFI System"):

    $ sudo fdisk -l /dev/sdb
    
    Disk /dev/sdb: 3.7 GiB, 4004511744 bytes, 7821312 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Disk identifier: C6CEC927-FA8F-4958-A223-A7BCE283241E
    
    Device           Start          End   Size Type
    /dev/sdb1         2048      1046527   510M EFI System
    /dev/sdb2      1048576      7819263   3.2G unknown


I'll do a redump of /dev/sdb as below:

    $ sudo dd bs=1k if=/dev/sdb of=fed-min.iso conv=sparse

Thanks for pointing that out.

-- 
/kashyap

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

[Laszlo Ersek]

On 06/10/14 18:10, Kashyap Chamarthy wrote:

> This is disk image #3:
> 
>     http://download.fedoraproject.org/pub/fedora/linux/updates/20/Images/x86_64/Fedora-x86_64-20-20140407-sda.qcow2

As I suspected, this disk image is inapproprite for UEFI virtual machines.

$ guestfish --ro -a Fedora-x86_64-20-20140407-sda.qcow2
><fs> launch
><fs> list-filesystems
/dev/sda1: ext4

It has no EFI system partition.

The image must have been prepared for BIOS machines. (For VMs that
implies SeaBIOS, not OVMF.)

-o-

For cases #1 and #2, I looked into
<http://people.freedesktop.org/~kay/installer/installer.sh>. It
- formats an EFI system partition as FAT32 alright,
- mounts it as "/run/installer-$ROOT/system/boot",
- does some other stuff,
- and then executes

  chroot /run/installer-$ROOT/system/ gummiboot install --no-variables

I assume something goes wrong in this step (ie. the ESP won't contain
any gummiboot binary under EFI/BOOT/BOOTX64.EFI).

"install.sh" seems to support formatting regular files -- that should
allow you to both upload one for inspection (eg. with guestfish, see
above), and also to test it with qemu (without needing a USB stick).

Thanks
Laszlo

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

[Laszlo Ersek]

Alright, so we've already dealt with case #3 (--> the disk image was not
appropriate for a UEFI VM); let's see cases #1 and #2 (I downloaded and
tested the gummiboot rawhide image that you gave me).

What I did as preparation was:
- I converted the raw image to qcow2:

  qemu-img convert -p -f raw -O qcow2 \
      fedora-rawhide.iso fedora-rawhide.qcow2

- then I created an overlay so that the original never be modified:

  qemu-img create -f qcow2 -o backing_file=fedora-rawhide.qcow2 \
      overlay.qcow2

And I tested with "overlay.qcow2" (rather than /dev/sdb), always
recreating it from scratch before a test.

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)

So, this "just works (TM)" for me too, same as for you.

> 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

This happens because the image is incorrectly built. One "trick" that
you should always use is the following two options:

  -debugcon file:debug.log \
  -global isa-debugcon.iobase=0x402

(This is documented in the OVMF README.)

This will place the debug console at guest ioport 0x402, and redirect it
to the debug.log host-side file. OVMF writes a pretty verbose log to
that port.

Looking at that log, it's clear that gummiboot is actually started:

[...]
Booting EFI Floppy
PlatformBdsBootFail
[...]
Booting EFI Floppy 1
PlatformBdsBootFail
[...]
Booting EFI Hard Drive
[...]

The first two floppy boot failures are also displayed on serial (that's
what you quoted).

No hard disk boot failure is logged to serial because that boot actually
succeeds.

So, the question is, why don't you see anything on serial then? Well
because in the image file neither gummiboot nor the kernel are
configured to care about serial at all. And, in case #2, you have no VGA
etc; only a serial line.

Try this:
- boot the image like in case #1 (== normal VGA),
- log in, and navigate to /boot/loader/entries/
- edit the gummiboot conf file you find there,
- append "console=tty console=ttyS0" to the "options" line
- shut down the guest cleanly (shutdown -h now)
- start the guest again, like in case #2 (== headless).
- You should get a login prompt on serial. (I do.)

Thanks
Laszlo

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

[Kashyap Chamarthy]

On Wed, Jun 11, 2014 at 06:35:43PM +0200, Laszlo Ersek wrote:
> Alright, so we've already dealt with case #3 (--> the disk image was not
> appropriate for a UEFI VM); let's see cases #1 and #2 (I downloaded and
> tested the gummiboot rawhide image that you gave me).
> 
> What I did as preparation was:
> - I converted the raw image to qcow2:
> 
>   qemu-img convert -p -f raw -O qcow2 \
>       fedora-rawhide.iso fedora-rawhide.qcow2
> 
> - then I created an overlay so that the original never be modified:
> 
>   qemu-img create -f qcow2 -o backing_file=fedora-rawhide.qcow2 \
>       overlay.qcow2
> 
> And I tested with "overlay.qcow2" (rather than /dev/sdb), always
> recreating it from scratch before a test.
> 
> 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)
> 
> So, this "just works (TM)" for me too, same as for you.
> 
> > 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
> 
> This happens because the image is incorrectly built. One "trick" that
> you should always use is the following two options:
> 
>   -debugcon file:debug.log \
>   -global isa-debugcon.iobase=0x402
> 
> (This is documented in the OVMF README.)
> 
> This will place the debug console at guest ioport 0x402, and redirect it
> to the debug.log host-side file. OVMF writes a pretty verbose log to
> that port.
> 
> Looking at that log, it's clear that gummiboot is actually started:
> 
> [...]
> Booting EFI Floppy
> PlatformBdsBootFail
> [...]
> Booting EFI Floppy 1
> PlatformBdsBootFail
> [...]
> Booting EFI Hard Drive
> [...]
> 
> The first two floppy boot failures are also displayed on serial (that's
> what you quoted).
> 
> No hard disk boot failure is logged to serial because that boot actually
> succeeds.
> 
> So, the question is, why don't you see anything on serial then? Well
> because in the image file neither gummiboot nor the kernel are
> configured to care about serial at all. 

Ah, right, I should have noticed that. I usually have the serial console
attribute (console=tty0 console=ttyS0,115200) by default in all my
Kickstart-based installs, so I missed it in this setup. Thanks.

> And, in case #2, you have no VGA
> etc; only a serial line.

> 
> Try this:
> - boot the image like in case #1 (== normal VGA),
> - log in, and navigate to /boot/loader/entries/
> - edit the gummiboot conf file you find there,
> - append "console=tty console=ttyS0" to the "options" line
> - shut down the guest cleanly (shutdown -h now)
> - start the guest again, like in case #2 (== headless).
> - You should get a login prompt on serial. (I do.)

This, of course, works.

Thanks Laszlo.

-- 
/kashyap