* rdma-core spec weird behavior on Fedora
@ 2021-02-07 8:06 Leon Romanovsky
2021-02-08 12:59 ` Jason Gunthorpe
2021-02-10 11:54 ` Leon Romanovsky
0 siblings, 2 replies; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-07 8:06 UTC (permalink / raw)
To: Honggang Li
Cc: Itay Aveksis, RDMA mailing list, Alaa Hleihel, Jason Gunthorpe,
Doug Ledford
Hi Honggang,
Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
removes protection from rdma-core when user performs "dnf autoremove".
Before your patch, systemd was dependent on libibverbs and latter
required rdma-core. After your patch, the last link is lost and
rdma-core marked as orphaned package.
Any attempt to install rdma-core as standalone package will have the
following errors, due to the library dependency of udevadm.
[leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
libibverbs.so.1 => not found
[leonro@c rdma-core]$ sudo dnf install /tmp/rdma-core/RPMS/x86_64/rdma-core-34.0-1.fc32.x86_64.rpm
Last metadata expiration check: 1:29:40 ago on Sun 07 Feb 2021 07:29:13 AM IST.
Dependencies resolved.
======================================================================================================================
Package Architecture Version Repository Size
======================================================================================================================
Installing:
rdma-core x86_64 34.0-1.fc32 @commandline 54 k
Transaction Summary
======================================================================================================================
Install 1 Package
Total size: 54 k
Installed size: 121 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : rdma-core-34.0-1.fc32.x86_64 1/1
Running scriptlet: rdma-core-34.0-1.fc32.x86_64 1/1
/sbin/udevadm: error while loading shared libraries: libibverbs.so.1: cannot open shared object file: No such file or directory
/sbin/udevadm: error while loading shared libraries: libibverbs.so.1: cannot open shared object file: No such file or directory
/sbin/udevadm: error while loading shared libraries: libibverbs.so.1: cannot open shared object file: No such file or directory
/usr/bin/udevadm: error while loading shared libraries: libibverbs.so.1: cannot open shared object file: No such file or directory
/usr/bin/systemctl: error while loading shared libraries: libibverbs.so.1: cannot open shared object file: No such file or directory
warning: %triggerin(systemd-245.8-2.fc32.x86_64) scriptlet failed, exit status 127
Error in <unknown> scriptlet in rpm package rdma-core
Verifying : rdma-core-34.0-1.fc32.x86_64 1/1
Installed:
rdma-core-34.0-1.fc32.x86_64
Complete!
--------------------------------------------------------------------------------------
I think that the right solution is to make rdma-core meta-package as we
wanted it from the beginning when created rdma-core repo.
Thanks
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-07 8:06 rdma-core spec weird behavior on Fedora Leon Romanovsky
@ 2021-02-08 12:59 ` Jason Gunthorpe
2021-02-08 13:10 ` Leon Romanovsky
2021-02-10 11:54 ` Leon Romanovsky
1 sibling, 1 reply; 13+ messages in thread
From: Jason Gunthorpe @ 2021-02-08 12:59 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> Hi Honggang,
>
> Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> removes protection from rdma-core when user performs "dnf autoremove".
>
> Before your patch, systemd was dependent on libibverbs and latter
> required rdma-core. After your patch, the last link is lost and
> rdma-core marked as orphaned package.
>
> Any attempt to install rdma-core as standalone package will have the
> following errors, due to the library dependency of udevadm.
> [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> libibverbs.so.1 => not found
well that makes no sense, since when is udevadm connected to
libibverbs?
$ ldd `which udevadm`
linux-vdso.so.1 (0x00007ffcc09ef000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 12:59 ` Jason Gunthorpe
@ 2021-02-08 13:10 ` Leon Romanovsky
2021-02-08 13:15 ` Alaa Hleihel
2021-02-08 13:21 ` Jason Gunthorpe
0 siblings, 2 replies; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-08 13:10 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > Hi Honggang,
> >
> > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > removes protection from rdma-core when user performs "dnf autoremove".
> >
> > Before your patch, systemd was dependent on libibverbs and latter
> > required rdma-core. After your patch, the last link is lost and
> > rdma-core marked as orphaned package.
> >
> > Any attempt to install rdma-core as standalone package will have the
> > following errors, due to the library dependency of udevadm.
> > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > libibverbs.so.1 => not found
>
> well that makes no sense, since when is udevadm connected to
> libibverbs?
>
> $ ldd `which udevadm`
> linux-vdso.so.1 (0x00007ffcc09ef000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
This is from my laptop and it is connected:
➜ kernel git:(m/msix-v6) ldd /sbin/udevadm
linux-vdso.so.1 (0x00007fffc4bf2000)
libsystemd-shared-246.so => /usr/lib/systemd/libsystemd-shared-246.so (0x00007f70f69ef000)
libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f70f69c0000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007f70f69b6000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f70f6981000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70f6966000)
libc.so.6 => /lib64/libc.so.6 (0x00007f70f679b000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f70f6792000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f70f6758000)
libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007f70f66e3000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f70f65be000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f70f659d000)
libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007f70f6593000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f70f6573000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007f70f6530000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f70f6243000)
libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f70f6111000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007f70f60ff000)
librt.so.1 => /lib64/librt.so.1 (0x00007f70f60f4000)
libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f70f60d0000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f70f60a3000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f70f5fce000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f70f5fa2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f70f5f9b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f5f79000)
/lib64/ld-linux-x86-64.so.2 (0x00007f70f6d29000)
libz.so.1 => /lib64/libz.so.1 (0x00007f70f5f5d000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f70f5f55000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f70f5f4c000)
libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007f70f5eef000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f70f5e53000)
libargon2.so.1 => /lib64/libargon2.so.1 (0x00007f70f5e4a000)
libjson-c.so.5 => /lib64/libjson-c.so.5 (0x00007f70f5e35000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f70f5e10000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f70f5c8d000)
libpcap.so.1 => /lib64/libpcap.so.1 (0x00007f70f5c3e000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f70f5c33000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f70f5c04000)
libeconf.so.0 => /lib64/libeconf.so.0 (0x00007f70f5bfa000)
libm.so.6 => /lib64/libm.so.6 (0x00007f70f5ab4000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f70f5a1d000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f70f59f2000)
libibverbs.so.1 => /lib64/libibverbs.so.1 (0x00007f70f59cf000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007f70f59c7000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007f70f5944000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007f70f5921000)
➜ kernel git:(m/msix-v6) cat /etc/os-release
NAME=Fedora
VERSION="33 (Workstation Edition)"
ID=fedora
VERSION_ID=33
VERSION_CODENAME=""
PLATFORM_ID="platform:f33"
PRETTY_NAME="Fedora 33 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:33"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=33
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=33
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 13:10 ` Leon Romanovsky
@ 2021-02-08 13:15 ` Alaa Hleihel
2021-02-08 13:26 ` Leon Romanovsky
2021-02-08 13:21 ` Jason Gunthorpe
1 sibling, 1 reply; 13+ messages in thread
From: Alaa Hleihel @ 2021-02-08 13:15 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Doug Ledford
On 08/02/2021 15:10, Leon Romanovsky wrote:
> External email: Use caution opening links or attachments
>
>
> On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
>> On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
>>> Hi Honggang,
>>>
>>> Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
>>> removes protection from rdma-core when user performs "dnf autoremove".
>>>
>>> Before your patch, systemd was dependent on libibverbs and latter
>>> required rdma-core. After your patch, the last link is lost and
>>> rdma-core marked as orphaned package.
>>>
>>> Any attempt to install rdma-core as standalone package will have the
>>> following errors, due to the library dependency of udevadm.
>>> [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
>>> libibverbs.so.1 => not found
>>
>> well that makes no sense, since when is udevadm connected to
>> libibverbs?
>>
>> $ ldd `which udevadm`
>> linux-vdso.so.1 (0x00007ffcc09ef000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
>> libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
>> libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
>> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
>> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
>> liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
>> libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
>> libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
>
> This is from my laptop and it is connected:
>
> ➜ kernel git:(m/msix-v6) ldd /sbin/udevadm
> linux-vdso.so.1 (0x00007fffc4bf2000)
> libsystemd-shared-246.so => /usr/lib/systemd/libsystemd-shared-246.so (0x00007f70f69ef000)
> libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f70f69c0000)
> libacl.so.1 => /lib64/libacl.so.1 (0x00007f70f69b6000)
> libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f70f6981000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70f6966000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f70f679b000)
> libcap.so.2 => /lib64/libcap.so.2 (0x00007f70f6792000)
> libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f70f6758000)
> libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007f70f66e3000)
> libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f70f65be000)
> libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f70f659d000)
> libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007f70f6593000)
> liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f70f6573000)
> libmount.so.1 => /lib64/libmount.so.1 (0x00007f70f6530000)
> libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f70f6243000)
> libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f70f6111000)
> libpam.so.0 => /lib64/libpam.so.0 (0x00007f70f60ff000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f70f60f4000)
> libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f70f60d0000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f70f60a3000)
> libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f70f5fce000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f70f5fa2000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f70f5f9b000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f5f79000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f70f6d29000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f70f5f5d000)
> libattr.so.1 => /lib64/libattr.so.1 (0x00007f70f5f55000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f70f5f4c000)
> libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007f70f5eef000)
> libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f70f5e53000)
> libargon2.so.1 => /lib64/libargon2.so.1 (0x00007f70f5e4a000)
> libjson-c.so.5 => /lib64/libjson-c.so.5 (0x00007f70f5e35000)
> libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f70f5e10000)
> libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f70f5c8d000)
> libpcap.so.1 => /lib64/libpcap.so.1 (0x00007f70f5c3e000)
Check if libpcap was built with rdma support.
# nm /lib64/libpcap.so.1 | grep ibv
That's probably what pulled the libibverbs dependency.
Alaa
> libffi.so.6 => /lib64/libffi.so.6 (0x00007f70f5c33000)
> libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f70f5c04000)
> libeconf.so.0 => /lib64/libeconf.so.0 (0x00007f70f5bfa000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f70f5ab4000)
> libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f70f5a1d000)
> libudev.so.1 => /lib64/libudev.so.1 (0x00007f70f59f2000)
> libibverbs.so.1 => /lib64/libibverbs.so.1 (0x00007f70f59cf000)
> libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007f70f59c7000)
> libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007f70f5944000)
> libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007f70f5921000)
> ➜ kernel git:(m/msix-v6) cat /etc/os-release
> NAME=Fedora
> VERSION="33 (Workstation Edition)"
> ID=fedora
> VERSION_ID=33
> VERSION_CODENAME=""
> PLATFORM_ID="platform:f33"
> PRETTY_NAME="Fedora 33 (Workstation Edition)"
> ANSI_COLOR="0;38;2;60;110;180"
> LOGO=fedora-logo-icon
> CPE_NAME="cpe:/o:fedoraproject:fedora:33"
> HOME_URL="https://fedoraproject.org/"
> DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
> SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
> BUG_REPORT_URL="https://bugzilla.redhat.com/"
> REDHAT_BUGZILLA_PRODUCT="Fedora"
> REDHAT_BUGZILLA_PRODUCT_VERSION=33
> REDHAT_SUPPORT_PRODUCT="Fedora"
> REDHAT_SUPPORT_PRODUCT_VERSION=33
> PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
> VARIANT="Workstation Edition"
> VARIANT_ID=workstation
>
>
>>
>> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 13:10 ` Leon Romanovsky
2021-02-08 13:15 ` Alaa Hleihel
@ 2021-02-08 13:21 ` Jason Gunthorpe
2021-02-08 13:31 ` Leon Romanovsky
1 sibling, 1 reply; 13+ messages in thread
From: Jason Gunthorpe @ 2021-02-08 13:21 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > Hi Honggang,
> > >
> > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > removes protection from rdma-core when user performs "dnf autoremove".
> > >
> > > Before your patch, systemd was dependent on libibverbs and latter
> > > required rdma-core. After your patch, the last link is lost and
> > > rdma-core marked as orphaned package.
> > >
> > > Any attempt to install rdma-core as standalone package will have the
> > > following errors, due to the library dependency of udevadm.
> > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > libibverbs.so.1 => not found
> >
> > well that makes no sense, since when is udevadm connected to
> > libibverbs?
> >
> > $ ldd `which udevadm`
> > linux-vdso.so.1 (0x00007ffcc09ef000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
>
> This is from my laptop and it is connected:
Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
But it still doesn't make sense, how did you get a in a situation
where this is no libibverbs installed even though there should be
dependencies from udevadm preventing that?
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 13:15 ` Alaa Hleihel
@ 2021-02-08 13:26 ` Leon Romanovsky
0 siblings, 0 replies; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-08 13:26 UTC (permalink / raw)
To: Alaa Hleihel
Cc: Jason Gunthorpe, Honggang Li, Itay Aveksis, RDMA mailing list,
Doug Ledford
On Mon, Feb 08, 2021 at 03:15:52PM +0200, Alaa Hleihel wrote:
> On 08/02/2021 15:10, Leon Romanovsky wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> >> On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> >>> Hi Honggang,
> >>>
> >>> Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> >>> removes protection from rdma-core when user performs "dnf autoremove".
> >>>
> >>> Before your patch, systemd was dependent on libibverbs and latter
> >>> required rdma-core. After your patch, the last link is lost and
> >>> rdma-core marked as orphaned package.
> >>>
> >>> Any attempt to install rdma-core as standalone package will have the
> >>> following errors, due to the library dependency of udevadm.
> >>> [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> >>> libibverbs.so.1 => not found
> >>
> >> well that makes no sense, since when is udevadm connected to
> >> libibverbs?
> >>
> >> $ ldd `which udevadm`
> >> linux-vdso.so.1 (0x00007ffcc09ef000)
> >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> >> libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> >> libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> >> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> >> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> >> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> >> /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> >> liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> >> libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> >> libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> >> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> >
> > This is from my laptop and it is connected:
> >
> > ➜ kernel git:(m/msix-v6) ldd /sbin/udevadm
> > linux-vdso.so.1 (0x00007fffc4bf2000)
> > libsystemd-shared-246.so => /usr/lib/systemd/libsystemd-shared-246.so (0x00007f70f69ef000)
> > libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f70f69c0000)
> > libacl.so.1 => /lib64/libacl.so.1 (0x00007f70f69b6000)
> > libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f70f6981000)
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70f6966000)
> > libc.so.6 => /lib64/libc.so.6 (0x00007f70f679b000)
> > libcap.so.2 => /lib64/libcap.so.2 (0x00007f70f6792000)
> > libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f70f6758000)
> > libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007f70f66e3000)
> > libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f70f65be000)
> > libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f70f659d000)
> > libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007f70f6593000)
> > liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f70f6573000)
> > libmount.so.1 => /lib64/libmount.so.1 (0x00007f70f6530000)
> > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f70f6243000)
> > libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f70f6111000)
> > libpam.so.0 => /lib64/libpam.so.0 (0x00007f70f60ff000)
> > librt.so.1 => /lib64/librt.so.1 (0x00007f70f60f4000)
> > libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f70f60d0000)
> > libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f70f60a3000)
> > libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f70f5fce000)
> > liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f70f5fa2000)
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f70f5f9b000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f5f79000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f70f6d29000)
> > libz.so.1 => /lib64/libz.so.1 (0x00007f70f5f5d000)
> > libattr.so.1 => /lib64/libattr.so.1 (0x00007f70f5f55000)
> > libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f70f5f4c000)
> > libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007f70f5eef000)
> > libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f70f5e53000)
> > libargon2.so.1 => /lib64/libargon2.so.1 (0x00007f70f5e4a000)
> > libjson-c.so.5 => /lib64/libjson-c.so.5 (0x00007f70f5e35000)
> > libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f70f5e10000)
> > libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f70f5c8d000)
> > libpcap.so.1 => /lib64/libpcap.so.1 (0x00007f70f5c3e000)
>
> Check if libpcap was built with rdma support.
> # nm /lib64/libpcap.so.1 | grep ibv
>
> That's probably what pulled the libibverbs dependency.
➜ kernel git:(m/msix-v6) nm /lib64/libpcap.so.1 | grep ibv
nm: /lib64/libpcap.so.1: no symbols
Thanks
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 13:21 ` Jason Gunthorpe
@ 2021-02-08 13:31 ` Leon Romanovsky
2021-02-08 14:08 ` Jason Gunthorpe
0 siblings, 1 reply; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-08 13:31 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > Hi Honggang,
> > > >
> > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > >
> > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > required rdma-core. After your patch, the last link is lost and
> > > > rdma-core marked as orphaned package.
> > > >
> > > > Any attempt to install rdma-core as standalone package will have the
> > > > following errors, due to the library dependency of udevadm.
> > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > libibverbs.so.1 => not found
> > >
> > > well that makes no sense, since when is udevadm connected to
> > > libibverbs?
> > >
> > > $ ldd `which udevadm`
> > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> >
> > This is from my laptop and it is connected:
>
> Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
>
> But it still doesn't make sense, how did you get a in a situation
> where this is no libibverbs installed even though there should be
> dependencies from udevadm preventing that?
It was part of my experiments and it is not the issue which we need to solve.
Our two problems are that "dnf autoremove" removes rdma-core and you can't
install it separately after Honggang's patch.
Thanks
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 13:31 ` Leon Romanovsky
@ 2021-02-08 14:08 ` Jason Gunthorpe
2021-02-08 14:31 ` Leon Romanovsky
0 siblings, 1 reply; 13+ messages in thread
From: Jason Gunthorpe @ 2021-02-08 14:08 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote:
> On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > > Hi Honggang,
> > > > >
> > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > > >
> > > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > > required rdma-core. After your patch, the last link is lost and
> > > > > rdma-core marked as orphaned package.
> > > > >
> > > > > Any attempt to install rdma-core as standalone package will have the
> > > > > following errors, due to the library dependency of udevadm.
> > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > > libibverbs.so.1 => not found
> > > >
> > > > well that makes no sense, since when is udevadm connected to
> > > > libibverbs?
> > > >
> > > > $ ldd `which udevadm`
> > > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> > >
> > > This is from my laptop and it is connected:
> >
> > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
> >
> > But it still doesn't make sense, how did you get a in a situation
> > where this is no libibverbs installed even though there should be
> > dependencies from udevadm preventing that?
>
> It was part of my experiments and it is not the issue which we need to solve.
>
> Our two problems are that "dnf autoremove" removes rdma-core and you can't
> install it separately after Honggang's patch.
why not? libibverbs should not be removed by autoremoved?
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 14:08 ` Jason Gunthorpe
@ 2021-02-08 14:31 ` Leon Romanovsky
2021-02-08 15:35 ` Jason Gunthorpe
0 siblings, 1 reply; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-08 14:31 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 10:08:24AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote:
> > On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > > > Hi Honggang,
> > > > > >
> > > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > > > >
> > > > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > > > required rdma-core. After your patch, the last link is lost and
> > > > > > rdma-core marked as orphaned package.
> > > > > >
> > > > > > Any attempt to install rdma-core as standalone package will have the
> > > > > > following errors, due to the library dependency of udevadm.
> > > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > > > libibverbs.so.1 => not found
> > > > >
> > > > > well that makes no sense, since when is udevadm connected to
> > > > > libibverbs?
> > > > >
> > > > > $ ldd `which udevadm`
> > > > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> > > >
> > > > This is from my laptop and it is connected:
> > >
> > > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
> > >
> > > But it still doesn't make sense, how did you get a in a situation
> > > where this is no libibverbs installed even though there should be
> > > dependencies from udevadm preventing that?
> >
> > It was part of my experiments and it is not the issue which we need to solve.
> >
> > Our two problems are that "dnf autoremove" removes rdma-core and you can't
> > install it separately after Honggang's patch.
>
> why not? libibverbs should not be removed by autoremoved?
During installation of rdma-core, DNF throws errors if libibverbs
doesn't exist, which was in my case when I wanted to reinstall rdma-core
to something new.
Thanks
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 14:31 ` Leon Romanovsky
@ 2021-02-08 15:35 ` Jason Gunthorpe
2021-02-08 15:59 ` Leon Romanovsky
0 siblings, 1 reply; 13+ messages in thread
From: Jason Gunthorpe @ 2021-02-08 15:35 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 04:31:00PM +0200, Leon Romanovsky wrote:
> On Mon, Feb 08, 2021 at 10:08:24AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote:
> > > On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> > > > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > > > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > > > > Hi Honggang,
> > > > > > >
> > > > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > > > > >
> > > > > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > > > > required rdma-core. After your patch, the last link is lost and
> > > > > > > rdma-core marked as orphaned package.
> > > > > > >
> > > > > > > Any attempt to install rdma-core as standalone package will have the
> > > > > > > following errors, due to the library dependency of udevadm.
> > > > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > > > > libibverbs.so.1 => not found
> > > > > >
> > > > > > well that makes no sense, since when is udevadm connected to
> > > > > > libibverbs?
> > > > > >
> > > > > > $ ldd `which udevadm`
> > > > > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> > > > >
> > > > > This is from my laptop and it is connected:
> > > >
> > > > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
> > > >
> > > > But it still doesn't make sense, how did you get a in a situation
> > > > where this is no libibverbs installed even though there should be
> > > > dependencies from udevadm preventing that?
> > >
> > > It was part of my experiments and it is not the issue which we need to solve.
> > >
> > > Our two problems are that "dnf autoremove" removes rdma-core and you can't
> > > install it separately after Honggang's patch.
> >
> > why not? libibverbs should not be removed by autoremoved?
>
> During installation of rdma-core, DNF throws errors if libibverbs
> doesn't exist, which was in my case when I wanted to reinstall rdma-core
> to something new.
dnf shouldn't let you remove libibvebs, so how did it get removed?
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 15:35 ` Jason Gunthorpe
@ 2021-02-08 15:59 ` Leon Romanovsky
2021-02-08 18:18 ` Jason Gunthorpe
0 siblings, 1 reply; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-08 15:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 11:35:31AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 08, 2021 at 04:31:00PM +0200, Leon Romanovsky wrote:
> > On Mon, Feb 08, 2021 at 10:08:24AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote:
> > > > On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> > > > > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > > > > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > > > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > > > > > Hi Honggang,
> > > > > > > >
> > > > > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > > > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > > > > > >
> > > > > > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > > > > > required rdma-core. After your patch, the last link is lost and
> > > > > > > > rdma-core marked as orphaned package.
> > > > > > > >
> > > > > > > > Any attempt to install rdma-core as standalone package will have the
> > > > > > > > following errors, due to the library dependency of udevadm.
> > > > > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > > > > > libibverbs.so.1 => not found
> > > > > > >
> > > > > > > well that makes no sense, since when is udevadm connected to
> > > > > > > libibverbs?
> > > > > > >
> > > > > > > $ ldd `which udevadm`
> > > > > > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > > > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > > > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > > > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > > > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > > > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > > > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > > > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> > > > > >
> > > > > > This is from my laptop and it is connected:
> > > > >
> > > > > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
> > > > >
> > > > > But it still doesn't make sense, how did you get a in a situation
> > > > > where this is no libibverbs installed even though there should be
> > > > > dependencies from udevadm preventing that?
> > > >
> > > > It was part of my experiments and it is not the issue which we need to solve.
> > > >
> > > > Our two problems are that "dnf autoremove" removes rdma-core and you can't
> > > > install it separately after Honggang's patch.
> > >
> > > why not? libibverbs should not be removed by autoremoved?
> >
> > During installation of rdma-core, DNF throws errors if libibverbs
> > doesn't exist, which was in my case when I wanted to reinstall rdma-core
> > to something new.
>
> dnf shouldn't let you remove libibvebs, so how did it get removed?
I built rdma-core RPM with latest code, issued "dnf install rdma-core
...", which passed with error and left system with "unknown" library.
Thanks
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-08 15:59 ` Leon Romanovsky
@ 2021-02-08 18:18 ` Jason Gunthorpe
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gunthorpe @ 2021-02-08 18:18 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Honggang Li, Itay Aveksis, RDMA mailing list, Alaa Hleihel, Doug Ledford
On Mon, Feb 08, 2021 at 05:59:11PM +0200, Leon Romanovsky wrote:
> On Mon, Feb 08, 2021 at 11:35:31AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 08, 2021 at 04:31:00PM +0200, Leon Romanovsky wrote:
> > > On Mon, Feb 08, 2021 at 10:08:24AM -0400, Jason Gunthorpe wrote:
> > > > On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote:
> > > > > On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote:
> > > > > > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote:
> > > > > > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote:
> > > > > > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> > > > > > > > > Hi Honggang,
> > > > > > > > >
> > > > > > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> > > > > > > > > removes protection from rdma-core when user performs "dnf autoremove".
> > > > > > > > >
> > > > > > > > > Before your patch, systemd was dependent on libibverbs and latter
> > > > > > > > > required rdma-core. After your patch, the last link is lost and
> > > > > > > > > rdma-core marked as orphaned package.
> > > > > > > > >
> > > > > > > > > Any attempt to install rdma-core as standalone package will have the
> > > > > > > > > following errors, due to the library dependency of udevadm.
> > > > > > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> > > > > > > > > libibverbs.so.1 => not found
> > > > > > > >
> > > > > > > > well that makes no sense, since when is udevadm connected to
> > > > > > > > libibverbs?
> > > > > > > >
> > > > > > > > $ ldd `which udevadm`
> > > > > > > > linux-vdso.so.1 (0x00007ffcc09ef000)
> > > > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000)
> > > > > > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000)
> > > > > > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000)
> > > > > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000)
> > > > > > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000)
> > > > > > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000)
> > > > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000)
> > > > > > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000)
> > > > > > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000)
> > > > > > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000)
> > > > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000)
> > > > > > >
> > > > > > > This is from my laptop and it is connected:
> > > > > >
> > > > > > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs
> > > > > >
> > > > > > But it still doesn't make sense, how did you get a in a situation
> > > > > > where this is no libibverbs installed even though there should be
> > > > > > dependencies from udevadm preventing that?
> > > > >
> > > > > It was part of my experiments and it is not the issue which we need to solve.
> > > > >
> > > > > Our two problems are that "dnf autoremove" removes rdma-core and you can't
> > > > > install it separately after Honggang's patch.
> > > >
> > > > why not? libibverbs should not be removed by autoremoved?
> > >
> > > During installation of rdma-core, DNF throws errors if libibverbs
> > > doesn't exist, which was in my case when I wanted to reinstall rdma-core
> > > to something new.
> >
> > dnf shouldn't let you remove libibvebs, so how did it get removed?
>
> I built rdma-core RPM with latest code, issued "dnf install rdma-core
> ...", which passed with error and left system with "unknown" library.
Hum.
In DEB land if a post install script called some other program, like
udevadm, then it would have to pre-depend on that program so it could
be fully ready to run. Pre-depending would ensure that libibverbs was
swapped out somewhat atomically and the system wouldn't try to
configure rdma-core when libibverbs was not installed during a
transaction to change things around.
Sounds like some dnf expert should take a look at what is going on
here
But also, I don't think Fedora should have libverbs as an mandatory
package in every system for whateve udev is doing with libcap,
something really weird is going on that udev needs pcap
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rdma-core spec weird behavior on Fedora
2021-02-07 8:06 rdma-core spec weird behavior on Fedora Leon Romanovsky
2021-02-08 12:59 ` Jason Gunthorpe
@ 2021-02-10 11:54 ` Leon Romanovsky
1 sibling, 0 replies; 13+ messages in thread
From: Leon Romanovsky @ 2021-02-10 11:54 UTC (permalink / raw)
To: Honggang Li
Cc: Itay Aveksis, RDMA mailing list, Alaa Hleihel, Jason Gunthorpe,
Doug Ledford
On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote:
> Hi Honggang,
>
> Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages")
> removes protection from rdma-core when user performs "dnf autoremove".
>
> Before your patch, systemd was dependent on libibverbs and latter
> required rdma-core. After your patch, the last link is lost and
> rdma-core marked as orphaned package.
>
> Any attempt to install rdma-core as standalone package will have the
> following errors, due to the library dependency of udevadm.
> [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs
> libibverbs.so.1 => not found
ok, the root cause for that was found - broken installation of libpcap.
Thanks
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-02-10 11:57 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-07 8:06 rdma-core spec weird behavior on Fedora Leon Romanovsky
2021-02-08 12:59 ` Jason Gunthorpe
2021-02-08 13:10 ` Leon Romanovsky
2021-02-08 13:15 ` Alaa Hleihel
2021-02-08 13:26 ` Leon Romanovsky
2021-02-08 13:21 ` Jason Gunthorpe
2021-02-08 13:31 ` Leon Romanovsky
2021-02-08 14:08 ` Jason Gunthorpe
2021-02-08 14:31 ` Leon Romanovsky
2021-02-08 15:35 ` Jason Gunthorpe
2021-02-08 15:59 ` Leon Romanovsky
2021-02-08 18:18 ` Jason Gunthorpe
2021-02-10 11:54 ` Leon Romanovsky
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.