UEFI installations needs to be on disks with gpt. But openqa now uses disks with mbr for all tests. So in tests where the disk isn't reformated (e. g. delete partial) the uefi installation fails. There are two solution for this: Use disks with gpt for all tests. Non-uefi tests works with gpt so everything should work. But there is some probability that we would missed problems with mbr handling. I'm not sure if it happens. I will discuss this with anaconda guys. Create new disks with gpt and new tests which uses them - this would bring few new tests (or if it makes sense, we could use it in all partitioning testcases), but we wouldn't lose testing of mbr. Which solution will be used depends on what anaconda guys will tell me.
This ticket is a duplicate of https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/22
This ticket had assigned some Differential requests: D624 D623
"Use disks with gpt for all tests. Non-uefi tests works with gpt so everything should work."
I would not recommend doing this. We want to be testing the default/common case, and the default/common case for BIOS installs is MBR disks. We tried to make GPT the default for BIOS installs for one release and it was a train wreck.
A single test for 'BIOS install to a GPT disk' would actually be a valuable thing to have, but we should not have the 'normal' tests using GPT disks for BIOS installs.
However, I don't like the second idea much either. This feels to me like a limitation of openQA, and we should perhaps investigate fixing it upstream: somehow making it possible to vary what HDD a run uses based on some settings. I've no idea how viable this is, but it's worth looking at.
I'm with Adam. Another possibility (we've been discussing this with @pschindl) is to have separate machines with proper disks attached. We would define HDD_$ variable per machine rather than per test where required. We would then schedule empty_all test on different machine than upgrade tests.
HDD_$
Cleanest solution is to "fix" this somehow in upstream, but then again, how would it be implemented? Only thing I can think of is to somehow define string to substitute in HDD_$ variable.
I did look at this briefly and I think it's theoretically possible to allow for this in upstream, it's not even very hard; but it's a question of coming up with a concept and whether upstream would want it. To put it briefly, I think every job execution in openQA runs through here:
https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/Worker/Jobs.pm#L317
and thus here:
https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/Worker/Engines/isotovideo.pm#L67
at which point all the variables are set. So it would be theoretically fairly simple to add some kind of substitution code there; it's just a case of deciding what the rules would be.
My first rough thought looked something like this: you can include in any setting's value any number of ${SETTING} strings (where SETTING is any setting). When the substitutions run, if the setting is set to 1, the string is replaced with the name of the setting. If the setting is not set at all (or set to 0?), the string is simply removed. If the setting is set to anything else, the string is replaced with the value of the setting. Possibly when substituting we'd want it to pad with - just for readability. So if we set HDD_1 to disk_full${UEFI}.img, for instance, when running a UEFI test it'd be changed to disk_full-UEFI.img, when not running a UEFI test it'd be changed to disk_full.img.
${SETTING}
-
HDD_1
disk_full${UEFI}.img
disk_full-UEFI.img
disk_full.img
The question is whether when you step back and look at it overall this is actually a really sensible design, or whether there's some better way to approach it, I guess. I'll ask upstream what they think - maybe there's already something for this and we just don't know it?
upstream tells me they implemented something very like my suggestion just a few days ago:
https://github.com/os-autoinst/openQA/pull/432/files
it doesn't have the wrinkle with 0 and 1s, but they suggested using the MACHINE setting instead of the UEFI setting, which might be good enough, we'll have to look.
MACHINE
UEFI
So now BOS is running a recent openQA, the stuff I linked in the previous comment should be available for us to use.
Upstream folks told me they just use MACHINE for this, but I guess adding another variable isn't too bad either...
Login to comment on this ticket.