Fix OVMF location for openSUSE #2647
Conversation
pkg/qemu/qemu.go
Outdated
| @@ -1119,7 +1119,7 @@ func getFirmware(qemuExe string, arch limayaml.Arch) (string, error) { | |||
| // Fedora package "edk2-ovmf" | |||
| candidates = append(candidates, "/usr/share/edk2/ovmf/OVMF_CODE.fd") | |||
| // openSUSE package "qemu-ovmf-x86_64" | |||
| candidates = append(candidates, "/usr/share/qemu/ovmf-x86_64-code.bin") | |||
| candidates = append(candidates, "/usr/share/qemu/ovmf-x86_64-4m.bin") | |||
There was a problem hiding this comment.
What was the actual problem with code.bin?
There was a problem hiding this comment.
For consistency with other distros, can we just keep code and add vars ?
There was a problem hiding this comment.
It no longer loads the firmware at all. Please see the referenced Bugzilla entry for a repro case using just QEMU (without Lima).
There was a problem hiding this comment.
For consistency with other distros, can we just keep code and add vars ?
You want to add vars for all the distros?
There was a problem hiding this comment.
Was this a change in qemu, or where does the qemu-ovf upstream live? Looks like an old issue/bug was fixed...
There was a problem hiding this comment.
This seems like a lot of complexity. Why not use the unified firmaware on all platforms instead? What is the advantage of splitting it?
There was a problem hiding this comment.
Was this a change in qemu, or where does the qemu-ovf upstream live? Looks like an old issue/bug was fixed...
I believe the reason ovmf.bin can be split into ovmf-code.bin and ovmf-vars.bin is so that you can actually persist NV parameters for a virtual machine. It is supposed to be used like this
$ cp /usr/share/qemu/ovmf-x86_64-vars.bin .
$ qemu-system-x86_64 \
-drive if=pflash,format=raw,unit=0,readonly,file=/usr/share/qemu/ovmf-x86_64-code.bin \
-drive if=pflash,format=raw,unit=1,file=ovmf-x86_64-vars.binFor some reason there was a patch that did automatically reserve space for NV variables in the ovmf-code.bin software, so you could use the file by itself (of course changes to NV variables will not persist in this case). I have no idea how this patched CODE image would be different from the combined/unified image.
Now it seems like this patch is interfering with secure boot in some configurations, so has been removed from the openSUSE builds, and the CODE version no longer works unless you also mount the VARS image as well.
It is not clear to me why we don't use the unified image everywhere (beyond that we have to figure out if it is available on the distro, and what names are being used).
|
Small typo: The title should be OVMF, not OMVF. "Open Virtual Machine Firmware", I think it stands for? https://github.com/tianocore/tianocore.github.io/wiki/OVMF-FAQ |
jandubois
changed the title
|
Upstream is very light on details, they just say to use "OVMF.fd" https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF But that is another directory?
And it seems it is not built for the others: /usr/share/OVMF/OVMF_CODE.fd https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF |
I don't know what you mean, you just showed a list of files that all had both CODE and VARS variants. And the README shows that they are supposed to be used together: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README#L208-L209 Anyways, I'm fine with just using the unified version for openSUSE to fix the breakage. If the other distros distribute a version based on the fork with the patch, then we can leave them alone until/unless they switch as well in the future. I object to using the VARS file as well, as it will add a lot of complexity (we need to find the matching VARS file, and then make a copy so it can be mounted writable), but offers no benefit (we are not updating any NV variables). FWIW, I picked the |
The split firmware requires that both the CODE and the VARS parts are mounted. Otherwise the combined firmware should be used. This should apply to the other Linux distributions too, but I have not checked the filenames there. Ref: https://bugzilla.suse.com/show_bug.cgi?id=1230291#c5 Signed-off-by: Jan Dubois <jan.dubois@suse.com>
|
I meant that the docs showed how to use a file that did not exist (on all platforms), but the README did. The files were for Ubuntu, I forgot to mention that. It did have other variants too, like 4M or "snakeoil". |
Yeah, the naming is all over the place, but I think the basic idea is clear. Anyways, I think this PR is ready to be merged, as it switches to a firmware version that actually works on Tumbleweed. I don't care too much about the files for the other platforms; as long as they work without a VARS file, we can leave them as-is. But if they do require it, then I think we should switch them as well to the unified version instead of adding the complexity of adding a writable VARS volume. That is, unless we have a use-case to actually change NVs and persist their changes (instead of re-applying the changes on each boot). |
The split firmware requires that both the CODE and the VARS parts are mounted. Otherwise the combined firmware should be used.
This should apply to the other Linux distributions too, but I have not checked the filenames there.
Ref: https://bugzilla.suse.com/show_bug.cgi?id=1230291#c5