Bug 1635865

Summary:	/usr/bin/qemu-system-x86_64: undefined symbol: libusb_set_option
Product:	[Fedora] Fedora	Reporter:	Alex G. <mr.nuke.me>
Component:	qemu	Assignee:	Fedora Virtualization Maintainers <virt-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	amit, berrange, cfergeau, dwmw2, itamar, pbonzini, rjones, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-03 19:57:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alex G. 2018-10-03 19:28:35 UTC

Description of problem:

It appears there is a dependency issue with libusbx:
On a fresh install, qemu-kvm fails to start

Version-Release number of selected component (if applicable):

qemu-kvm-2.11.2-4.fc28.x86_64
libusbx-1.0.21-6.fc28.x86_64 


How reproducible:
I don't understand the grammar of this field.


Steps to Reproduce:
1. $ qemu-kvm

Actual results:
# qemu-kvm 
/usr/bin/qemu-system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: libusb_set_option


Expected results:
qemu-kvm starts up.


Additional info:
User must manually upgrade to libusbx-1.0.22-1.fc28.x86_64.
With libusbx-1.0.21-6.fc28.x86_64, the problem persists.

Comment 1 Richard W.M. Jones 2018-10-03 19:57:20 UTC

This happens all the time when using a qemu version which
is later than the corresponding libusbx version.  I believe
the only good fix is for libusbx to start using symbol
versioning (which would probably have to happen upstream).

In the mean time, yes, the workaround is to upgrade to the
newest libusbx.

*** This bug has been marked as a duplicate of bug 1625641 ***