* Re: [Qemu-devel] QEMU + OVMF, bootable linux image
2017-02-03 18:20 [Qemu-devel] QEMU + OVMF, bootable linux image Jason Dickens
@ 2017-02-03 21:00 ` Laszlo Ersek
0 siblings, 0 replies; 2+ messages in thread
From: Laszlo Ersek @ 2017-02-03 21:00 UTC (permalink / raw)
To: Jason Dickens, qemu-devel
On 02/03/17 19:20, Jason Dickens wrote:
> I am trying to create a raw Linux image that is bootable by QEMU using
> the OVMF firmware image.
>
> Basically, I have used a standard Ubuntu ISO and a empty raw image.
> Executing qemu-system-x86_64 with the ISO as CD and the other image as a
> hardrive I have been able to install Ubuntu on the image, no problem.
>
> However, when trying to boot the created image I simply get the UEFI shell?
>
> I've noticed the following:
>
> 1. The ISO image which boots with OVMF in UEFI just fine has the
> following format (from fdisk):
>
> Disk ubuntu-14.04.3-desktop-amd64.iso: 1006 MiB, 1054867456 bytes,
> 2060288 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: dos
> Disk identifier: 0x6a6216fc
>
> Device Boot Start End Sectors Size Id Type
> ubuntu-14.04.3-desktop-amd64.iso1 * 0 2060287 2060288 1006M 0
> Empty
> ubuntu-14.04.3-desktop-amd64.iso2 2038760 2043303 4544 2.2M ef EFI
> (FAT-12/16/32)
>
> 2. The image created by the linux install has the following(from fdisk):
>
> Disk ovmf_test_image: 10 GiB, 10737418240 bytes, 20971520 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: 36240C48-C008-4619-BE31-26D271000490
>
> Device Start End Sectors Size Type
> ovmf_test_image1 2048 1050623 1048576 512M EFI System
> ovmf_test_image2 1050624 12584959 11534336 5.5G Linux filesystem
> ovmf_test_image3 12584960 20969471 8384512 4G Linux swap
>
>
> Can someone help me understand the format requirements to boot using
> OVMF in UEFI mode? Clearly these two images are dramatically different.
> However, I would expect #2 to be the more modern method and more likely
> to work? As for QEMU command I use literally the same command switching
> only between the file names to get the different results it looks
> something like this:
>
> qemu-system-x86_64 -drive file=ovmf_test_image,format=raw -m 4G
> --bios.bin -net none
"something like this" is quite likely where the bug is.
I downloaded "ubuntu-14.04.3-desktop-amd64.iso". I also have Gerd's
build of OVMF installed. The RPM is called "edk2.git-ovmf-x64", and the
repository is at <http://www.kraxel.org/repos/> (see the instructions
there). Before running the test, I upgraded the package to
"20170126.b2442.gf1d91f3".
The following script works flawlessly for me. You can use the same
script both for installation and then to boot the installed guest.
------------------------
ISO=ubuntu-14.04.3-desktop-amd64.iso
IMG=ubuntu-14.04.3-desktop-amd64.img
VARS=ubuntu-14.04.3-desktop-amd64.vars
DBG=ubuntu-14.04.3-desktop-amd64.dbg
CODE=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
TMPL=/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
if ! [ -e "$VARS" ]; then
cp $TMPL "$VARS"
fi
if ! [ -e "$IMG" ]; then
qemu-img create -f raw "$IMG" 20G
fi
qemu-system-x86_64 \
\
-machine accel=kvm \
-m 4096 \
\
-drive if=pflash,readonly,format=raw,file=$CODE \
-drive if=pflash,format=raw,file="$VARS" \
\
-drive id=disk,if=none,format=raw,file=$IMG \
-drive id=cdrom,if=none,readonly,format=raw,file=$ISO \
\
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,bus=scsi0.0,drive=disk,bootindex=0 \
-device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=1 \
\
-chardev file,id=debug,path="$DBG" \
-device isa-debugcon,iobase=0x402,chardev=debug
------------------------
If you wish, after installation (and powering off the guest), you can
simply drop the two lines from the script that contain the word "cdrom";
the guest will remain bootable just the same.
In general, I strongly suggest using libvirt. The QEMU command line is
too complex if you don't know exactly what you are doing.
(I'm not being arrogant: the vast majority of the QEMU command line
options freak me out, so I insist on using libvirt even for my own
development purposes.)
HTH,
Laszlo
^ permalink raw reply [flat|nested] 2+ messages in thread