rdma-core spec weird behavior on Fedora

public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed

* 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: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: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: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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox