OVMF_VARS.fd and OVMF_CODE.fd are split files. OVMF.fd is a unified file. Concatenating the first two yields the third.
OVMF_VARS.fd is a variable store template. OVMF_CODE.fd is the fimrware executable. When you create a new VM, libvirt instantiates the VM's own, private variable store by copying OVMF_VARS.fd. And, all VMs share the OVMF_CODE.fd binary. When you update the OVMF package, the varstore template and the executable are both replaced, but the VMs preserve their own, private variable stores. This was the reason for implementing the split files -- so that the firmware be possible to update centrally on a host, but the VMs' varstores remain unaffected. (If you use a unified file, then the varstore part of that file is not a template, but a live variable store, and if you replace the entire file, then the VM loses its variables. In addition, each VM would have a separate copy of the executable part as well, which would require touching each VM's copy when updating the firmware on a host system, to get a central update.) Regarding the place of OVMF_VARS.fd and OVMF_CODE.fd in the filesystem -- you put them wherever you want in Debian I guess, but they *really* correspond to each other. For example, a Secure Boot enabled OVMF_CODE.fd will not work with varstores copied from an OVMF_VARS.fd that was the output of a Secure Boot disabled build. IOW, OVMF_VARS.fd is not a config file for the user to update, it's really the counterpart of OVMF_CODE.fd. https://github.com/tianocore/edk2/commit/1c50db8a Debian's OVMF package should probably be updated, and the installed files should include the split files (preferably: *only* the split files). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
