Firmware auto-select limitation
Michal Privoznik
mprivozn at redhat.com
Fri May 15 15:16:57 UTC 2020
On 5/15/20 4:40 PM, GUOQING LI wrote:
> Hi everyone and Martin
>
> I would like to confirm the conversation we had in regard the possible
> limitation of firmware auto-select feature that’s been released since
> v5.20. I recall you saying that there were a lot of issues with auto
> select and later they shipped it into a Json file , it still didn’t
> solve all the problems, did it?
I'm not aware of any pending fw autoselection bug/problem.
>
> Is it better to explicitly specify the loader and nvram path than using
> auto-select ?
No.
>
> Just today, I encountered the issue of using firmware=“efi” on libvirt
> 5.4.0
If you specify the FW and NVRAM explicitly in the domain XML does this
not reproduce?
>
> I am running Ubuntu eoan 19.10, I am wondering how did it happen.
>
> *Detailed error *
> Error starting domain: internal error: process exited while connecting
> to monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive
> file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
> Failed to lock byte 100
>
This error message comes from QEMU. Unfortunately, it doesn't say why
locking the file failed. Is there perhaps some additional info in the
audit log?
I don't think this is related to FW autoselection (those bugs
demonstrate in libvirt picking wrong FW image) and what you are facing
is different.
Michal
More information about the libvir-list
mailing list