#1557 PR merged: This patch correct behavior during symlink creation process of /usr/lib*

Labels: bug, fixed / solved / done

gozora opened issue at 2017-10-29 12:55:

If symlink (in /usr) points to relative target on original system, it will be incorrectly
recreated in ReaR recovery system.
This applies to links in other than root (/)
c.f. Issue https://github.com/rear/rear/issues/1555

I've omitted use of ln and later "guesswork" and rather used cp to copy original symlink "as is".

gozora commented at 2017-10-31 11:57:

@gdha yes, for me it worked just fine ...


aochkintr commented at 2019-05-08 15:08:

got same ( similar) failure with rear v2.4 -soem detail are below
more logs are available
-Andy ( first time user of ReaR)

+++++++  excerpt from    /var/log/rear/rear-aragorn.log

ReaR2019-05-08 09:29:48.969211462 Including build/default/960_remove_encryption_keys.sh
ReaR2019-05-08 09:29:48.974476692 Including build/default/970_add_rear_release.sh
ReaR2019-05-08 09:29:48.981849145 Including build/default/980_verify_rootfs.sh
ReaR2019-05-08 09:29:48.990485974 Testing that /tmp/rear.xFM4znPxHfr26uX/rootfs contains a usable s ystem
ReaR2019-05-08 09:29:48.996730694 Testing 'ldd /bin/bash' to ensure 'ldd' works for the subsequent  'ldd' tests
chroot: failed to run command '/bin/ldd': No such file or directory
ReaR2019-05-08 09:29:49.002383819 ERROR:
BUG in /usr/share/rear/build/default/980_verify_rootfs.sh line 29:
'ReaR recovery system in '/tmp/rear.xFM4znPxHfr26uX/rootfs' is broken: 'ldd /bin/bash' failed'

[Export of Github issue for rear/rear.]