* [Qemu-devel] Booting a guest with OVMF @ 2014-06-10 13:04 Kashyap Chamarthy 2014-06-10 15:18 ` Laszlo Ersek 2014-06-11 16:35 ` Laszlo Ersek 0 siblings, 2 replies; 10+ messages in thread From: Kashyap Chamarthy @ 2014-06-10 13:04 UTC (permalink / raw) To: pbonzini, lersek; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 13:04 [Qemu-devel] Booting a guest with OVMF Kashyap Chamarthy @ 2014-06-10 15:18 ` Laszlo Ersek 2014-06-10 16:10 ` Kashyap Chamarthy 2014-06-11 16:35 ` Laszlo Ersek 1 sibling, 1 reply; 10+ messages in thread From: Laszlo Ersek @ 2014-06-10 15:18 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 15:18 ` Laszlo Ersek @ 2014-06-10 16:10 ` Kashyap Chamarthy 2014-06-10 16:26 ` Laszlo Ersek 2014-06-10 17:26 ` Laszlo Ersek 0 siblings, 2 replies; 10+ messages in thread From: Kashyap Chamarthy @ 2014-06-10 16:10 UTC (permalink / raw) To: Laszlo Ersek; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 16:10 ` Kashyap Chamarthy @ 2014-06-10 16:26 ` Laszlo Ersek 2014-06-10 17:16 ` Kashyap Chamarthy 2014-06-10 17:26 ` Laszlo Ersek 1 sibling, 1 reply; 10+ messages in thread From: Laszlo Ersek @ 2014-06-10 16:26 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 16:26 ` Laszlo Ersek @ 2014-06-10 17:16 ` Kashyap Chamarthy 2014-06-10 17:30 ` Laszlo Ersek 0 siblings, 1 reply; 10+ messages in thread From: Kashyap Chamarthy @ 2014-06-10 17:16 UTC (permalink / raw) To: Laszlo Ersek; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 17:16 ` Kashyap Chamarthy @ 2014-06-10 17:30 ` Laszlo Ersek 2014-06-10 18:03 ` Kashyap Chamarthy 0 siblings, 1 reply; 10+ messages in thread From: Laszlo Ersek @ 2014-06-10 17:30 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 17:30 ` Laszlo Ersek @ 2014-06-10 18:03 ` Kashyap Chamarthy 0 siblings, 0 replies; 10+ messages in thread From: Kashyap Chamarthy @ 2014-06-10 18:03 UTC (permalink / raw) To: Laszlo Ersek; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 16:10 ` Kashyap Chamarthy 2014-06-10 16:26 ` Laszlo Ersek @ 2014-06-10 17:26 ` Laszlo Ersek 1 sibling, 0 replies; 10+ messages in thread From: Laszlo Ersek @ 2014-06-10 17:26 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: pbonzini, Peter Jones, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-10 13:04 [Qemu-devel] Booting a guest with OVMF Kashyap Chamarthy 2014-06-10 15:18 ` Laszlo Ersek @ 2014-06-11 16:35 ` Laszlo Ersek 2014-06-11 18:11 ` Kashyap Chamarthy 1 sibling, 1 reply; 10+ messages in thread From: Laszlo Ersek @ 2014-06-11 16:35 UTC (permalink / raw) To: Kashyap Chamarthy, pbonzini; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Booting a guest with OVMF 2014-06-11 16:35 ` Laszlo Ersek @ 2014-06-11 18:11 ` Kashyap Chamarthy 0 siblings, 0 replies; 10+ messages in thread From: Kashyap Chamarthy @ 2014-06-11 18:11 UTC (permalink / raw) To: Laszlo Ersek; +Cc: pbonzini, qemu-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-06-11 18:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-10 13:04 [Qemu-devel] Booting a guest with OVMF Kashyap Chamarthy 2014-06-10 15:18 ` Laszlo Ersek 2014-06-10 16:10 ` Kashyap Chamarthy 2014-06-10 16:26 ` Laszlo Ersek 2014-06-10 17:16 ` Kashyap Chamarthy 2014-06-10 17:30 ` Laszlo Ersek 2014-06-10 18:03 ` Kashyap Chamarthy 2014-06-10 17:26 ` Laszlo Ersek 2014-06-11 16:35 ` Laszlo Ersek 2014-06-11 18:11 ` Kashyap Chamarthy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.