Add automatic lookup for UEFI_PFLASH_CODE/VARS to fix UEFI on Tumbleweed machines #1190
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1190 +/- ##
==========================================
+ Coverage 40.01% 40.33% +0.31%
==========================================
Files 40 40
Lines 4868 4867 -1
Branches 828 827 -1
==========================================
+ Hits 1948 1963 +15
+ Misses 2588 2578 -10
+ Partials 332 326 -6
Continue to review full report at Codecov.
|
…eed machines This allows to simply set UEFI=1 and neither BIOS nor UEFI_PFLASH which will lookup corresponding "code" and "vars" firmware files instead of failing. The firmware files used by Fedora and Debian were already referencing "code" files as single pflash targets so we do the same for the openSUSE package which by now in openSUSE Factory does not supply the single code+vars image anymore. Currently os-autoinst-distri-opensuse sets UEFI_PFLASH which is still supported from os-autoinst but will not work if the worker is a more recent openSUSE Tumbleweed. Simply not specifying the variable will fix that problem as soon as this commit is in. Tested locally with a vars.json file in three variants, with UEFI_PFLASH resolving the single code+vars file as well as without UEFI_PFLASH and no explicit path to neither BIOS nor UEFI_FPLASH_CODE so that the firmware file is automatically looked up. The third variant is to explicitly specify either code or vars file which still works. Related progress issue: https://progress.opensuse.org/issues/55052
okurz
force-pushed
the
fix/uefi_for_new_ovmf
branch
from
ed3bcdb
to
6e42b19
Compare
|
LGTM |
|
I will look into tests in a separate PR because this would be something to discuss first. |
|
ten points to anyone who can remember the entire sequence of how we got to where we are right now with all of this stuff...:P |
|
@AdamWill uhhh, … do you mean I overlooked something? I tried to dig deep in the git logs to understand how we got there but I have not experienced the full history personally :) |
|
Because of this change and the test suits not being adapted stuff is broken on osd |
|
@DrMullings the job you mentioned has hardcoded code+vars path but also UEFI_PFLASH. I did not know that this worked even in before but it shouldn't. Anyway, when you rebase your test code on latest master the variable |
|
@okurz UEFI_PFLASH is being set in the test suite, we just checked that |
|
@okurz I can't think of something specific, but we have changed this thing so damn often it's hard to be sure everything anyone does is gonna work (see @DrMullings issue for e.g.). "Just set I've already found weird gremlins in this stuff before, like at one point at least if you set a particular combination of variables the test would execute as a UEFI test, but the variable |
|
yes, true. This motivated me to at least start a test for "backend/qemu.pm" with #1191 . If people like it then I hope we can extend that one |
This allows to simply set UEFI=1 and neither BIOS nor UEFI_PFLASH which will
lookup corresponding "code" and "vars" firmware files instead of failing.
The firmware files used by Fedora and Debian were already referencing "code"
files as single pflash targets so we do the same for the openSUSE package
which by now in openSUSE Factory does not supply the single code+vars image
anymore.
Currently os-autoinst-distri-opensuse sets UEFI_PFLASH which is still
supported from os-autoinst but will not work if the worker is a more recent
openSUSE Tumbleweed. Simply not specifying the variable will fix that problem
as soon as this commit is in.
Tested locally with a vars.json file in three variants, with UEFI_PFLASH
resolving the single code+vars file as well as without UEFI_PFLASH and no
explicit path to neither BIOS nor UEFI_FPLASH_CODE so that the firmware file
is automatically looked up. The third variant is to explicitly specify either
code or vars file which still works.
Related progress issue: https://progress.opensuse.org/issues/55052