nfs-ganesha-2.8.2 on CentOS-7.7 and error: /lib64/libganesha_nfsd.so.2.8: undefined symbol: rados_read_op_omap_get_vals2
I'm trying to run nfs-ganesha-2.8.2 on CentOS-7.7 and it's failing with the error shown in the Subject line. More details below. On some other CentOS-7 systems I'm successfully running nfs-ganesha-2.7.6 from the centos-gluster41 repo, but I thought I'd have a go with the nfs-ganesha-2.8.2 from the centos-nfs-ganesha28 repo. Was that a mistake? Is there a good document anyone could point me to that describes current recommendations (e.g. what versions to use, what to avoid) for installing and using nfs-ganesha on CentOS-7. I should point out that I'm only interested in using the PROXY FSAL at this time. This is what I'm happily - for the most part - using with nfs-ganesha-2.7.6. My google-fu has not turned up an answer, so I'm turning here for help. Any help in solving this problem with 2.8.2 or advice about using other versions will be much appreciated. Thanks! [root@localhost ~]# uname -r 3.10.0-1062.1.1.el7.x86_64 [root@localhost ~]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) [root@localhost ~]# yum install -y nfs-ganesha nfs-ganesha-proxy [root@localhost ~]# !syst systemctl status -l nfs-ganesha ● nfs-ganesha.service - NFS-Ganesha file server Loaded: loaded (/usr/lib/systemd/system/nfs-ganesha.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2019-09-27 12:04:14 EDT; 2h 48min ago Docs: http://github.com/nfs-ganesha/nfs-ganesha/wiki Process: 24252 ExecStart=/bin/bash -c ${NUMACTL} ${NUMAOPTS} /usr/bin/ganesha.nfsd ${OPTIONS} ${EPOCH} (code=exited, status=127) Sep 27 12:04:14 localhost systemd[1]: Starting NFS-Ganesha file server... Sep 27 12:04:14 localhost bash[24252]: /usr/bin/ganesha.nfsd: symbol lookup error: /lib64/libganesha_nfsd.so.2.8: undefined symbol: rados_read_op_omap_get_vals2 Sep 27 12:04:14 localhost systemd[1]: nfs-ganesha.service: control process exited, code=exited status=127 Sep 27 12:04:14 localhost systemd[1]: Failed to start NFS-Ganesha file server. Sep 27 12:04:14 localhost systemd[1]: Unit nfs-ganesha.service entered failed state. Sep 27 12:04:14 localhost systemd[1]: nfs-ganesha.service failed.
Ganesha 2.8 in the CentOS Storage SIG is built with Ceph Nautilus (14), also from the CentOS Storage SIG. On the surface it's strange that libganesha_nfsd.so is looking for symbols from librados. As a short term solution you could try installing the nfs-ganesha-ceph RPM and see if that helps. -- Kaleb On Fri, Sep 27, 2019 at 3:25 PM Todd Pfaff <pfaff@rhpcs.mcmaster.ca> wrote:
I'm trying to run nfs-ganesha-2.8.2 on CentOS-7.7 and it's failing with the error shown in the Subject line. More details below.
On some other CentOS-7 systems I'm successfully running nfs-ganesha-2.7.6 from the centos-gluster41 repo, but I thought I'd have a go with the nfs-ganesha-2.8.2 from the centos-nfs-ganesha28 repo. Was that a mistake? Is there a good document anyone could point me to that describes current recommendations (e.g. what versions to use, what to avoid) for installing and using nfs-ganesha on CentOS-7.
I should point out that I'm only interested in using the PROXY FSAL at this time. This is what I'm happily - for the most part - using with nfs-ganesha-2.7.6.
My google-fu has not turned up an answer, so I'm turning here for help. Any help in solving this problem with 2.8.2 or advice about using other versions will be much appreciated. Thanks!
[root@localhost ~]# uname -r 3.10.0-1062.1.1.el7.x86_64
[root@localhost ~]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core)
[root@localhost ~]# yum install -y nfs-ganesha nfs-ganesha-proxy
[root@localhost ~]# !syst systemctl status -l nfs-ganesha ● nfs-ganesha.service - NFS-Ganesha file server Loaded: loaded (/usr/lib/systemd/system/nfs-ganesha.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2019-09-27 12:04:14 EDT; 2h 48min ago Docs: http://github.com/nfs-ganesha/nfs-ganesha/wiki Process: 24252 ExecStart=/bin/bash -c ${NUMACTL} ${NUMAOPTS} /usr/bin/ganesha.nfsd ${OPTIONS} ${EPOCH} (code=exited, status=127)
Sep 27 12:04:14 localhost systemd[1]: Starting NFS-Ganesha file server... Sep 27 12:04:14 localhost bash[24252]: /usr/bin/ganesha.nfsd: symbol lookup error: /lib64/libganesha_nfsd.so.2.8: undefined symbol: rados_read_op_omap_get_vals2 Sep 27 12:04:14 localhost systemd[1]: nfs-ganesha.service: control process exited, code=exited status=127 Sep 27 12:04:14 localhost systemd[1]: Failed to start NFS-Ganesha file server. Sep 27 12:04:14 localhost systemd[1]: Unit nfs-ganesha.service entered failed state. Sep 27 12:04:14 localhost systemd[1]: nfs-ganesha.service failed. _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
On Fri, Sep 27, 2019 at 3:33 PM Kaleb Keithley <kkeithle@redhat.com> wrote:
Ganesha 2.8 in the CentOS Storage SIG is built with Ceph Nautilus (14), also from the CentOS Storage SIG.
On the surface it's strange that libganesha_nfsd.so is looking for symbols from librados.
As a short term solution you could try installing the nfs-ganesha-ceph RPM and see if that helps.
Or rather install the librados2 RPM from Ceph Nautilus and see if that helps. -- Kaleb
Thanks, Kaleb, this did the trick: yum install centos-release-ceph-nautilus yum update librados2 systemctl start nfs-ganesha cheers, Todd
On 9/27/19 3:33 PM, Kaleb Keithley wrote:
Ganesha 2.8 in the CentOS Storage SIG is built with Ceph Nautilus (14), also from the CentOS Storage SIG.
On the surface it's strange that libganesha_nfsd.so is looking for symbols from librados.
The recovery backends are built directly into SAL, rather than being separate libraries that are loaded. Daniel
On Mon, Sep 30, 2019 at 8:20 AM Daniel Gryniewicz <dang@redhat.com> wrote:
On 9/27/19 3:33 PM, Kaleb Keithley wrote:
Ganesha 2.8 in the CentOS Storage SIG is built with Ceph Nautilus (14), also from the CentOS Storage SIG.
On the surface it's strange that libganesha_nfsd.so is looking for symbols from librados.
The recovery backends are built directly into SAL, rather than being separate libraries that are loaded.
Yup. The recovery backends can be easily fixed by making a cmake module (i.e. a shared lib) out of the recovery_rados{,ng,kv} files and dlopen+dlsym-ing them. There is also .../support/rados_grace.[co] It's in ganesha_nfsd.so, mainly as a convenience so that tools/ganesha-rados-grace can simply link to ganesha_nfsd.so, but I think we do away with that as well. -- Kaleb
participants (3)
-
Daniel Gryniewicz -
Kaleb Keithley -
Todd Pfaff