Missing libraries in Rescue ISO causing executables to fail

[rmetrich]

• ReaR version ("/usr/sbin/rear -V"): 2.4 master

• OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): RHEL7

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

COPY_AS_IS+=( /non-standard-dir/lib64/* )
#PROGS+=( /lib/udev/rename_device )

• Description of the issue (ideally so that others can reproduce it):

When adding programs into the Rescue ISO using COPY_AS_IS (typically done when using NetBackup in real life) and the directories specified contain files with same names as standard libraries (but likely at different version), the corresponding standard libraries are not included, causing some binaries that are added anyway to not be usable.
The related code is /usr/share/rear/build/GNU/Linux/100_copy_as_is.sh.
However, if a program is specified using PROG, then the required system libraries will be included anyway, because there is additional code running in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh.

Reproducer

Create a non standard path and copy "libglib" into it:

# mkdir -p /non-standard-dir/lib64
# cp /lib64/libglib-2.0.so.0 /non-standard-dir/lib64/

# rear -dD mkrescue
...
There are binaries or libraries in the ReaR recovery system that need additional libraries
/usr/lib/udev/rename_device requires additional libraries
	libglib-2.0.so.0 => not found
/usr/lib/udev/udev-kvm-check requires additional libraries
	libglib-2.0.so.0 => not found
...

# find /tmp/rear.* -name "libglib*"
/tmp/rear.gg4yN2RSDWWhD1M/rootfs/non-standard-dir/lib64/libglib-2.0.so.0

We can see from there that libglib-2.0.so.0 was not included, even though it's a must for /usr/lib/udev/rename_device.

I'm currently investigating this.

[jsmeix]

@rmetrich
again many thanks for your continuous and careful testing
that reveals such hidden bugs that only happen in special cases!

[jsmeix]

@rmetrich
I wonder about your reproducer:
I think one cannot "just change" the actual libraries files
without also adapting the dynamic linker configuration
i.e. adapt dynamic linker config files like /etc/ld.so.conf
and finally run ldconfig - or do I misunderstand it?

[rmetrich]

That's just an example. In real life, this happens when doing relaxed COPY_AS_IS such as the one done for ... NetBackup ... : /usr/openv/lib which contains unrelated libraries and probably unneeded ones.

[jsmeix]

@rmetrich
your #1976 explains it all.
It is a generic bug in ReaR.

[jsmeix]

With #1976 merged
this issue should be fixed.

@rmetrich
many thanks for your analysis what the root cause was and your fix!

[jsmeix]

I found a simple reproducer that emphasizes
this generic bug (before the fix here) even more.

I only added to my etc/rear/local.conf

COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/sbin/postfix /doesnotexist/usr/lib/postfix/libpostfix-global.so )

and "rear -D mkrescue" failed with

Testing that the recovery system in /tmp/rear.8eGP5wvyks7HAf1/rootfs contains a usable system
There are binaries or libraries in the ReaR recovery system that need additional libraries
/bin/postfix requires additional libraries (fatal error)
        libpostfix-global.so => not found
ReaR recovery system in '/tmp/rear.8eGP5wvyks7HAf1/rootfs' needs additional libraries, check /root/rear.github.master/var/log/rear/rear-g243.log for details
ERROR: ReaR recovery system in '/tmp/rear.8eGP5wvyks7HAf1/rootfs' not usable (required libraries are missing)

For me ldd /usr/sbin/postfix shows in particular

libpostfix-global.so => /usr/lib/postfix/libpostfix-global.so

but copying /usr/lib/postfix/libpostfix-global.so is skipped
in build/GNU/Linux/100_copy_as_is.sh because
the copy_as_is_filelist_file contains

tar: /doesnotexist/usr/lib/postfix/libpostfix-global.so: Cannot stat: No such file or directory

cf. the comment in build/GNU/Linux/100_copy_as_is.sh about
"make it work fail-safe even in case of non-existent files in the COPY_AS_IS array"

I.e. even files that failed to copy may have matched before this fix here.

[rmetrich]

Good point!