Re: [libvirt PATCH] qemu: Improve error message for failed firmware autoselection
On Fri, Sep 22, 2023 at 03:44:55PM +0200, Michal Prívozník wrote: > On 9/22/23 15:26, Andrea Bolognani wrote: > > 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 Pushed, thanks. > 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. Can you think of an existing page where it would fit? Honestly it would probably make sense to have an entire kbase dedicated to firmware selection, with recommendations, best practices, gotchas and so on. Maybe we could then include the debugging steps as part of it? Note that the current output, even with debugging enabled, is not very easy to follow, so before suggesting that people go look at it I would probably want to improve upon it. Damn, I think you might just have nerd-sniped me into working on this! Let me add it to my to-do list :D -- Andrea Bolognani / Red Hat / Virtualization
Re: [libvirt PATCH] qemu: Improve error message for failed firmware autoselection
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 > --- > 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 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
