#3356 PR merged: In 100_copy_as_is.sh error out if symlinking VAR_DIR SHARE_DIR fails

Labels: bug, fixed / solved / done

jsmeix opened issue at 2024-12-04 14:22:

  • Type: Bug Fix

  • Impact: Low

coreutils 8.16 was released in 2012 so the '-r' option
should be supported since more than 10 years
so it is unlikely that someone is actually hit by it
BUT
some older Linux distributions with rather old coreutils
may still be in use somewhere so it is good to care about
this possible error because when 'ln' fails here, the
consequence is severe (recovery system startup fails)
and it shows up (too) late (at "rear recover" time)
AND
this issue is introduced in ReaR 2.8 by
https://github.com/rear/rear/pull/3206
so it could be considered as a regression in ReaR 2.8

  • Reference to related issue (URL):

https://github.com/rear/rear/pull/3206
therein
https://github.com/rear/rear/pull/3206#discussion_r1868998080
and subsequent comments

  • How was this pull request tested?

Tested on SLES11-SP4 where 'ln' from coreutils 8.12
does not support the '-r/--relative' option
which is supported since coreutils 8.16

Also tested on a system where 'ln' supports '-r'
i.e. on SLES15-SP6 with coreutils 8.32

  • Description of the changes in this pull request:

In build/GNU/Linux/100_copy_as_is.sh
failsafe symlinking of VAR_DIR and SHARE_DIR
and error out if symlinking fails because
with non-default VAR_DIR and/or SHARE_DIR
(e.g. when running from checkout)
it is mandatory that in the ReaR recovery system
all ReaR files are accessible via the default
/var/lib/rear and /usr/share/rear directories,
see https://github.com/rear/rear/pull/3206

jsmeix commented at 2024-12-05 09:10:

@rear/contributors
provided there are no objections,
I would like to merge it tomorrow afternoon

jsmeix commented at 2024-12-06 12:23:

Just merged "bona fide" without further testing
(that all CI tests passed indicates it is OK)
so I had only tested the initial changes
https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e

I adapted
https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8
where I had tested things only with the initial changes
https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e

jsmeix commented at 2024-12-06 12:27:

To be on the safe side to avoid that pull request commits
may somehow get lost in GitHub as reference here
my initial changes in this pull request
https://github.com/rear/rear/commit/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e

# Symlinking non-default VAR_DIR and SHARE_DIR to defaults (e.g. when running from checkout or REAR_VAR configuration):
Log "In ReaR recovery system symlinking non-default VAR_DIR and SHARE_DIR to defaults if needed (e.g. when running from checkout)"
# When running with non-default VAR_DIR and/or SHARE_DIR it is mandatory that in the ReaR recovery system
# all ReaR files are accessible via the default /var/lib/rear and /usr/share/rear directories - otherwise
# the ReaR recovery system startup fails in usr/share/rear/skel/default/etc/scripts/system-setup with
# "ERROR: ReaR recovery cannot work without /usr/share/rear/conf/default.conf"
# so we error out if making a needed symlink fails.
# On old systems with /bin/ln from coreutils < 8.16 'ln' did not support the '-r/--relative' option
# but a relative symlink is needed in portable mode, see https://github.com/rear/rear/pull/3206
if ! test "$VAR_DIR" = /var/lib/rear ; then
    Log "In ReaR recovery system make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
    if ! ln -v -srf "$ROOTFS_DIR/$VAR_DIR" $ROOTFS_DIR/var/lib/rear ; then
        is_true "$PORTABLE" && Error "Failed to make relative symlink (needed in portable mode) /var/lib/rear to VAR_DIR '$VAR_DIR'"
        Log "'ln -srf VAR_DIR' failed, trying without '-r' option"
        ln -v -sf "$VAR_DIR" $ROOTFS_DIR/var/lib/rear || Error "Failed to make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
    fi
fi
if ! test "$SHARE_DIR" = /usr/share/rear ; then
    Log "In ReaR recovery system make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
    if ! ln -v -srf "$ROOTFS_DIR/$SHARE_DIR" $ROOTFS_DIR/usr/share/rear ; then
        is_true "$PORTABLE" && Error "Failed to make relative symlink (needed in portable mode) /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
        Log "'ln -srf SHARE_DIR' failed, trying without '-r' option"
        ln -v -sf "$SHARE_DIR" $ROOTFS_DIR/usr/share/rear || Error "Failed to make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
    fi
fi

versus the finally merged changes
https://github.com/rear/rear/commit/780140679cfc88b1f329d354202266e936926c78

# Symlinking non-default VAR_DIR and SHARE_DIR to defaults (e.g. when running from checkout or REAR_VAR configuration):
Log "In ReaR recovery system symlinking non-default VAR_DIR and SHARE_DIR to defaults if needed (e.g. when running from checkout)"
# When running with non-default VAR_DIR and/or SHARE_DIR it is mandatory that in the ReaR recovery system
# all ReaR files are accessible via the default /var/lib/rear and /usr/share/rear directories - otherwise
# the ReaR recovery system startup fails in usr/share/rear/skel/default/etc/scripts/system-setup with
# "ERROR: ReaR recovery cannot work without /usr/share/rear/conf/default.conf"
# so we error out if making a needed symlink fails.
# On old systems with /bin/ln from coreutils < 8.16 'ln' did not support the '-r/--relative' option
# but a relative symlink is needed in portable mode, see https://github.com/rear/rear/pull/3206
if ! test "$VAR_DIR" = /var/lib/rear ; then
    Log "In ReaR recovery system make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
    ln -v -srf "$ROOTFS_DIR/$VAR_DIR" $ROOTFS_DIR/var/lib/rear || Error "Failed to symlink /var/lib/rear to '$VAR_DIR'"
fi
if ! test "$SHARE_DIR" = /usr/share/rear ; then
    Log "In ReaR recovery system make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
    ln -v -srf "$ROOTFS_DIR/$SHARE_DIR" $ROOTFS_DIR/usr/share/rear || Error "Failed to symlink /usr/share/rear to '$SHARE_DIR'"
fi

schlomo commented at 2024-12-09 09:15:

Thank you very much @jsmeix

[Export of Github issue for rear/rear.]