New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issues if rear is installed in non-default path #774
Comments
hi again, yes, i know that just executing rear from a cloned repository or extracted archive will work. This however still creates files in /etc/rear/, even if the user does not want it to. Is there a I know the old commit from SEP Sesam broke some Fedora related things :-) |
After some more testing: simply running rear from extracted tar or git checkout solves both problems. I think we can close this here :-) |
@abbbi In usr/sbin/rear there is # Find out if we're running from checkout REAR_DIR_PREFIX="" readonly SCRIPT_FILE="$( readlink -f $( type -p "$0" || echo "$0" ) )" if test "$SCRIPT_FILE" != "$( readlink -f /usr/sbin/$PROGRAM )" ; then REAR_DIR_PREFIX=${SCRIPT_FILE%/usr/sbin/$PROGRAM} fi readonly REAR_DIR_PREFIX # Program directories - they must be set here. Everything else is then dynamic. # Not yet readonly here because they are set via the /etc/rear/rescue.conf file # in the recovery system that is sourced by the rear command in recover mode # and CONFIG_DIR can also be changed via '-c' command line option: SHARE_DIR="$REAR_DIR_PREFIX/usr/share/rear" CONFIG_DIR="$REAR_DIR_PREFIX/etc/rear" VAR_DIR="$REAR_DIR_PREFIX/var/lib/rear" LOG_DIR="$REAR_DIR_PREFIX/var/log/rear" Accordingly if for example $CONFIG_DIR is used in the scripts and no hardcoded "/etc/rear", rear should create files accordingly. It seems currently it is hardcoded in usr/sbin/rear when a non-empty REAR_DIR_PREFIX will be used. I assume you may need to adapt and enhance that for your needs and then verify if a non-empty REAR_DIR_PREFIX will really be used in all the various rear scripts as needed. As far as I see there is a difference if rear runs in its recovery system (basically when "rear recover" is run) in contrast to when rear is run in the original system (e.g. when "rear mkbackup" is run). As far as I see if rear runs in its recovery system then rear should use hardcoded paths like "/etc/rear/" to match the actual direcories in the recovery system. In contrast when rear is run in the original system it should consistently use REAR_DIR_PREFIX where appropriate. |
@abbbi As far as I see your #774 (comment) proves that rear works correctly when a non-empty REAR_DIR_PREFIX is used. Accordingly I think all what you still may need to make rear working perfectly for your use-case is to to adapt and enhance the current hardcoded magic in usr/sbin/rear when a non-empty REAR_DIR_PREFIX will be used. |
In recovery mode the |
hi there,
im struggeling to get rear correctly working on a non-standard installation path.
Im using the DESTDIR= parameter to install rear into another path than usually, that results in some
issues which should at least be discussed.
For example, installing rear into /opt/rear/ with the following command:
make install DESTDIR=/opt/rear/
will result in the following error:
linux-fhta:~/rear # /opt/rear/usr/sbin/rear mkrescue -v
/opt/rear/usr/sbin/rear: line 282: /usr/share/rear/conf/default.conf: No such file or directory
/opt/rear/usr/sbin/rear: line 290: IsInArray: command not found
/opt/rear/usr/sbin/rear: line 296: has_binary: command not found
ERROR: Required program 'pidof' missing, please check your PATH
Issue is that the Makefile does not use the DESTDIR parameter in all places to replace the paths within the rear exectuable. I think i have created a patch for this sometime in the past and it was reverted as it lead to break rear in other modules or situations, the diff is one like this:
Is there another way to install REAR into a non-default path than using DESTDIR=?
Another problem is that with a recent change, the "os.conf" file is allways forcibly installed into the /etc/rear directory of the resulting image. This causes rear to not find the os.conf configuration file and exit upon execution during recovery. One has to copy the os.conf configuration file within the recovery image from /etc/rear/os.conf to $DESTDIR/etc/rear/os.conf:
The text was updated successfully, but these errors were encountered: