Hi all,
yesterday some atlas user opened a GGUS (48554) about some error in
lfc-ls.:
lfc-mkdir: error while loading shared libraries: libuuid.so.1: cannot
open shared object file: No such file or directory
I did some quick test:
#ldd /opt/lcg/bin/lfc-ls
linux-gate.so.1 => (0xffffe000)
libglobus_gssapi_gsi_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gssapi_gsi_gcc32dbgpthr.so.0 (0xf7fe0000)
libglobus_gss_assist_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gss_assist_gcc32dbgpthr.so.0 (0xf7fd3000)
libdl.so.2 => /lib/libdl.so.2 (0x00b5a000) libnsl.so.1
=> /lib/libnsl.so.1 (0x00c55000) libuuid.so.1 => not found libc.so.6
=> /lib/tls/libc.so.6 (0x00a29000)
libglobus_gsi_proxy_core_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gsi_proxy_core_gcc32dbgpthr.so.0
(0xf7f9a000) libglobus_gsi_credential_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gsi_credential_gcc32dbgpthr.so.0
(0xf7f8a000) libglobus_gsi_callback_gcc32dbgpthr.so.0 => /opt/globus/lib/libglobus_gsi_callback_gcc32dbgpthr.so.0 (0xf7f80000)
[...]
that nodes already had libuuid.so.1, but 64 bits only:
# ls -lsa /lib64/libuuid.so.1
4 lrwxrwxrwx 1 root root 14 Dec 3 23:31 /lib64/libuuid.so.1 ->
libuuid.so.1.2
# rpm -qf /lib64/libuuid.so.1
e2fsprogs-1.35-12.17.el4.x86_64
but lfc-ls (or lfc-mkdir) needed 32 bits libuuid.so.1, so I had to
install e2fsprogs.i386 to solve the problem.
This problem only happened in new nodes that I installed yesterday,
so not sure where this problem comes from, cause my old nodes did not
complain about lfc-* commands...
We have glite repo replicas here at pic, so I first thought it could be
a desync of
http://glitesoft.cern.ch/EGEE/gLite/R3.2/glite-WN/sl5/x86_64/RPMS.release/repodata/comps-glite-WN.xml
but I downloaded last comps file and comparing to new one they are
exaclty the same.
So, I have installled other node using glitesoft repos (from
http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.1/)
and I found same problem:
# lfc-ls
lfc-ls: error while loading shared libraries: libuuid.so.1: cannot open
shared object file: No such file or directory
[root@td152 ~]# which lfc-ls
/opt/lcg/bin/lfc-ls
You have new mail in /var/spool/mail/root
[root@td152 ~]# ldd /opt/lcg/bin/lfc-ls
linux-gate.so.1 => (0xffffe000)
libglobus_gssapi_gsi_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gssapi_gsi_gcc32dbgpthr.so.0 (0xf7fe0000)
libglobus_gss_assist_gcc32dbgpthr.so.0
=> /opt/globus/lib/libglobus_gss_assist_gcc32dbgpthr.so.0 (0xf7fd3000)
libdl.so.2 => /lib/libdl.so.2 (0x0026b000) libnsl.so.1
=> /lib/libnsl.so.1 (0x00366000) libuuid.so.1 => not found
[...]
So, I have some questions here:
I have both LFC-client installed:
# rpm -qa|grep LFC-client
LFC-client-1.6.11-3sec.slc4.x86_64
LFC-client-1.6.11-3sec.slc4.i386
but they share lfc binaries:
# rpm -qf /opt/lcg/bin/lfc-ls
LFC-client-1.6.11-3sec.slc4.x86_64
LFC-client-1.6.11-3sec.slc4.i386
Is this expected?
And, as in other cases I found, depending in the order you install
those rpm the binary is 32 or 64 bits, which one is the one that we
must install? (Cause if the node is 64 bit it should have 64 bits
binaries, from my point of view)
# file /opt/lcg/bin/lfc-ls
/opt/lcg/bin/lfc-ls: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not
stripped
Anyone noticed it before?
I found thit bug:
https://savannah.cern.ch/bugs/?func=detailitem&item_id=48489 but it
refers to 64 bits tarball... do I have to open a new bug?
Cheers,
Arnau
|