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 <7d1340278307@ewoof.net> Signed-off-by: Andrea Bolognani <abologna@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 <mprivozn@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