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(a)ewoof.net>
Signed-off-by: Andrea Bolognani <abologna(a)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(a)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