So that UEFI rescue mode test? I guess you never ran it? :)
At least in production, it fails for multiple reasons. Most obviously, it doesn't actually boot from the optical drive: with a UEFI VM, the installed system - probably the actual 'Fedora' UEFI boot manager entry, rather than fallback boot from the hard disk - takes priority and the VM boots that, not the optical drive.
I tried adding an explicit BOOTFROM=d. That causes os-autoinst to run qemu with -boot order=d, which per the docs should instruct qemu to boot from the optical drive, but it doesn't seem to work, it still prefers the Fedora entry, apparently. I suspect the docs don't really cover the OVMF firmware case.
BOOTFROM=d
-boot order=d
Looking at what libvirt does it seems not to use -boot order but rather the ability to specify a bootindex for each -device arg...here's an extract from the qemu command for a UEFI VM run by libvirt, for me:
-boot order
bootindex
-device
/usr/bin/qemu-system-x86_64 ... -boot strict=on ... -drive file=/share/data/isos/25/Beta/1.1/Fedora-Server-dvd-x86_64-25_Beta-1.1.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/share/data/isos/vms/test_uefi.qcow,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2
That command line does seem to result in the VM preferring the optical drive to the 'Fedora' UEFI boot manager entry at least on my system, but I'm not sure how safe that is, to be honest; I haven't looked fully into the details of how the qemu command line ties in with the VM's UEFI boot manager configuration, heck, even the details of exactly how qemu provides/emulates the flash where UEFI stores its configuration (it seems rather complicated and I'm not sure exactly how this winds up being handled in the os-autoinst design, and it may well vary depending on what versions of qemu and the OVMF firmware package you have installed).
I think to be confident of really fixing this properly we'd need to first grok better exactly how one can modify / override the boot order for OVMF UEFI VMs, and then send a patch upstream for os-autoinst to allow it to do that properly. But since you wanted to add the test, I'm gonna leave that to you. ;)
Once we actually get the test to boot from the optical drive reliably, there's a second problem, which is that typing 'r' to skip to the 'Rescue mode' boot menu entry does not work with grub (UEFI boot of the media uses grub, not syslinux). So we'd have to conditionalize that bit of the test:
diff --git a/tests/rescue_mode_encrypted.pm b/tests/rescue_mode_encrypted.pm index 8a1f80a..5db1e0d 100644 --- a/tests/rescue_mode_encrypted.pm +++ b/tests/rescue_mode_encrypted.pm @@ -9,7 +9,13 @@ sub run { send_key "down"; send_key "ret"; # select "rescue system" - type_string "r\n"; + if (get_var('UEFI')) { + send_key "down"; + send_key "ret"; + } + else { + type_string "r\n"; + } assert_screen "rescue_select", 120; # it takes time to start anaconda # continue
If you don't want to prioritize fixing this, we should take the test back out so it's not constantly false-failing every day.
This ticket had assigned some Differential requests: D1060
The uefi-rescue branch was my attempt to fix it with BOOTFROM, btw.
uefi-rescue
BOOTFROM
Yeah, it looks like that every time I don't test something (I have problems with UEFI virtualization on my laptop), it backfires :-). But hey, you've ACKed it ;-). I'll try to make this work, but it might take some time, so I'll revert my commit for now.
On related note, I tried to get to boot disk with UEFI created by virt-install, messed with configuration and now I get this:
{F86120}
every time I try to boot VM with UEFI. Have you ever encountered this problem?
EDIT: nevermind, I've set BIOS to /usr/share/edk2/ovmf/OVMF_CODE.fd which works.
/usr/share/edk2/ovmf/OVMF_CODE.fd
According to http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt it looks like bootindex=N should be preferred method for specifying boot device over "(legacy) '-boot order=drives' command line options", so I think that it should be safe.
bootindex=N
The thing that's not clear (to me) is exactly how OVMF uses (I guess? I don't know exactly how this stuff is handed off from the qemu args to the firmware, either) the bootindex values to populate the UEFI boot manager, particularly how it decides whether to give the boot manager entries for booting from drives priority over boot manager entries created by installed OSes.
wow, that's a long whitepaper. But the stuff under (d) Filtering and reordering the boot options based on fw_cfg seems interesting and suggests to me that devices passed in with a bootindex should wind up with higher priority in the boot manager than entries created by OS installation. Hope I'm reading it right...
(d) Filtering and reordering the boot options based on fw_cfg
Still, having read that I'm a bit surprised that BOOTFROM=d didn't work, actually. Oh, well. Good luck. :P
I don't know sh*t about innards of OVMF or how UEFI works, but from:
Once we have an "all-inclusive", partly preexistent, partly freshly auto-generated boot option list from bullet (b), OVMF loads QEMU's requested boot order from fw_cfg, and filters and reorders the list from (b) with it:
and
According to the (preferred) "-device ...,bootindex=N" and the (legacy) '-boot order=drives' command line options, QEMU requests a boot order from the firmware through the "bootorder" fw_cfg file. (For a bootindex example, refer to the "Example qemu invocation" section.)
it looks like it should work that way. Ahm, time for me to work.
here's an extract from the qemu command for a UEFI VM run by libvirt, for me: /usr/bin/qemu-system-x86_64 ... -boot strict=on ... -drive file=/share/data/isos/25/Beta/1.1/Fedora-Server-dvd-x86_64-25_Beta-1.1.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/share/data/isos/vms/test_uefi.qcow,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2
here's an extract from the qemu command for a UEFI VM run by libvirt, for me:
By the way, how did you obtain what commands libvirt uses @adamwill?
It's a long, complex and involved process:
ps -e | grep qemu
Too difficult to me, I will go back to old and easy online debugging with gdb and strace output exploring.
strace
I've created an issue on openQA's issue tracker https://github.com/os-autoinst/os-autoinst/issues/640 and possible solution here https://github.com/os-autoinst/os-autoinst/pull/641. It would be great if you'd tested OVMF's behaviour on your machine @adamwill.
This should be hopefully fixed now.
Login to comment on this ticket.