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
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.
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?
(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/
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
https://src.fedoraproject.org/rpms/fio/c/7c3f48012b9bd06178a4263c31067b0cdd397de1?branch=master Let's see if this build solves the problem: https://koji.fedoraproject.org/koji/taskinfo?taskID=52807957
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.
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.
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
Created attachment 1719111 [details] Fix for engine plugin SONAME
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.
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.
I believe this is all fixed now, closing. Re-open if any issues remain.