#872 Issue closed: usage of BACKUP_OPTIONS for separated things should be split up¶
Labels: enhancement, bug, cleanup,
won't fix / can't fix / obsolete
jsmeix opened issue at 2016-06-09 10:31:¶
Current rear GitHub master.
Excerpt from https://github.com/rear/rear/issues/870#issue-159368065
OUTPUT=USB USB_DEVICE=/dev/disk/by-label/REAR-000 BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" prevents the creation of the live rescue system on the USB device, because the backup options are used there as well.
I think this is a generic bug that is caused by mixing up
separated things.
It looks like some kind of (mis)use of one same
BACKUP_OPTIONS
for what should be probably better separated
into separated config variables like
NFS_MOUNT_OPTIONS
or something like that.
jsmeix commented at 2016-06-09 10:36:¶
@gdha
what do you think?
Should I try to split up BACKUP_OPTIONS into
several separated config variables?
To avoid backward incompatible regressions
my plan is to not change the current usage
of BACKUP_OPTIONS as a general variable
but to add some more specific variables as needed
and when such a specific variable is set then use
only the specific value
(and ignore the BACKUP_OPTIONS value).
In short:
If set use the new specific value
otherwise
fall back using the BACKUP_OPTIONS value.
gdha commented at 2016-06-09 10:49:¶
@jsmeix To be honest I would avoid making too much variables. If it is
possible we can clear the variable in the USB prep phase if needed (just
check on nfs key and remove it).
gdha commented at 2016-06-09 10:57:¶
@jsmeix if we decide to change to name then BACKUP_URL_OPTIONS seems
more related to the BACKUP_URL, no?
jsmeix commented at 2016-06-09 12:27:¶
I do not intend to change anything for
the current BACKUP_OPTIONS variable.
I will have a look if it is possible to implement some exceptional
case handling for BACKUP_OPTIONS when the recovery system
is on USB.
I will prepare a pull request so that then we can better discuss
with something real about what kind of changes I have in mind.
In general I prefer to keep separated things separated
which means in general I prefer to have as many variables
as there are separated things.
Many variables does not mean that the user
must know about them or even explicitly set them.
Many variables also does not mean that there cannot be
more globally meant variables plus more specifically
meant variables.
For example there could be a more globally meant variable
SOMETHING
plus corresponding more specifically meant variables like
SOMETHING_SPECIAL_THIS
SOMETHING_SPECIAL_THAT
or things like that.
There should be reasonable default/fallback behaviour
for each variable when it is not explicitly set so that "usually"
the user should not need to care about them.
But when there are "unusual" cases it should be possible
for the user to adjust all and every detail exactly as he needs.
Of course this results the question what "usual"
versus "unusual" cases are.
When all and every detail can be specified as needed
the question what the default case is
is no longer very important.
jsmeix commented at 2016-06-09 13:20:¶
How to reproduce the issue:
On my SLES12-SP1 x86_64
KVM/QEMU virtual test machine
with two virtual disks
# parted -l Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1571MB 1570MB primary linux-swap(v1) type=82 2 1571MB 21.5GB 19.9GB primary ext4 boot, type=83 Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 2147MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 2147MB 2146MB primary ext2 type=83
with etc/rear/local.conf
OUTPUT=USB USB_DEVICE=/dev/sdb1 BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://10.160.4.244/nfs NETFS_KEEP_OLD_BACKUP_COPY=yes SSH_ROOT_PASSWORD="rear" USE_DHCLIENT="yes"
"rear mkbackup" fails as follows:
~/rear-master # usr/sbin/rear -d -D mkbackup Relax-and-Recover 1.18 / Git Using log file: /root/rear-master/var/log/rear/rear-g185.log Creating disk layout Creating root filesystem layout Copying files and directories Copying binaries and libraries Copying kernel modules Creating initramfs ERROR: Mount command 'mount -v -o nfsvers=3,nolock /dev/sdb1 /tmp/rear.B1WS88na0foIX82/outputfs' failed. Aborting due to an error, check /root/rear-master/var/log/rear/rear-g185.log for details You should also rm -Rf /tmp/rear.B1WS88na0foIX82 Terminated
jsmeix commented at 2016-06-09 14:03:¶
In usr/share/rear/prep/default/02_translate_url.sh I found:
### Make sure we have OUTPUT_* from BACKUP_*, for compat with versions that
### not separated the two.
if [[ -z "$OUTPUT_OPTIONS" ]] ; then
if [[ -z "$OUTPUT_URL" && -z "$OUTPUT_MOUNTCMD" ]] ; then
### There can be cases where it's intentionally empty.
OUTPUT_OPTIONS=$BACKUP_OPTIONS
fi
fi
which results that in
usr/share/rear/output/default/10_mount_output_path.sh
mount_url $OUTPUT_URL $BUILD_DIR/outputfs $OUTPUT_OPTIONS
evaluates to
mount_url nfs://10.160.4.244/nfs /tmp/rear.FnsF7EvkWh8K68K/outputfs nfsvers=3,nolock
which works but also to
mount_url usb:///dev/sdb1 /tmp/rear.FnsF7EvkWh8K68K/outputfs nfsvers=3,nolock
which fails with
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
I.e. in current rear versions there is OUTPUT_*
separated from BACKUP_* and for backward compatibility
OUTPUT_* inherits from BACKUP_*
Therefore in this case it helps to set a non-empty dummy
OUTPUT_OPTIONS="nodiratime"
to get BACKUP_OPTIONS separated from OUTPUT_OPTIONS
which results
mount_url nfs://10.160.4.244/nfs /tmp/rear.euHSfSw80xVx5zL/outputfs nfsvers=3,nolock
that works as intended and
mount_url usb:///dev/sdb1 /tmp/rear.euHSfSw80xVx5zL/outputfs nodiratime
that also works as intended.
Of course this is only a workaround but I need more time
to better understand all the complicated interdependencies
of the variables.
I like to avoid a quick and dirty hack in the mount_url()
function in usr/share/rear/lib/global-functions.sh for
the (usb) case (like just removing the "$options" there).
I really wished there were well separated variables
for each separated use case...
[Export of Github issue for rear/rear.]