Bug 1884954

Summary: fio-engine-rbd exposing a bogus Provides: librbd.so.1()(64bit) breaking install on any apps using librbd1
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: fioAssignee: Eric Sandeen <esandeen>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: agedosier, berrange, clalancette, esandeen, itamar, jforbes, laine, libvirt-maint, pportant, rjones, robatino, veillard, virt-maint, ykorman
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: openqa
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-19 21:43:13 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:
Bug Depends On:    
Bug Blocks: 1829022    
Attachments:
Description Flags
Fix for engine plugin SONAME none

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.