#2129 Issue `closed`: 985_fix_broken_links.sh misses relative links¶

Labels: enhancement, bug, fixed / solved / done

OliverO2 opened issue at 2019-04-29 16:46:¶

ReaR version ("/usr/sbin/rear -V"): 2.4 / Git (f3157906)
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Ubuntu 18.04.2 LTS
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86 compatible

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

Log file entry:

Broken symlink './usr/share/misc/magic' in recovery system because 'readlink' cannot determine its link target

Original system:

# readlink /usr/share/misc/magic
../file/magic
# ls -ld /usr/share/file/magic
drwxr-xr-x 1 root root 0 Feb 13  2018 /usr/share/file/magic/

jsmeix commented at 2019-04-30 07:48:¶

The matching code in build/default/985_fix_broken_links.sh is

pushd $ROOTFS_DIR
    ...
        link_target=$( readlink $v -e $broken_symlink )
        if test "$link_target" ; then
            ...
        else
            LogPrintError "Broken symlink '$broken_symlink' in recovery system because 'readlink' cannot determine its link target"
        fi

I wonder what I should do when readlink cannot determine the link target?
I think when I get no link target I cannot fix the broken symlink?

jsmeix commented at 2019-04-30 08:15:¶

By the way:
Had I already stated somewhere that "I hate symlinks !" ?
;-)
This "fix symlinks in the recovery system" issue wasted already so much time...

OliverO2 commented at 2019-04-30 08:27:¶

I wonder what I should do when readlink cannot determine the link target?
I think when I get no link target I cannot fix the broken symlink?

In the above case, my ls -ld shows that the link target exists. 985_fix_broken_links.sh currently interprets all relative links relative to its own current directory (which is $ROOTFS_DIR). It must interpret each relative link relative to the path of its link source on the original and target system.

You might try this:

        [...]
        link_target=$( readlink $v -e $broken_symlink )
        if [[ "$link_target" != /* ]]; then
            link_target="$broken_symlink/$link_target"
        fi
        if test "$link_target" ; then
        [...]

Actually, your 985_fix_broken_links.sh might be more useful than you think. More on that later.

OliverO2 commented at 2019-04-30 08:32:¶

I see, the above won't work as your find does a relative search. If you'd change this to an absolute search, then do the above test, and then strip the leading / everything should be fine. I could test it this, but no earlier than late afternoon.

jsmeix commented at 2019-04-30 08:43:¶

No rush - take your time...

OliverO2 commented at 2019-04-30 12:48:¶

On the value of copying symbolic link targets in ReaR:

It helps on Debian systems, where custom configuration packages modify configuration files from distribution packages. The MIT's project Athena has created a special framework config-package-dev to support this. After installing a configuration package, it typically looks like this:

$ ls -l /etc/ldap/ldap.conf*
lrwxrwxrwx 1 root root  19 2007-08-13 17:07 /etc/ldap/ldap.conf -> ldap.conf.debathena
-rw-r--r-- 1 root root 347 2007-08-15 17:58 /etc/ldap/ldap.conf.debathena
-rw-r--r-- 1 root root 333 2007-08-13 17:27 /etc/ldap/ldap.conf.debathena-orig

There are sound reasons why the config-package-dev framework relies heavily on symbolic links:

Using a symlink here rather than a direct replacement is necessary for technical reasons related to how Debian unpacks files. The diversion system in config-package-dev has been carefully tested to support uninstallation, upgrades, and cleanly recovering from when you hit ^C in the middle of installing something (or installation fails for some other reason).

With respect to ReaR it means that vital configuration files (such as /etc/ssh/sshd_config) might be relative symbolic links. It is then much easier for the user if these just work and she doesn't need to care about which extra files to include.

jsmeix commented at 2019-04-30 14:13:¶

@OliverO2
Wow!
Impressive what you achieved "no earlier than late afternoon" ;-)

jsmeix commented at 2019-05-03 12:16:¶

With https://github.com/rear/rear/pull/2131 merged this issue is fixed.

[Export of Github issue for rear/rear.]

#2129 Issue closed: 985_fix_broken_links.sh misses relative links¶