From: Peter Krempa <pkrempa@redhat.com>

Commit 41fe1199bbad4ab9cc refactored 'qemuPrepareNVRAMFile' by splitting
out checks which weren't relevant for the implementation of the
alternative way to store UEFI variable data in the JSON file.

By doing so the commit moved the check which disallows NVRAM configs
where the user would ask for conversion of the template to another
format *before* it's checked if a NVRAM image even needs to be
populated.

This means that any configs where the user converted their NVRAM image
to a different format than the template which were previously working
now start complaining that format conversion is not supported.

Fix this by duplicating the logic that is used to determine if the image
will be created. The existing logic can be now simplified because the
caller ensures that 'loader' and 'loader->nvram' are non-NULL.

Fixes: 41fe1199bbad4ab9cc4bda078571cd7bc5897d44
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
---
 src/qemu/qemu_process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 3f1960f314..dec4a0e9c6 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5018,7 +5018,7 @@ qemuPrepareNVRAMFile(virQEMUDriver *driver,
 {
     /* If 'nvramTemplateFormat' is empty it means that it's a user-provided
      * template which we couldn't verify. Assume the user knows what they're doing */
-    if (loader && loader->nvram &&
+    if ((!virFileExists(loader->nvram->path) || reset_nvram) &&
         loader->nvramTemplateFormat != VIR_STORAGE_FILE_NONE &&
         loader->nvram->format != loader->nvramTemplateFormat) {
         virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-- 
2.56.0

On 11/12/26 17:54, Peter Krempa via Devel wrote:
> From: Peter Krempa <pkrempa@redhat.com>
> 
> Commit 41fe1199bbad4ab9cc refactored 'qemuPrepareNVRAMFile' by splitting
> out checks which weren't relevant for the implementation of the
> alternative way to store UEFI variable data in the JSON file.
> 
> By doing so the commit moved the check which disallows NVRAM configs
> where the user would ask for conversion of the template to another
> format *before* it's checked if a NVRAM image even needs to be
> populated.
> 
> This means that any configs where the user converted their NVRAM image
> to a different format than the template which were previously working
> now start complaining that format conversion is not supported.
> 
> Fix this by duplicating the logic that is used to determine if the image
> will be created. The existing logic can be now simplified because the
> caller ensures that 'loader' and 'loader->nvram' are non-NULL.
> 
> Fixes: 41fe1199bbad4ab9cc4bda078571cd7bc5897d44
> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> ---
>  src/qemu/qemu_process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal