Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL?

[iringor]

• ReaR version ("/usr/sbin/rear -V"):
  Relax-and-Recover 2.6 / 2020-06-17
  This also happens to Relax-and-Recover 2.4 / Git for RHEL 7.9

• If your ReaR version is not the current version, explain why you can't upgrade:

• OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

NAME="Red Hat Enterprise Linux"
VERSION="8.6 (Ootpa)"

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
  For details, please check it from https://github.com/iringor/rear.git

[root@dvsdsas1 ~]# cat /etc/rear/site.conf | grep . | grep -v ^#
export TMPDIR="/rear"
OUTPUT=ISO
ISO_DIR="/rear"
OUTPUT_URL=null
BACKUP=NETFS
BACKUP_URL=iso:///backup
REL=`cat /etc/redhat-release |awk -F"release" '{print $2}' |awk -F. '{print $1}'`
if [ $REL -le 6 ]; then
   LISTOFBACKUP="$(df -T -x tmpfs -x devtmpfs -x devpts -x sysfs -x proc | grep -oE '/\S+' | grep -v /dev/ | awk '! /^\/$|^\/boot$/ {print}'| tr '\n' ' ')"
else
   LISTOFBACKUP="$(df -T -x tmpfs -x devtmpfs -x devpts -x sysfs -x proc | awk 'NR>1{print $7}' | awk '! /^\/$|^\/boot$/ {print}'| tr '\n' ' ')"
fi
LISTOFBACKUP="${LISTOFBACKUP} /var/log/cups /var/log/httpd "
if [ -f /usr/local/sbin/mondoexclude.txt ]; then
   LISTOFBACKUP="${LISTOFBACKUP}`cat /usr/local/sbin/mondoexclude.txt`"
fi
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" ${LISTOFBACKUP})
ISO_MAX_SIZE=4400
MIGRATION_MODE=false

• Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
  VMware

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  x86

• Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
  BIOS GRUB

• Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  local disk

• Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

[root@dvsdsas1 ~]# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
NAME                                KNAME     PKNAME    TRAN   TYPE FSTYPE      LABEL  SIZE MOUNTPOINT
/dev/sda                            /dev/sda                   disk                     20G
|-/dev/sda1                         /dev/sda1 /dev/sda         part xfs                  1G /boot
`-/dev/sda2                         /dev/sda2 /dev/sda         part LVM2_member         19G
  |-/dev/mapper/VolGroup01-root     /dev/dm-0 /dev/sda2        lvm  xfs                 17G /
  `-/dev/mapper/VolGroup01-swap     /dev/dm-1 /dev/sda2        lvm  swap                 2G [SWAP]
/dev/sdb                            /dev/sdb                   disk                    200G
`-/dev/sdb1                         /dev/sdb1 /dev/sdb         part LVM2_member        200G
  |-/dev/mapper/VolGroup02-LogVol01 /dev/dm-2 /dev/sdb1        lvm  xfs                100G /usr/sap/sapmnt
  |-/dev/mapper/VolGroup02-LogVol02 /dev/dm-3 /dev/sdb1        lvm  xfs                 40G /install
  |-/dev/mapper/VolGroup02-LogVol03 /dev/dm-4 /dev/sdb1        lvm  xfs                 10G /u01
  |-/dev/mapper/VolGroup02-lv_swap2 /dev/dm-5 /dev/sdb1        lvm  swap                16G [SWAP]
  `-/dev/mapper/VolGroup02-LogVol04 /dev/dm-6 /dev/sdb1        lvm  xfs                 10G /rear
/dev/sr0                            /dev/sr0            sata   rom                    1024M

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

I am getting this email notification everyday even if the mkbackup script is only running once a month.

From: (Cron Daemon) <root@server.company.com> 
Sent: Thursday, April 4, 2024 1:30 AM
To: root@server.company.com
Subject: Cron <root@server> test -f /var/lib/rear/layout/disklayout.conf && /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL ?
(default 'No' timeout 300 seconds)
ERROR: The mkrescue workflow does not work for the BACKUP_URL scheme 'iso'
Some latest log messages since the last called script 040_check_backup_and_output_scheme.sh:
  2024-04-04 01:30:24.256120130 Including prep/default/040_check_backup_and_output_scheme.sh
  2024-04-04 01:30:24.314857703 UserInput: called in /usr/share/rear/prep/default/040_check_backup_and_output_scheme.sh line 30
  2024-04-04 01:30:24.350941007 UserInput: No choices specified
  2024-04-04 01:30:24.368811100 Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL ?
  2024-04-04 01:30:24.386439123 (default 'No' timeout 300 seconds)
  2024-04-04 01:30:24.422376325 UserInput: 'read' timed out with non-zero exit code
  2024-04-04 01:30:24.477753667 Aborting 'mkrescue' with a 'iso' BACKUP_URL by default Aborting due to an error, check /var/log/rear/rear-dvsdsas1.log for details

• Workaround, if any:

• Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:

verbatim content

[iringor]

I think the issue is resolved. I was not aware that when installing rear, it automatically creates a cron for rear mkrescue that runs everyday at 1:30 AM and it looks like this is a default setting. I will comment out this cron for now and if there is no more recurring issue related to this in a week I will close this case. Thanks.

[root@server ~]# grep -R rear /etc/cron*
/etc/cron.d/rear:#30 1 * * * root /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

[jsmeix]

@iringor
it seems your issue is similar like this one
#2787
where also a cron job broke things.

The /etc/cron.d/rear/ related things
were removed for ReaR 2.5 see
#2139
and
#1892

See the comments therein why that cron thing is broken
and why I and others are against such cron things.

It seems your issue here is just another case
that shows why that cron thing is broken.

I guess your cron job is a leftover from ReaR 2.4

[iringor]

Hi Johannes, Yes, it looks similar. But my issue is now fixed. I could not access https://relax-and-recover.org/ before when I started researching about ReaR. The site was blocked by our IT admin for some reason. I didn't find this in the man pages, but it is mentioned in https://relax-and-recover.org/usage/ that a cron job can be created (or automatically created?) to sync with the rescue image. It is actually a good tool, this "rear checklayout," to alert me if there is a need to create a new image. Thank you. -Don Ringor