Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1884954 - fio-engine-rbd exposing a bogus Provides: librbd.so.1()(64bit) breaking install on any apps using librbd1
Summary: fio-engine-rbd exposing a bogus Provides: librbd.so.1()(64bit) breaking ins...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fio
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F34BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-10-03 23:13 UTC by Adam Williamson
Modified: 2020-10-19 21:43 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-19 21:43:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Fix for engine plugin SONAME (deleted)
2020-10-05 16:54 UTC, Yigal Korman
no flags Details | Diff

Description Adam Williamson 2020-10-03 23:13:28 UTC
In Fedora-Rawhide-20201003.n.0 , all libvirt services fail to start on boot of a Workstation live install. This is likely related to the update of libvirt from libvirt-6.7.0-2.fc34 to libvirt-6.8.0-1.fc34.

journal shows this:

Oct 03 01:22:26 localhost.localdomain libvirtd[792]: libvirt version: 6.8.0, package: 1.fc34 (Fedora Project, 2020-10-02-21:05:52, )
Oct 03 01:22:26 localhost.localdomain libvirtd[792]: hostname: localhost.localdomain
Oct 03 01:22:26 localhost.localdomain libvirtd[792]: internal error: Failed to load module '/usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so': librbd.so.1: cannot open shared object file: No such file or directory

suggesting a missing dep on librbd1 somewhere.

This breaks virtualization, proposing as an F34 Beta blocker per criterion "The release must be able host virtual guest instances of the same release." - https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Virtualization_requirements

Comment 1 Daniel Berrangé 2020-10-05 12:02:31 UTC
Libvirt has a link time dep on librbd.so.1:

# ldd /usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so | grep rbd
	librbd.so.1 => not found


the RPM has auto-provides that lists this:

# rpm -q libvirt-daemon-driver-storage-rbd-6.8.0-1.fc34.x86_64 --requires | grep rbd
librbd.so.1()(64bit)


fio-engine-rbd claims to provide this library:

# rpm -q --whatprovides 'librbd.so.1()(64bit)'
fio-engine-rbd-3.23-3.fc34.x86_64

but it does *NOT* provide it

# rpm -ql fio-engine-rbd | grep rbd
/usr/lib64/fio/librbd.so

this appears to be an internal plugin for fio that is claiming same ABI/soname as the real librbd.so library

If i manually install librbd1 then we see the clash:

# rpm -q --whatprovides 'librbd.so.1()(64bit)'
fio-engine-rbd-3.23-3.fc34.x86_64
librbd1-15.2.5-1.fc34.x86_64


IIUC, dnf install will prefer fio-engine-rbd because its name sorts first alphabetically.

So, AFAICT,   fio needs fixing so that its doesn't add  Provides for its private plugins.

Comment 2 Richard W.M. Jones 2020-10-05 13:28:45 UTC
Oh dear, this was me I'm afraid.  The background is adding modular engine
support for fio:

https://src.fedoraproject.org/rpms/fio/blob/master/f/fio.spec#_31

Unfortunately it seems these engine names (*.so files) cause conflicting
RPM dependencies because they have the same SONAME as the "real" libraries.

> So, AFAICT,   fio needs fixing so that its doesn't add  Provides for its private plugins.

Perhaps filtering them out in the fio package is the answer here?

Comment 3 Eric Sandeen 2020-10-05 13:56:44 UTC
(In reply to Richard W.M. Jones from comment #2)

> Perhaps filtering them out in the fio package is the answer here?

Seems like it.  (in the subpackage, right)

 I didn't know that was possible, but I guess it is?  https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/

Comment 4 Richard W.M. Jones 2020-10-05 14:11:00 UTC
Filtering the Provides seems to work.

Before:

$ rpm -q --provides -p x86_64/fio-engine-nbd-3.23-3.fc34.x86_64.rpm 
fio-engine-nbd = 3.23-3.fc34
fio-engine-nbd(x86-64) = 3.23-3.fc34
libnbd.so.1()(64bit)

After:

$ rpm -q --provides -p x86_64/fio-engine-nbd-3.23-4.fc34.x86_64.rpm 
fio-engine-nbd = 3.23-4.fc34
fio-engine-nbd(x86-64) = 3.23-4.fc34

Comment 6 Adam Williamson 2020-10-05 15:36:06 UTC
Thanks for the quick work here, guys. Yes, provides filtering works fine and is what you're supposed to do in cases like this. Richard, you might also want to check if any subpackages of fio got automatic *requires* on the soname and filter those too, otherwise they're going to now pull in librbd1 when they don't need to.

Comment 7 Richard W.M. Jones 2020-10-05 16:13:32 UTC
Looking at the new Requires and Provides (see links here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1620357 )
and it looks OK to me.

Note it's expected that the engines will Require various libraries
(instead of core fio), because that's the point of the split.

Comment 8 Yigal Korman 2020-10-05 16:53:17 UTC
Hi,

I'm the original contributer of the modular engine split in fio.
This is my bug, the SONAME of the engine shouldn't match the name of the dependant library.
I have a patch to fix this upstream [0].
I will attach it to this report in case you'd like to pick it up in the package until it goes upstream.
I'm glad to see that the modular split is now enabled in Fedora, this was my original intent, just didn't get to sending the pull request [1].

[0] 0001-fio-fix-dynamic-engines-soname-definition.patch
[1] https://src.fedoraproject.org/fork/ykorman/rpms/fio/blob/dynamic-libengines/f/fio.spec

Comment 9 Yigal Korman 2020-10-05 16:54:11 UTC
Created attachment 1719111 [details]
Fix for engine plugin SONAME

Comment 10 Richard W.M. Jones 2020-10-05 17:02:22 UTC
Thanks, here is a Fedora build containing that patch:

https://koji.fedoraproject.org/koji/taskinfo?taskID=52816959

Note I have left the Provides exclusion in as a safety net since we
do not need the automatic dep generation for the fio engines.  We
can consider removing the exclusion in future.

Comment 11 Adam Williamson 2020-10-05 17:04:18 UTC
Yeah, it's still correct to exclude the auto-provides because packages shouldn't "provide" library sonames unless they're actually in the system shared library path and intended to be used as systemwide shared libraries.

Comment 12 Adam Williamson 2020-10-19 21:43:13 UTC
I believe this is all fixed now, closing. Re-open if any issues remain.


Note You need to log in before you can comment on or make changes to this bug.