#2456 Issue closed: RELAXRECOVE instead of RELAXRECOVER - Cannot restore backup - the path is wrong

Labels: enhancement, support / question, fixed / solved / done

matekubi opened issue at 2020-07-15 07:26:

  • ReaR version ("/usr/sbin/rear -V"):

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

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

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

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

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

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

Error during restore from Rescue CD

URL: https://ibb.co/swPt6FM

Please check the screenshot. The path is wrong. Lack of R in RELAXRECOVER name of USB.
Maybe it is because I've created ISO with backup inside and then use Rufus to write it to USB.
For now, I have to do this in that way - I mean save as ISO and write to USB stick
instead of writing directly to USB.

  • Workaround, if any:
    Yes, create a hard link between RELAXRECOVE and RELAXRECOVER

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

jsmeix commented at 2020-07-15 08:11:

There are certain length limits for such labels and RELAXRECOVE is 11 characters
so in your case there is a maximum lenght of 11 characters of that label.

E.g. "man e2label" tells

Ext2 volume labels can be at most 16 characters long

same as "man mke2fs".

In contrast "man mkfs.fat" tells

The volume name can be up to 11 characters long.

So I assume you have a FAT or VFAT filesystem
where its label can be at most 11 characters long.

matekubi commented at 2020-07-15 08:15:

Is that possible to change this label in some REAR settings in order to avoid this issue?

jsmeix commented at 2020-07-15 11:51:


@matekubi in your initial
you had falsely written

create a hard link between REARRECOVE and REARRECOVER

and I had searched all ReaR files for REARRECOVER
but did not find anything because there is no REARRECOVER.

Now I see that it is actually about RELAXRECOVER
and this one exists in the ReaR files

# find usr/sbin/rear usr/share/rear/ doc -type f | xargs grep -l 'RELAXRECOVER'

In particular usr/share/rear/conf/default.conf even explains
this issue here:

# Default ISO label:
# When the backup is split on multiple ISOs (cf. ISO_MAX_SIZE below)
# the first ISO 'rear-HOSTNAME.iso' has the label $ISO_VOLID
# and subsequent ISOs 'rear-HOSTNAME_01.iso' 'rear-HOSTNAME_02.iso' ...
# get the labels ${ISO_VOLID}_01 ${ISO_VOLID}_02 ... respectively.
# The default value RELAXRECOVER is too long to fit a FAT32 volume label
# so that the actual FAT32 volume label on the medium is truncated
# which lets 'rear recover' fail because ReaR cannot mount it with
# the RELAXRECOVER volume label so that in case of FAT32 or any other
# filesystem that only support short volume labels the ISO_VOLID value
# must be appropriately specified in /etc/rear/local.conf


And we have had some issues with that label, for example
and in particular (same as this issue here)
with an explanation why we cannot change such default values

jsmeix commented at 2020-07-15 13:04:

right now I did https://github.com/rear/rear/pull/2457
and I need you to test if that works in actual real world, cf.

To test it replace in your usr/share/rear/conf/default.conf
and recreate your ReaR ISO via "rear mkbackup" and
recreate your FAT bootable USB stick exactly as you did before and
then try out if "rear recover" works with your new created USB stick.

jsmeix commented at 2020-07-20 14:32:

With https://github.com/rear/rear/pull/2457 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]