Firmware auto-select limitation
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? Is it better to explicitly specify the loader and nvram path than using auto-select ? Just today, I encountered the issue of using firmware=“efi” on libvirt 5.4.0 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 Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup self._backend.create() File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirt.libvirtError: 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
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
On Fri, May 15, 2020 at 17:16:57 +0200, Michal Privoznik wrote:
On 5/15/20 4:40 PM, GUOQING LI wrote:
[...]
*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?
IMO there's another qemu where the 'readonly=on' command line property or thus the <readonly> property in the XML is missing and thus it's opened in write mode. Readers are forbidden then.
participants (3)
-
GUOQING LI -
Michal Privoznik -
Peter Krempa