Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#58903 - [libvirt] Unable to start virtual machine
Attached to Project:
Community Packages
Opened by Giancarlo Razzolini (grazzolini) - Thursday, 07 June 2018, 03:34 GMT
Last edited by Christian Rebischke (Shibumi) - Friday, 08 June 2018, 14:48 GMT
Opened by Giancarlo Razzolini (grazzolini) - Thursday, 07 June 2018, 03:34 GMT
Last edited by Christian Rebischke (Shibumi) - Friday, 08 June 2018, 14:48 GMT
|
DetailsDescription:
After upgrade to libvirt 4.4.0, can't start VM's with the following error: Failed to load module '/usr/lib/libvirt/storage-file/libvirt_storage_file_gluster.so': libgfapi.so.0: cannot open shared object file Downgrading libvirt package to 4.3.0 fixes the issue. Additional info: * libvirt 4.4.0 Steps to reproduce: Upgrade to libvirt 4.4.0 and then try to start a new VM. |
This task depends upon
Closed by Christian Rebischke (Shibumi)
Friday, 08 June 2018, 14:48 GMT
Reason for closing: Fixed
Additional comments about closing: 4.4.0-2
Friday, 08 June 2018, 14:48 GMT
Reason for closing: Fixed
Additional comments about closing: 4.4.0-2
Comment by Doug Newgard (Scimmia) -
Thursday, 07 June 2018, 05:42 GMT
So it's a simple missing dep. Downgrading seems like severe overkill.
Comment by Gabriel Majeri (gabrielm) -
Thursday, 07 June 2018, 09:03 GMT
Can confirm that installing the `glusterfs` package fixes this issue with 4.4.0
Comment by Eli Schwartz (eschwartz) -
Thursday, 07 June 2018, 22:58 GMT
Maybe try filing an upstream bug? If these are implemented as plugins, it seems silly that merely detecting it on disk and trying to load it unsuccessfully would abort everything. It should just log a warning and continue with other storage backends enabled.
Comment by Christian Rebischke (Shibumi) -
Friday, 08 June 2018, 14:48 GMT
I have pushed a version 4.4.0-2 it should fix the dependency issues..