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
"rear mkrescue" does not error out when COPY_AS_IS="/some/dir" results broken recovery system #2925
Comments
Can you please use version 2.7? We can't support older version, sorry. Also, how did you install ReaR? @jsmeix do we have RHEL 8 repos with current packages somewhere? Is there a specific reason for copying a kernel source to the rescue system? What would you do with that during recovery? IMHO the lockable USB storage device should not make a difference as long as it is unlocked. The rescue systems runs completely out of a RAM disk (created by the Bottom line: This looks like an installation gone wrong or a very unusual system layout. After upgrading to 2.7 please try again and also provide us the log file from the |
I can try the newer version. Didn't realize I was using an older version. yum install rear I had to do the copy as is with that kernel because the mkbackup kept erroring out with that specific line as the cause, when I went looking for solutions that copy as is line was what I found and once I included it, I could at the very least create the backup. That makes sense, but why would it reach out for the default.conf file during that phase? This was a second go round, I uninstalled rear and all of the packages with it. Reinstalled it and had the same error at the same point. I will attempt with the newer version and try again. |
The fact that it is missing shows that there is some fundamental problem. Please try with a recent version and als show us the output and log of |
BTW, you can configure SSH for the rescue system to make your life simpler. |
The cause is
in etc/rear/local.conf (or etc/rear/site.conf)
in usr/share/rear/conf/default.conf that is sourced in usr/sbin/rear Use
instead. Note that COPY_AS_IS is an array, See also the comments in our original By the way: |
In the openSUSE Build Service (OBS) |
Nice catch @jsmeix! Maybe some day we can do a simple check for such common mistakes by validating that variables that should be an array are actually still an array, or at least the ones where we always expect more than one value in them, like this |
Interestingly "rear mkrescue" does not error out with
I tested it right now on a test VM with
I would have expected that something fails with that.
I think I will enhance
or something similar. When I call this inside the ReaR recovery system
For now I prefer a simple test for what is actually needed |
Should we keep this issue open till we actually add a sanity check? I was thinking along the lines of parsing And then we can add a check like this to validate that all those variables are actually still arrays:
(and this code is not very robust, see https://stackoverflow.com/a/42877229 for the probably most "correct" implementation) What do you think. Should I add that to ReaR? |
I did By the way:
would be syntactically correct but still results |
Relax-and-Recover (ReaR) Issue Template
Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):
ReaR version: 2.6
OS version: RHEL 8.5
ReaR configuration files:
OUTPUT=USB
OUTPUT_URL="usb:///dev/disk/by-label/REAR-000"
BACKUP=NETFS
BACKUP_URL="usb:///dev/disk/by-label/REAR-000"
BACKUP_SELINUX_DISABLE=1
CLONE_ALL_USERS=y
USE_SERIAL_CONSOLE=n
SSH_ROOT_PASSWORD=
USE_SERIAL_CONSOLE=n
COPY_AS_IS="/usr/src/kernals/4.18.0-348.el8.x86_64"
USB_UEFI_PART_SIZE="650"
EOF
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
Firmware: GRUB
Storage: SSD
Description of the issue: So I was able create a mkBACKUP on a external lockable SSD that I had available. I am able to boot to the drive by plugging the device and the SSD into a docking station to keep the lockable ssd powered so it won't auto lock during the reboot process, however once booted to the drive and it enters ReaR the drive umounts and instantly locks after loading into rear. Once ReaR loads and asks for the login, I do that and attempt a rear recover, but says it can't find /bin/rear to find the default.conf file. I unlock the drive, do a lsblk to make sure that it shows that it is mounted on the system, but I get the same result.
Is it impossible to use a lockable drive as the USB device or am I missing something to make this work correctly?
The text was updated successfully, but these errors were encountered: