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