[Rear-users] Fwd: Re: Problems with multiple libraries ...

Peter Eckhardt peter at linux-freelancer.net
Mon Apr 20 11:41:15 CEST 2009



----- Weitergeleitete Nachricht von peter at linux-freelancer.net -----
      Datum: Mon, 20 Apr 2009 11:40:18 +0200
        Von: Peter Eckhardt <peter at linux-freelancer.net>
Antwort an: Peter Eckhardt <peter at linux-freelancer.net>
    Betreff: Re: [Rear-users] Problems with multiple libraries ...
         An: Schlomo Schapiro <schlomo at schapiro.org>

Hello Schlomo,

1.) Problem with library and symlink
====================================

ohne COPY_AS_IS_TSM --->


# sample local configuration

# Create ReaR rescue media as ISO image
OUTPUT=ISO

# optionally set your backup software
BACKUP=TSM

# the following is required on older VMware VMs
# MODULES_LOAD=( vmxnet )


usr/sbin/rsct/lib/libct_tr.so /usr/sbin/rsct/lib/libha_gs_r.so
cp: `/usr/sbin/rsct/lib/libct_cu.so' and
`/tmp/rear.5342/rootfs/lib/libct_cu.so' are the same file
2009-04-20 10:50:40 ERROR [LipCopyTo] Could not copy
'/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.5342/rootfs/lib'

mit COPY_AS_IS_TSM --->

# sample local configuration

# Create ReaR rescue media as ISO image
OUTPUT=ISO

# optionally set your backup software
BACKUP=TSM
COPY_AS_IS_TSM=( /etc/adsm/TSM.PWD /opt/tivoli/tsm/client )

# the following is required on older VMware VMs
# MODULES_LOAD=( vmxnet )


/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.7
/usr/sbin/rsct/lib/libct_cu.so /usr/sbin/rsct/lib/libct_tr.so
/usr/sbin/rsct/lib/libha_gs_r.so
cp: `/usr/sbin/rsct/lib/libct_cu.so' and
`/tmp/rear.8919/rootfs/lib/libct_cu.so' are the same file
2009-04-20 10:55:27 ERROR [LipCopyTo] Could not copy
'/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.8919/rootfs/lib'

---------------------

machine:/ # find . -name "*libct_cu.so"
./tmp/rear.5342/rootfs/lib/libct_cu.so
./tmp/rear.5342/rootfs/opt/tivoli/tsm/client/api/bin/libct_cu.so
./tmp/rear.8919/rootfs/lib/libct_cu.so
./tmp/rear.8919/rootfs/opt/tivoli/tsm/client/api/bin/libct_cu.so
./usr/lib/libct_cu.so
./usr/sbin/rsct/lib/libct_cu.so
./opt/tivoli/tsm/client/api/bin/libct_cu.so

s96sanpns00:/ # ls -l /usr/lib/libct_cu.so
lrwxrwxrwx 1 bin bin 30 Mar 12 10:38 /usr/lib/libct_cu.so ->
/usr/sbin/rsct/lib/libct_cu.so

ls -l /usr/sbin/rsct/lib/libct_cu.so
-r--r--r-- 1 bin bin 595453 May 20  2008 /usr/sbin/rsct/lib/libct_cu.so

ls -l /opt/tivoli/tsm/client/api/bin/libct_cu.so
-r-xr-xr-x 1 root bin 334774 Nov 28 16:19
/opt/tivoli/tsm/client/api/bin/libct_cu.so

ldd /usr/bin/dsmc
          linux-gate.so.1 =>  (0xffffe000)
          libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f64000)
          libpthread.so.0 => /lib/libpthread.so.0 (0xf7f4e000)
          libdl.so.2 => /lib/libdl.so.2 (0xf7f4a000)
          libgpfs.so => /usr/lib/libgpfs.so (0xf7f41000)
          libdmapi.so => /usr/lib/libdmapi.so (0xf7f3a000)
          librt.so.1 => /lib/librt.so.1 (0xf7f31000)
          libha_gs_r.so => /usr/lib/libha_gs_r.so (0xf7f08000)
          libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7e4c000)
          libm.so.6 => /lib/libm.so.6 (0xf7e27000)
          libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e1c000)
          libc.so.6 => /lib/libc.so.6 (0xf7cef000)
          /lib/ld-linux.so.2 (0xf7fa6000)
          libct_cu.so => /usr/lib/libct_cu.so (0xf7c89000)
          libct_tr.so => /usr/lib/libct_tr.so (0xf7c7e000)

In this case problem is the symlink. Fisrt the "contents" of the
symlink is copied

2009-04-20 10:55:27 Libraries(32): /lib/libnss_dns-2.4.so
/lib/libnss_dns.so.2 /lib/libnss_files-2.4.so /lib/libnss_files.so.2
/lib/libgcc_s.so.1 /lib/libresolv-2.4.so /lib/libresolv.so.2
/lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
/lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
/lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
/lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
/lib/librt.so.1
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libApiDS.so
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libxerces-c1_6_0.so
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libxmlutil-5.5.1.0.so
/usr/lib/libApiDS.so /usr/lib/libct_cu.so /usr/lib/libct_tr.so
/usr/lib/libdmapi.so /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
/usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5.0.7 /usr/lib/libtsm551xerces-c1_6_0.so
/usr/lib/libxmlutil-5.5.1.0.so /usr/sbin/rsct/lib/libct_cu.so
/usr/sbin/rsct/lib/libct_tr.so /usr/sbin/rsct/lib/libha_gs_r.so
/lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
/lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
/lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
/lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
/lib/librt.so.1 /usr/lib/libct_cu.so /usr/lib/libct_tr.so
/usr/lib/libdmapi.so /usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
/usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.7
/usr/sbin/rsct/lib/libct_cu.so /usr/sbin/rsct/lib/libct_tr.so
/usr/sbin/rsct/lib/libha_gs_r.so
cp: `/usr/sbin/rsct/lib/libct_cu.so' and
`/tmp/rear.8919/rootfs/lib/libct_cu.so' are the same file
2009-04-20 10:55:27 ERROR [LipCopyTo] Could not copy
'/usr/sbin/rsct/lib/libct_cu.so' to '/tmp/rear.8919/rootfs/lib'

First /usr/lib/libct_cu.so is copied then
/usr/sbin/rsct/lib/libct_cu.so which fails because the symlink was
copied.

2.) Same problem different results
===================================

# sample local configuration

# Create ReaR rescue media as ISO image
OUTPUT=ISO

# optionally set your backup software
BACKUP=TSM
COPY_AS_IS_TSM=( /etc/adsm/TSM.PWD /opt/tivoli/tsm/client )
# the following is required on older VMware VMs
# MODULES_LOAD=( vmxnet )


2009-04-20 11:29:35 Libraries(32): /lib/libnss_dns-2.4.so
/lib/libnss_dns.so.2 /lib/libnss_files-2.4.so /lib/libnss_files.so.2
/lib/libgcc_s.so.1 /lib/libresolv-2.4.so /lib/libresolv.so.2
/lib/ld-2.4.so /lib/ld-linux.so.2 /lib/libc-2.4.so /lib/libc.so.6
/lib/libcrypt-2.4.so /lib/libcrypt.so.1 /lib/libdl-2.4.so
/lib/libdl.so.2 /lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
/lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
/lib/librt.so.1
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libApiDS.so
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libxerces-c1_6_0.so
/usr/lib/../../opt/tivoli/tsm/client/api/bin/libxmlutil-5.5.1.0.so
/usr/lib/libApiDS.so /usr/lib/libct_cu.so /usr/lib/libdmapi.so
/usr/lib/libgpfs.so /usr/lib/libha_gs_r.so
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
/usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5.0.7 /usr/lib/libtsm551xerces-c1_6_0.so
/usr/lib/libxmlutil-5.5.1.0.so /lib/ld-2.4.so /lib/ld-linux.so.2
/lib/libc-2.4.so /lib/libc.so.6 /lib/libcrypt-2.4.so
/lib/libcrypt.so.1 /lib/libdl-2.4.so /lib/libdl.so.2
/lib/libgcc_s.so.1 /lib/libm-2.4.so /lib/libm.so.6
/lib/libpthread-2.4.so /lib/libpthread.so.0 /lib/librt-2.4.so
/lib/librt.so.1 /opt/tivoli/tsm/client/api/bin/libgpfs.so
/usr/lib/libct_cu.so /usr/lib/libdmapi.so /usr/lib/libgpfs.so
/usr/lib/libha_gs_r.so /usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5.0.7
cp: `/opt/tivoli/tsm/client/api/bin/libgpfs.so' and
`/tmp/rear.16149/rootfs/lib/libgpfs.so' are the same file
2009-04-20 11:29:35 ERROR [LipCopyTo] Could not copy
'/opt/tivoli/tsm/client/api/bin/libgpfs.so' to
'/tmp/rear.16149/rootfs/lib'

machine2:/ # find . -name "*libgpfs.so"
./tmp/rear.16149/rootfs/lib/libgpfs.so
./tmp/rear.16149/rootfs/opt/tivoli/tsm/client/api/bin/libgpfs.so
./opt/tivoli/tsm/client/api/bin/libgpfs.so
./usr/lib/libgpfs.so

machine2:/ # ldd /usr/bin/dsmc
          linux-gate.so.1 =>  (0xffffe000)
          libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f2f000)
          libpthread.so.0 => /lib/libpthread.so.0 (0xf7f19000)
          libdl.so.2 => /lib/libdl.so.2 (0xf7f15000)
          libgpfs.so => /usr/lib/libgpfs.so (0xf7f0c000)
          libdmapi.so => /usr/lib/libdmapi.so (0xf7f05000)
          librt.so.1 => /lib/librt.so.1 (0xf7efc000)
          libha_gs_r.so => /usr/lib/libha_gs_r.so (0xf7edd000)
          libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7e21000)
          libm.so.6 => /lib/libm.so.6 (0xf7dfc000)
          libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7df1000)
          libc.so.6 => /lib/libc.so.6 (0xf7cc4000)
          /lib/ld-linux.so.2 (0xf7f70000)
          libct_cu.so => /usr/lib/libct_cu.so (0xf7c7a000)

ls -l /opt/tivoli/tsm/client/api/bin/libgpfs.so
-r-xr-xr-x 1 root bin 39165 Nov 28 16:19
/opt/tivoli/tsm/client/api/bin/libgpfs.so .


ls -l /usr/lib/libgpfs.so
lrwxrwxrwx 1 root root 41 Mar  5 07:20 /usr/lib/libgpfs.so ->
/opt/tivoli/tsm/client/api/bin/libgpfs.so

First /usr/lib/libgpfs.so is copied then
/opt/tivoli/tsm/client/api/bin/libgpfs.so .



Hope that helps a bit
Peter



Quoting Schlomo Schapiro <schlomo at schapiro.org>:

> Hi Peter,
>
> that is a much better explanation, let me ask you a few questions:
>
> How would the example of same-named but different libraries work on the
> source system? If such libraries are installed in different directories
> that are part of the library loader path (/etc/ld.so.conf) then AFAIK
> the loader will in any case only take the first and ignore the second. I
> can imagine that it works if some software brings private libraries and
> sets LD_LIBRARY_PATH, thus forcing the loader to consider the private
> libraries first. But in that case ReaR would not pick up these libraries
> in any case because ReaR can find only those libraries that ldd gives us
> which are only those libraries that are mentioned in ld.so.conf.
>
> I already encountered such software (e.g. Galaxy) and the solution was
> to copy all the software with the private libraries through COPY_AS_IS
> which does not resolve any libraries.
>
> To better understand your actual problem, could you please tell us more
> about it with specific examples where you had this problem? With your
> modification I would expect ReaR to fail on that system in any case.
>
> Regards,
> Schlomo
>
> PS: What I am trying to say is that I am not yet convinced that we are
> solving the right problem with this patch.
>
> Peter Eckhardt wrote:
>> Hello,
>>
>> it took a bit to answer. Somehow holidays were more important than rear :-)
>>
>> ReaR has a generic problem if a libary with the same name exists in
>> two different directories. A situation which appears quite regulary if
>> an admin creates compatibility links or two packages bring the same
>> library but decide to have them in different directories.
>> If such a situation arises it makes the creation of the ReaR ISO fail
>> (without error message) in the LibCopyTo function. Problem is the cp
>> command which can't (and shouldn't) overwrite an existing file.
>> Overwriting may lead to the problem that in case two libaries with the
>> same name but different version or different functionality exists only
>> the last one copied will survive. In case of overwriting (i.e the cp
>> command line gets fixed) the cp command will succeed, the creation of
>> the ReaR iso too, but the restore form the iso may fail later due to
>> missing symbols in the library. So i personally prefer an abort of the
>> cp than just a silent overwrite.
>>
>> Thats the reason why i added the cmp command in the proposed fix. It
>> will only copy if the target does not exist or if target and source
>> aren't identical (then the cp will fail).
>>
>>
>> test -r "$k" || Error .....
>> if ! cmp "$TARGET/${basename $k}" "$k"
>> then
>>     cp -v -a ......
>> else
>>     Error "[LibCopyTo] Library $k exists more than one. Contents
>> differs. Aborted"
>> fi
>> test ! -L ......
>>
>> Brgds
>> Peter
>>
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Rear-users mailing list
> Rear-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rear-users
>



-- 
dadi-linux Peter Eckhardt
Gymnasiumstrasse 1
76297 Stutensee-Blankenloch

Fon: +49 7244 559007
Fax: +49 7244 559041

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



----- Ende der weitergeleiteten Nachricht -----


-- 
dadi-linux Peter Eckhardt
Gymnasiumstrasse 1
76297 Stutensee-Blankenloch

Fon: +49 7244 559007
Fax: +49 7244 559041

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.





More information about the rear-users mailing list