#2307 Issue closed: Under special circumstances commands in ReaR scripts are not run under bash (but e.g. under csh)

Labels: enhancement, support / question, minor bug, no-issue-activity

wolfgang6444 opened issue at 2020-01-10 18:47:

Hello,

I am getting the following error message:

ERROR: 
====================
BUG in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
'copy_binaries destination '/tmp/rear.dzUC1mLbi1DfZ8T/rootfs/bin' is not a directory'
--------------------
Please report this issue at https://github.com/rear/rear/issues
2020-01-10 19:27:32.839047632 ERROR:
====================
BUG in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
'copy_binaries destination '/tmp/rear.dzUC1mLbi1DfZ8T/rootfs/bin' is not a directory'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-labpc1.log
preferably with full debug information via 'rear -d -D mkbackup'
====================
==== Stack trace ====
Trace 0: /usr/sbin/rear:543 main
Trace 1: /usr/share/rear/lib/mkbackup-workflow.sh:15 WORKFLOW_mkbackup
Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source
Trace 4: /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh:62 source
Trace 5: /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh:14 copy_binaries
Trace 6: /usr/share/rear/lib/_input-output-functions.sh:428 BugError
Message:
====================
BUG in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
'copy_binaries destination '/tmp/rear.dzUC1mLbi1DfZ8T/rootfs/bin' is not a directory'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-labpc1.log
preferably with full debug information via 'rear -d -D mkbackup'
====================
== End stack trace ==
2020-01-10 19:27:32.848092905 Exiting rear mkbackup (PID 2929) and its descendant processes
2020-01-10 19:27:33.900679321 rear,2929 /usr/sbin/rear -v mkbackup
  `-rear,6205 /usr/sbin/rear -v mkbackup
      `-pstree,6206 -Aplau 2929
/usr/share/rear/lib/_input-output-functions.sh: line 157: kill: (6209) - No such process
2020-01-10 19:27:33.919365399 Running exit tasks
2020-01-10 19:27:33.920837456 Finished in 7 seconds
2020-01-10 19:27:33.922313608 Removing build area /tmp/rear.dzUC1mLbi1DfZ8T
removed directory '/tmp/rear.dzUC1mLbi1DfZ8T'
2020-01-10 19:27:33.941118026 End of program reached

Many thanks,

Wolfgang

jsmeix commented at 2020-01-13 08:23:

@wolfgang6444
what about your

full debug information via 'rear -d -D mkbackup'

and the usually needed general information
https://raw.githubusercontent.com/rear/rear/master/.github/ISSUE_TEMPLATE.md
that you get shown when you click on [New issue] on
https://github.com/rear/rear/issues

wolfgang6444 commented at 2020-01-14 18:19:

O.k. here is the missing info:

usr/sbin/rear -V
Relax-and-Recover 2.4 / Git

cat /etc/rear/os.conf
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=8

cat /etc/rear/local.conf
# cat local.conf
export TMPDIR="/tmp"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
OUTPUT=ISO
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" ntfsclone hexedit emacs)
#COPY_AS_IS=( "${COPY_AS_IS[@]}" "/sbin/ntfsclone /bin/hexedit /bin/emacs" )
COPY_AS_IS=( "${COPY_AS_IS[@]}" '/bin/hexedit /usr/libexec/emacs/*/*/* /usr/share/emacs/*/*/*')
OUTPUT_URL=file:///mnt/backup/rear/
BACKUP=NETFS
#BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=file:///mnt/backup/rear/
NETFS_KEEP_OLD_BACKUP_COPY=yes
BACKUP_PROG_EXCLUDE=( '/run/media/*' '/scr/*' '/tmp/*' '/mnt/backup/*' '/dev/*' '/video/*' )

Hardware is physical x86

Bootloader : grub2, UEFI

local-disks

lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                    KNAME     PKNAME    TRAN   TYPE FSTYPE        SIZE MOUNTPOINT
/dev/sda                /dev/sda            sata   disk               1.8T
|-/dev/sda1             /dev/sda1 /dev/sda         part vfat            1G /boot/efi
|-/dev/sda2             /dev/sda2 /dev/sda         part ext4            1G /boot
|-/dev/sda3             /dev/sda3 /dev/sda         part LVM2_member  57.9G
| |-/dev/mapper/cl-root /dev/dm-0 /dev/sda3        lvm  xfs            50G /
| `-/dev/mapper/cl-swap /dev/dm-1 /dev/sda3        lvm  swap          7.9G [SWAP]
`-/dev/sda4             /dev/sda4 /dev/sda         part ext4          200G /var/lib/libvirt/images
/dev/sdb                /dev/sdb            sata   disk             931.5G
|-/dev/sdb1             /dev/sdb1 /dev/sdb         part vfat          500M
|-/dev/sdb2             /dev/sdb2 /dev/sdb         part ntfs         96.7G
`-/dev/sdb3             /dev/sdb3 /dev/sdb         part ntfs          468M
/dev/sr0                /dev/sr0            sata   rom               1024M

rear -d -D 'mkbackup'
Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-labpc1.log
Using backup archive '/mnt/backup/rear//labpc1/backup.tar.gz'
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Creating disk layout
Excluding component fs:/mnt/backup
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Creating root filesystem layout
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/centos/grubx64.efi' as UEFI bootloader file
Copying logfile /var/log/rear/rear-labpc1.log into initramfs as '/tmp/rear-labpc1-partial-2020-01-14T19:14:28+01:00.log'
Copying files and directories
Copying binaries and libraries
ERROR:
====================
BUG in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
'copy_binaries destination '/tmp/rear.5dKsEA56dwxIt31/rootfs/bin' is not a directory'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-labpc1.log
preferably with full debug information via 'rear -d -D mkbackup'
====================
Aborting due to an error, check /var/log/rear/rear-labpc1.log for details
Exiting rear mkbackup (PID 30626) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.5dKsEA56dwxIt31
Terminated

Wolfgang

jsmeix commented at 2020-01-15 08:16:

@wolfgang6444
we need your actual log file /var/log/rear/rear-labpc1.log cf.

rear -d -D 'mkbackup'
Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-labpc1.log
...
... include the relevant parts from /var/log/rear/rear-labpc1.log

to be able to analyze what caused that BugError in your particular case.
Your terminal output does not show anything that could be the reason.

jsmeix commented at 2020-01-15 08:18:

@rmetrich @pcahyna
FYI because this one is about RHEL8
perhaps you could also have a look here
(of course only as your time permits).

wolfgang6444 commented at 2020-01-15 19:41:

here is the required log-file.
Where should I look?

Wolfgang

Uploading rear-labpc1.log…

wolfgang6444 commented at 2020-01-15 19:44:

uploading does not seem to work ...
here is another attempt ...

rear-labpc1.log

wolfgang6444 commented at 2020-01-16 12:29:

Why is this closed?

rmetrich commented at 2020-01-16 12:30:

I"m looking into this, I guess you closed the issue by mistake when submitting the log.

jsmeix commented at 2020-01-16 12:55:

@wolfgang6444
FYI: This issue was closed because you had closed it by
https://github.com/rear/rear/issues/2307#event-2952088288

rmetrich commented at 2020-01-16 12:57:

Hello,
the issue is there:

+ source /usr/share/rear/build/GNU/Linux/005_create_symlinks.sh
++ ln -sf -v bin/init /tmp/rear.5dKsEA56dwxIt31/rootfs/init
'/tmp/rear.5dKsEA56dwxIt31/rootfs/init' -> 'bin/init'
++ ln -sf -v bin /tmp/rear.5dKsEA56dwxIt31/rootfs/sbin
'/tmp/rear.5dKsEA56dwxIt31/rootfs/sbin' -> 'bin' 
++ ln -sf -v bash /tmp/rear.5dKsEA56dwxIt31/rootfs/bin/sh
ln: failed to create symbolic link '/tmp/rear.5dKsEA56dwxIt31/rootfs/bin/sh': No such file or directory

It's not related to having RHEL8. Apparently there is a bin file from your system being integrated into the ISO as /tmp/rear.XXX/rootfs/bin.

It's unclear to me how this happens. I can see that your COPY_AS_IS variable is broken (see the single quotes) but I cannot reproduce with latest ReaR 2.5:

COPY_AS_IS=( "${COPY_AS_IS[@]}" '/bin/hexedit /usr/libexec/emacs/*/*/* /usr/share/emacs/*/*/*')

should be

COPY_AS_IS=( "${COPY_AS_IS[@]}" /bin/hexedit /usr/libexec/emacs/*/*/* /usr/share/emacs/*/*/*)

Note that including emacs in the ISO along with hexedit looks odd to me, this COPY_AS_IS variable isn't necessary since you already added these as REQUIRED_PROGS

jsmeix commented at 2020-01-16 13:15:

From a quick look at
https://github.com/rear/rear/files/4067155/rear-labpc1.log
I guess

+ source /usr/share/rear/rescue/default/010_merge_skeletons.sh
++ LogPrint 'Creating root filesystem layout'
...
++ Log 'Adding '\''default'\'''
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ local 'timestamp=2020-01-14 19:14:27.562949775 '
++ test 1 -gt 0
++ echo '2020-01-14 19:14:27.562949775 Adding '\''default'\'''
2020-01-14 19:14:27.562949775 Adding 'default'
++ tar -C default -c .
++ tar -C /tmp/rear.5dKsEA56dwxIt31/rootfs -xv
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

points to the root cause.

For comparison on my openSUSE Leap 15.0 system
where it works for me with current ReaR master code I get

+ source /root/rear.github.master/usr/share/rear/rescue/default/010_merge_skeletons.sh
++ LogPrint 'Creating root filesystem layout'
...
++ Log 'Adding '\''default'\'''
++ echo '2020-01-16 13:58:20.856116395 Adding '\''default'\'''
2020-01-16 13:58:20.856116395 Adding 'default'
++ tar -C default -c .
++ tar -C /tmp/rear.FVc35OU0oJxtZwU/rootfs -xv

jsmeix commented at 2020-01-16 13:20:

@rmetrich
I did my last comment in parallel with your previous comment
(i.e. I did not read your comment while I made mine)
so perhaps your's is the actual root cause
or both are even somehow related.

jsmeix commented at 2020-01-16 13:22:

@rmetrich
do you think "rear mkrescue" should error out in
usr/share/rear/rescue/default/010_merge_skeletons.sh
when it failed to at least copy the default stuff
instead of ignoring such errors and blindly proceed there
and let things fail later at another place?

wolfgang6444 commented at 2020-01-16 19:13:

I tried to comment out

COPY_AS_IS= ...
and
BACKUP_PROG_EXCLUDE=...

in /etc/rear/local.conf

=> no change in behaviour

wolfgang6444 commented at 2020-01-20 08:56:

Any news?
Anything I should try?

Kind regards,

Wolfgang

rmetrich commented at 2020-01-20 10:10:

Hi @wolfgang6444 , could you provide the output of

# ls -l /tmp/rear.XXX/rootfs/

Where XXX is the temporary directory used by ReaR.

wolfgang6444 commented at 2020-01-20 18:01:

Hello,

pwd
/tmp/rear.5dKsEA56dwxIt31/rootfs
[root@labpc1 rootfs]# ls -ltr
total 0
drwxr-xr-x. 5 root root 41 Nov 12 10:59 var
drwxr-xr-x. 4 root root 154 Nov 12 10:59 etc
drwxr-xr-x. 2 root root 63 Jan 14 19:14 tmp
lrwxrwxrwx. 1 root root 8 Jan 14 19:14 init -> bin/init
lrwxrwxrwx. 1 root root 3 Jan 14 19:14 sbin -> bin
lrwxrwxrwx. 1 root root 7 Jan 14 19:14 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 14 19:14 lib64 -> usr/lib64
drwxr-xr-x. 5 root root 45 Jan 14 19:14 usr

updating 010_merge_skeletons.sh did not help.

I will reinstall rear alltogether

Wolfgang

rmetrich commented at 2020-01-21 07:13:

@wolfgang6444 Apparently you don't have the files or directories in /usr/share/rear/skel/default, explaining the issue.
Please try indeed reinstalling ReaR.

wolfgang6444 commented at 2020-01-21 20:16:

O.K.,

so I tried to reinstall rear as rpm from the repo: same behaviour.
so I tried to downloading rear-2.5.tar.gz from soureforge:

make rpm
rm -Rf dist build
rm -f build-stamp
make -C doc clean
make[1]: Entering directory '/scr/rear-2.5/doc'
rm -f unconv.8 *.html *.xml
make -C user-guide clean
make[2]: Entering directory '/scr/rear-2.5/doc/user-guide'
rm -f *.html *.svg *.xml
make[2]: Leaving directory '/scr/rear-2.5/doc/user-guide'
make[1]: Leaving directory '/scr/rear-2.5/doc'
== Validating scripts and configuration ==
find etc/ usr/share/rear/conf/ -name '*.conf' | xargs -n 1 bash -n
bash -n usr/sbin/rear
find . -name '*.sh' | xargs -n 1 bash -O extglob -O nullglob -n
find usr/share/rear -name '*.sh' | grep -v -E '(lib|skel|conf)' | while read FILE ; do \
        num=$(echo ${FILE##*/} | cut -c1-3); \
        if [[ "$num" = "000" || "$num" = "999" ]] ; then \
                echo "ERROR: script $FILE may not start with $num"; \
                exit 1; \
        else \
                if $( grep '[_[:alpha:]]' <<< $num >/dev/null 2>&1 ) ; then \
                        echo "ERROR: script $FILE must start with 3 digits"; \
                        exit 1; \
                fi; \
        fi; \
done
== Prepare manual ==
make -C doc man
make[1]: Entering directory '/scr/rear-2.5/doc'
make[1]: Nothing to be done for 'man'.
make[1]: Leaving directory '/scr/rear-2.5/doc'
== Building archive rear-2.5-git.0.0.unknown ==
rm -Rf build/rear-2.5-git.0.0.unknown
mkdir -p dist build/rear-2.5-git.0.0.unknown
tar -c --exclude-from=.gitignore --exclude=.gitignore --exclude=".??*" * | \
        tar -C build/rear-2.5-git.0.0.unknown -x
tar: .gitignoretar: This does not look like a tar archive
: No such file or directory
tar: Exiting with failure status due to previous errors
tar: Error is not recoverable: exiting now
make: *** [Makefile:170: dist/rear-2.5-git.0.0.unknown.tar.gz] Error 2

what is going on here?

Wolfgang

jsmeix commented at 2020-01-22 09:25:

@wolfgang6444
could you describe what exactly "rear as rpm from the repo" is?
I.e. which exact RPM package, provide the output of

rpm -qip path/to/your/rear.rpm
rpm -q --changelog -p path/to/your/rear.rpm | head

and from what exact repository, i.e. provide appropriate
output from your package installation program
so that @rmetrich has a better chance to imagine
what goes on at your place.

Regarding making things from a tar.gz:
I would instead recommend
"Testing current ReaR upstream GitHub master code"
as described at
https://en.opensuse.org/SDB:Disaster_Recovery
see also
"Version upgrades with Relax-and-Recover" in the same article.

Regarding your current ReaR installation:
What do you have in your usr/share/rear/skel/ directory?
I have what we have at ReaR upstream
https://github.com/rear/rear/tree/master/usr/share/rear/skel
in particular all in usr/share/rear/skel/default
https://github.com/rear/rear/tree/master/usr/share/rear/skel/default

wolfgang6444 commented at 2020-01-22 13:05:

Installed:
rear-2.4-10.el8.x86_64
from
AppStream CentOS-8 - AppStream

rpm -qip /var/cache/PackageKit/8/metadata/AppStream-8-x86_64/packages/rear-2.4-10.el8.x86_64.rpm
Name        : rear
Version     : 2.4
Release     : 10.el8
Architecture: x86_64
Install Date: (not installed)
Group       : Applications/File
Size        : 2148628
License     : GPLv3
Signature   : RSA/SHA256, Thu 05 Dec 2019 04:23:28 AM CET, Key ID 05b555b38483c65d
Source RPM  : rear-2.4-10.el8.src.rpm
Build Date  : Fri 08 Nov 2019 11:52:49 PM CET
Build Host  : x86-01.mbox.centos.org
Relocations : (not relocatable)
Packager    : CentOS Buildsys <bugs@centos.org>
Vendor      : CentOS
URL         : http://relax-and-recover.org/
Summary     : Relax-and-Recover is a Linux disaster recovery and system migration tool
Description :
Relax-and-Recover is the leading Open Source disaster recovery and system
migration solution. It comprises of a modular
frame-work and ready-to-go workflows for many common situations to produce
a bootable image and restore from backup using this image. As a benefit,
it allows to restore to different hardware and can therefore be used as
a migration tool as well.

Currently Relax-and-Recover supports various boot media (incl. ISO, PXE,
OBDR tape, USB or eSATA storage), a variety of network protocols (incl.
sftp, ftp, http, nfs, cifs) as well as a multitude of backup strategies
(incl.  IBM TSM, HP DataProtector, Symantec NetBackup, EMC NetWorker,
Bacula, Bareos, BORG, Duplicity, rsync).

Relax-and-Recover was designed to be easy to set up, requires no maintenance
and is there to assist when disaster strikes. Its setup-and-forget nature
removes any excuse for not having a disaster recovery solution implemented.

Professional services and support are available.

 rpm -q --changelog -p /var/cache/PackageKit/8/metadata/AppStream-8-x86_64/packages/rear-2.4-10.el8.x86_64.rpm | head
* Tue Jun 04 2019 Pavel Cahyna <pcahyna@redhat.com> - 2.4-10
- Apply upstream patch PR1993
  Automatically exclude $BUILD_DIR from the backup
  Resolves: rhbz1677733

* Mon Jun 03 2019 Pavel Cahyna <pcahyna@redhat.com> - 2.4-9
- Update fix for bz#1657725. Previous fix was not correct, bootlist was still
  invoked only with one partition argument due to incorrect array expansion.
  See upstream PR2096, 2097, 2098.

 ls -l /usr/share/rear/skel/
total 0
drwxr-xr-x.  4 root root  28 Jan 22 13:53 BACULA
drwxr-xr-x.  4 root root  28 Jan 22 13:53 BAREOS
drwxr-xr-x.  2 root root  28 Jan 22 13:53 Debian
drwxr-xr-x. 14 root root 144 Jan 22 13:53 default
drwxr-xr-x.  5 root root  39 Jan 22 13:53 DP
drwxr-xr-x.  5 root root  41 Jan 22 13:53 Fedora
drwxr-xr-x.  3 root root  17 Jan 22 13:53 GALAXY
drwxr-xr-x.  3 root root  17 Jan 22 13:53 GALAXY10
drwxr-xr-x.  3 root root  17 Jan 22 13:53 GALAXY7
drwxr-xr-x.  3 root root  17 Jan 22 13:53 Linux-ia64
drwxr-xr-x.  3 root root  17 Jan 22 13:53 Linux-ppc64
drwxr-xr-x.  3 root root  17 Jan 22 13:53 NBKDC
drwxr-xr-x.  4 root root  28 Jan 22 13:53 NBU
drwxr-xr-x.  3 root root  17 Jan 22 13:53 NSR
drwxr-xr-x.  3 root root  17 Jan 22 13:53 OBDR
drwxr-xr-x.  3 root root  17 Jan 22 13:53 OPALPBA
drwxr-xr-x.  4 root root  28 Jan 22 13:53 SESAM

Wolfgang

wolfgang6444 commented at 2020-01-22 13:43:

O.K.
I clone it from github:

git clone https://github.com/rear/rear.git
mv rear rear.github.master
cd rear.github.master
## created simple local.conf, see below ##
usr/sbin/rear -D mkbackup
Relax-and-Recover 2.5 / Git
Running rear mkbackup (PID 20440)
Using log file: /scr/rear.github.master/var/log/rear/rear-labpc1.log
Using backup archive '/mnt/backup/junk/labpc1/backup.tar.gz'
Found EFI system partition /dev/sda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-4.18.0-147.3.1.el8_1.x86_64' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /scr/rear.github.master/var/lib/rear/layout/disklayout.conf
Excluding component fs:/mnt/backup
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Verifying that the entries in /scr/rear.github.master/var/lib/rear/layout/disklayout.conf are correct ...
Creating root filesystem layout
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/centos/grubx64.efi' as UEFI bootloader file
Copying logfile /scr/rear.github.master/var/log/rear/rear-labpc1.log into initramfs as '/tmp/rear-labpc1-partial-2020-01-22T14:38:28+01:00.log'
Copying files and directories
Copying binaries and libraries
ERROR: 
====================
BUG in /scr/rear.github.master/usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
'copy_binaries destination '/tmp/rear.jPSjWoK6t2lLuLb/rootfs/bin' is not a directory'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /scr/rear.github.master/var/log/rear/rear-labpc1.log
preferably with full debug information via 'rear -D mkbackup'
====================
Some latest log messages since the last called script 390_copy_binaries_libraries.sh:
  2020-01-22 14:38:29.238635145 Found binary /sbin/mkfs.xfs
  2020-01-22 14:38:29.240472098 Found binary /sbin/mke2fs
  2020-01-22 14:38:29.242359696 Found binary /sbin/xfs_admin
  2020-01-22 14:38:29.244259082 Found binary /sbin/mkswap
  2020-01-22 14:38:29.246186745 Found binary /sbin/cryptsetup
  2020-01-22 14:38:29.248443115 Found binary /sbin/dmsetup
  2020-01-22 14:38:29.250467490 Found binary /sbin/ldconfig
  2020-01-22 14:38:29.252973788 Binaries being copied: /bin/attr /bin/awk /bin/basename /bin/bash /bin/bc /bin/bzip2 /bin/cat /bin/chacl /bin/chmod /bin/chown /bin/clear /bin/cmp /bin/cp /bin/cpio /bi
Aborting due to an error, check /scr/rear.github.master/var/log/rear/rear-labpc1.log for details
Exiting rear mkbackup (PID 20440) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.jPSjWoK6t2lLuLb
Terminated

cat etc/rear/local.conf 
# This file etc/rear/local.conf is intended for the user's
# manual configuration of Relax-and-Recover (ReaR).
# For configuration through packages and other automated means
# we recommend a separated file named site.conf next to this file
# and leave local.conf as is (ReaR upstream will never ship a site.conf).
# The default OUTPUT=ISO creates the ReaR rescue medium as ISO image.
# You need to specify your particular backup and restore method for your data
# as the default BACKUP=REQUESTRESTORE does not really do that (see "man rear").
# Configuration variables are documented in /usr/share/rear/conf/default.conf
# and the examples in /usr/share/rear/conf/examples/ can be used as templates.
# ReaR reads the configuration files via the bash builtin command 'source'
# so bash syntax like VARIABLE="value" (no spaces at '=') is mandatory.
# Because 'source' executes the content as bash scripts you can run commands
# within your configuration files, in particular commands to set different
# configuration values depending on certain conditions as you need like
# CONDITION_COMMAND && VARIABLE="special_value" || VARIABLE="usual_value"
# but that means CONDITION_COMMAND gets always executed when 'rear' is run
# so ensure nothing can go wrong if you run commands in configuration files.
export TMPDIR="/tmp"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
OUTPUT=ISO
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}")
COPY_AS_IS=( "${COPY_AS_IS[@]}" )
OUTPUT_URL=file:///scr/
BACKUP=NETFS
BACKUP_URL=file:///mnt/backup/junk

Always the same error.
This used to work without problems for years on centos 7
Now it seems to be completely skewed up.

B.T.W: How about a nice little make install or something in the git-repository?

Wolfgang

jsmeix commented at 2020-01-22 14:03:

I guess in your ReaR debug log file you still see something like

2020-01 ... Adding 'default'
++ tar -C default -c .
++ tar -C /tmp/rear.../rootfs -xv
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

cf. https://github.com/rear/rear/issues/2307#issuecomment-575145677

So I guess something could be special with tar on your system?

What do you get for

# mkdir /tmp/testy

# pushd /scr/rear.github.master/usr/share/rear/skel/

# tar -C default -c . | tar -C /tmp/testy -x

# popd

wolfgang6444 commented at 2020-01-22 15:03:

Yes:

2020-01-22 15:59:39.950699024 Adding 'Fedora/default'                                                                                         |sbin/xfs_growfs /sbin/xfs_info /sbin/xfs_repair /usr/libexec/openssh/sftp-server /usr/sbin/rear
++ tar -C Fedora/default -c .                                                                                                                 |2020-01-22 14:06:24.887531386 ERROR:
++ tar -C /tmp/rear.WYNFDt49c3TwV5j/rootfs -xv                                                                                                |====================
tar: This does not look like a tar archive                                                                                                    |BUG in /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh line 14:
tar: Exiting with failure status due to previous errors                                                                                       |'copy_binaries destination '/tmp/rear.ZKPCbIDhIOnAnHR/rootfs/bin' is not a directory'
++ for dir in default "$ARCH" "$OS" "$OS_MASTER_VENDOR/default" "$OS_MASTER_VENDOR_ARCH" "$OS_MASTER_VENDOR_VERSION" "$OS_VENDOR/default" "$O\|--------------------
S_VENDOR_ARCH" "$OS_VENDOR_VERSION" "$BACKUP" "$OUTPUT"

buesser >mkdir /tmp/testy
buesser >pushd /scr/rear.github.master/usr/share/rear/skel/
/scr/rear.github.master/usr/share/rear/skel ~ 
buesser >tar -C default -c . | tar -C /tmp/testy -x
buesser >popd
~

looks quite o.k. to me ?

jsmeix commented at 2020-01-22 15:47:

So it seems tar behaves different when called from within ReaR
compared to when called on the command line
which is something that I can neither explain right now
nor do I have a useful idea where to search for the root cause
of that different behaviour.

The "usual suspect" is that within ReaR some bash options
are set to non-standard values in usr/sbin/rear

shopt -s nullglob extglob

https://github.com/rear/rear/blob/master/usr/sbin/rear#L296
so to verify if that makes a difference for you
you could try

# mkdir /tmp/testy

# pushd /scr/rear.github.master/usr/share/rear/skel/

# ( shopt -s nullglob extglob ; tar -C default -c . | tar -C /tmp/testy -x )

# popd

that runs tar in a subshell where shopt -s nullglob extglob is set.
The subshell is primarily there so that shopt -s nullglob extglob
does not get set in your "outer" shell where you run your commands
i.e. to not "pollute" your "outer" shell with unusual bash settings.

FYI for comparison on my openSUSE Leap 15.0 system
things "just work" for me (I am not a CentOS or RHEL user):

rear.github.master # mkdir /tmp/testy

rear.github.master # pushd usr/share/rear/skel/
rear.github.master/usr/share/rear/skel ~/rear.github.master

rear.github.master/usr/share/rear/skel # ( shopt -s nullglob extglob ; tar -C default -c . | tar -C /tmp/testy -x )

rear.github.master/usr/share/rear/skel # popd
~/rear.github.master

rear.github.master # diff -rq usr/share/rear/skel/default /tmp/testy
[no output so no differences]

jsmeix commented at 2020-01-23 08:55:

I got the following email which belongs to this issue
so here a fullquote

Date: Wed, 22 Jan 2020 07:55:32 -0800
From: wolfgang6444 <notifications@github.com>
Reply-To: rear/rear <reply+AANUVQAV4UUEEXUDLKRAAVN4GWRPJEVBNHHCBLLDWQ@reply.github.com>
To: rear/rear <rear@noreply.github.com>
Cc: Johannes Meixner <jsmeix@suse.de>, Comment <comment@noreply.github.com>
Subject: Re: [rear/rear] BugError: copy_binaries destination '/tmp/rear.dzUC1mLbi1DfZ8T/rootfs/bin' is not a directory (#2307)
Parts/Attachments:
   1 Shown    12 lines  Text (charset: UTF-8)
   2   OK     25 lines  Text (charset: UTF-8)
----------------------------------------

talking of bash ...
as root I am using csh as default shell.
switching to bash before starting rear seems to fix the problem (I need to dig further ...)

Did you REALLY hardcode bash into the software ?

Wolfgang

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rear/rear/issues/2307#issuecomment-577253522

But there is no
https://github.com/rear/rear/issues/2307#issuecomment-577253522
here.

It looks like a bug in GitHub because the same kind of issue
had also happened recently, cf.
https://github.com/rear/rear/issues/2305#issuecomment-572025723

jsmeix commented at 2020-01-23 09:09:

@wolfgang6444
my offhanded expectation is that the very first line

#!/bin/bash

in usr/sbin/rear
https://github.com/rear/rear/blob/master/usr/sbin/rear#L1
ensures that explicitly /bin/bash is used as interpreter
for the ReaR scripts.

At least this is what usual documentation indicate
how those "shebang" thingy should normally work
but I guess there are special exceptions...

wolfgang6444 commented at 2020-01-23 09:46:

Hello,
my post about bash vs csh. was by mistake - so I removed it.
Unfortunately the behaviour is identical (bug) when using bash.

I will test shopt this evening.

Sorry for the confusion,

Wolfgang

jsmeix commented at 2020-01-23 11:34:

@wolfgang6444
thank you for your explanation!

So I think my additional special checks in
https://github.com/rear/rear/pull/2322
are not really needed.

I had the dim feeling that on your system perhaps
/bin/bash is not actually bash but "something else".

wolfgang6444 commented at 2020-01-24 08:00:

I may have expressed my self unclearly:
The problem is still present, even when using bash as 'starting shell'.
My 'success-message' was by mistake, at least I could not reproduce it ... so I removed the comment.

I just didn't have the time yet to dig further ...

wolfgang6444 commented at 2020-01-24 16:46:

I tried it out:

  • It is not sufficient to just start rear from bash if the entry in /etc/passwd still specifies csh as default shell for root.
    -If the entry for root in /etc/passwd is changed to /usr/bin/bash, and rear is started from a 'fresh shell', it seems to work.

So there probably is something wrong with the shebang in some scripts ...

BTW: 'which bash' returns /usr/bin/bash on centos 8.
For some weird reason there also is /bin/bash.
None of the two is a link.
I don't get the purpose of that ...

Both return bash on echo $0

I currently use /usr/bin/bash in /etc/passwd

I think it is probably not a good idea to change the default shell for root anyway, so for me the issue is solved.

jsmeix commented at 2020-01-27 14:03:

@wolfgang6444
thank you for your analysis
what the root cause was in your case.
It is much appreciated.

Now I can try to reproduce how ReaR behaves
when root does not use bash as default shell
and what could be done to detect or avoid that case and
perhaps even how to ensure bash is always used in ReaR scripts.

I also think that it is in practice not a good idea
to have a different shell than bash as default shell for root.
In theory everything should "just work"
regardless of root's default shell but:

In theory, theory and practice are the same.
In practice, they are not

cf. https://quoteinvestigator.com/2018/04/14/theory/

github-actions commented at 2020-06-29 01:37:

Stale issue message

[Export of Github issue for rear/rear.]