lima-vm / lima

Linux virtual machines, with a focus on running containers
https://lima-vm.io/
Apache License 2.0
15.07k stars 591 forks source link

Fix OVMF location for openSUSE #2647

Closed jandubois closed 2 hours ago

jandubois commented 5 days ago

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

afbjorklund commented 5 days ago

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

afbjorklund commented 5 days ago

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?

/usr/share/ovmf/OVMF.fd


And it seems it is not built for the others:

/usr/share/OVMF/OVMF_CODE.fd /usr/share/OVMF/OVMF_VARS.fd /usr/share/AAVMF/AAVMF32_CODE.fd /usr/share/AAVMF/AAVMF32_VARS.fd /usr/share/AAVMF/AAVMF_CODE.fd /usr/share/AAVMF/AAVMF_VARS.fd

https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF

jandubois commented 5 days ago

And it seems it is not built for the others:

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

  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \

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 4m purely because it was used by another file already; I believe the large NV area is only used for some Windows configurations and not really needed for Linux guests. So I will update this PR to pick the regular (2M) firmware.

afbjorklund commented 5 days ago

I meant that the docs showed how to use a file that did not exist (on all platforms), but the README did.

https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF#optional-point-directly-to-uefi-firmware-in-edk2build-directory

The files were for Ubuntu, I forgot to mention that.

It did have other variants too, like 4M or "snakeoil".

jandubois commented 5 days ago

I meant that the docs showed how to use a file that did not exist (on all platforms), but the README did.

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).