#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 ...
V.
aochkintr commented at 2019-05-08 15:08:¶
@gozora
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.]