On 9/22/23 15:26, Andrea Bolognani wrote: > The current message can be misleading, because it seems to suggest > that no firmware of the requested type is available on the system. > > What actually happens most of the time, however, is that despite > having multiple firmwares of the right type to choose from, none > of them is suitable because of lacking some specific feature or > being incompatible with some setting that the user has explicitly > enabled. > > Providing an error message that describes exactly the problem is > not feasible, since we would have to list each candidate along > with the reason why we rejected it, which would get out of hand > quickly. > > As a small but hopefully helpful improvement over the current > situation, reword the error message to make it clearer that the > culprit is not necessarily the firmware type, but rather the > overall domain configuration. > > Suggested-by: Michael Kjörling <7d1340278...@ewoof.net> > Signed-off-by: Andrea Bolognani <abolo...@redhat.com> > --- > src/qemu/qemu_firmware.c | 2 +- > .../firmware-auto-efi-loader-path-nonstandard.x86_64-latest.err | 2 +- > ...rmware-auto-efi-nvram-template-nonstandard.x86_64-latest.err | 2 +- > .../firmware-auto-efi-rw-abi-update.x86_64-latest.err | 2 +- > tests/qemuxml2argvdata/firmware-auto-efi-rw.x86_64-latest.err | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Michal Privoznik <mpriv...@redhat.com> And maybe we can document what us, libvirt developers, would do to debug this? I mean, we can put somewhere in a kbase article that we would enable debug logs and then check log messages where individual reasons for rejecting each fw are logged. Michal
