#2637 Issue `open`: Don't deprecate OBDR because it still works and is in use¶

Labels: enhancement, cleanup

jsmeix opened issue at 2021-06-22 13:41:¶

Usage of OUTPUT=OBDR should be deprecated in next ReaR version (2.7)
so that the OBDR code could be removed in the version after the next version (2.8)

See https://github.com/rear/rear/pull/2625 (excerpts):

UEFI seems to have broken OBDR support:
https://github.com/rear/rear/commit/41efc97eb7141c30455df45a871b98cd08e09fa7

OBDR probably got broken on ppc64le:
https://github.com/rear/rear/commit/4ef0f30156f0afea4a02d12f40c2c9d18cbe5e43
PR https://github.com/rear/rear/pull/1383

in particular
https://github.com/rear/rear/pull/2625#issuecomment-859335712
and some subsequent comments about OBDR therein.

jsmeix commented at 2021-06-22 13:51:¶

I wonder what the best way is how to deprecate something in ReaR.

My personal offhanded idea is to add a new script like
usr/share/rear/init/default/850_check_deperecations.sh
that errors out when something deprecated is used
e.g. something like

test "$OUTPUT" = "OBDR" && Error "OBDR support is deprecated"

perhaps a bit more user friendly - I only liked to suggest the basic idea.

jsmeix commented at 2021-06-25 13:35:¶

An offhanded proposal how to make it easier for the user
to still use deprecated functionality:

Add to default.conf

# For now you may set it to 'false' to still use deprecated OUTPUT="OBDR"
# but OBDR support will be removed in a subsequent ReaR version
# see https://github.com/rear/rear/issues/2637
OBDR_DEPRECATED="OBDR support is deprecated"

and in a new script usr/share/rear/init/default/850_check_deperecations.sh

if ! is_false "$OBDR_DEPRECATED" ; then
    test "$OUTPUT" = "OBDR" && Error "OUTPUT=$OUTPUT - $OBDR_DEPRECATED"
fi

github-actions commented at 2021-08-25 02:07:¶

Stale issue message

pcahyna commented at 2023-03-13 14:35:¶

@maslo64 can you please test OBDR support?

maslo64 commented at 2023-03-20 06:26:¶

@pcahyna tests were performed with 2.7.1 RPM and in order to restore, here are changes which were done to rear.

Here we need to update config file with "" and () because of tar behavior ,mentioned also in https://github.com/rear/rear/issues/2911
https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh

BACKUP_PROG_COMPRESS_OPTIONS=()
BACKUP_PROG_COMPRESS_SUFFIX=""

Here we are missing 'mt' program in order to perform restore , f.x. seek with fsf command

https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/conf/default.conf#L1283

what was also needed for restore was to execute script

bash /usr/share/rear/skel/OBDR/etc/scripts/system-setup.d/43-init-cciss.sh

and afterwards update TAPE_DEVICE=/dev/nstX in config file.

Thanks

jsmeix commented at 2023-03-22 13:52:¶

Via
https://github.com/rear/rear/commit/d600bd776027150628225188c394420e4c6724cb
I added 'mt' command to REQUIRED_PROGS_OBDR in default.conf according to
https://github.com/rear/rear/issues/2637#issuecomment-1475690995

jsmeix commented at 2023-03-22 13:58:¶

@maslo64
thank you for your comment.

As long as current ReaR works with OBDR and
as long as there are users who use current ReaR with OBDR,
we will not deprecate OBDR.

In general:
Contributions for special use case support in ReaR
are much appreciated because we at ReaR upstream
usually cannot test those special use cases
so we totally depend on contributions from people
who use and know about those special use cases.

jsmeix commented at 2023-03-22 14:06:¶

Currently I do not understand the third part in
https://github.com/rear/rear/issues/2637#issuecomment-1475690995

what was also needed for restore was to execute script

bash /usr/share/rear/skel/OBDR/etc/scripts/system-setup.d/43-init-cciss.sh

and afterwards update TAPE_DEVICE=/dev/nstX in config file.

but I never used a tape device with Linux
so I may not see things that are obvious
for users who actually use a tape device.

What confuses me:

I would assume etc/scripts/system-setup.d/43-init-cciss.sh
gets automatically run during ReaR recovery system startup?

I see TAPE_DEVICE is used a lot in various scripts
but there is no TAPE_DEVICE in usr/share/rear/conf/default.conf
so TAPE_DEVICE is no user config variable?

maslo64 commented at 2023-03-28 17:03:¶

I would assume etc/scripts/system-setup.d/43-init-cciss.sh gets automatically run during ReaR recovery system startup?
I did expect that would be the case, but I think in my case /var/lib/rear/output/rear-${HOSTNAME}.iso, was created using 'OUTPUT=ISO', then it changed to 'OUTPUT=OBDR' in config file, so script never made it to /etc/scripts/system-setup.d/ so it couldn't be executed during startup.
And reason why it was this was setup this way is that with 'OUTPUT=OBDR' the ISO file was never successfully created.
So we have had 'static' booting ISO always written to tape and data with tar was updated regularly.

I did test it now and it looks better during boot

Running 43-init-cciss.sh...
Disable OBDR mode for device /dev/sr0
Rescan single device using 1 0 1 0
Wait for devices to settle
Running 45-serial-console.sh...

so TAPE_DEVICE is no user config variable? after some more testing , this seems to be required for successful restore.
If only OUTPUT_URL=/dev/stX is specified, restore failed in my case.

As TAPE_DEVICE in recovery environment in OBDR case might not be same device file, as new device /dev/stX will be generated when changing device from OBDR mode. (considering there could be any number of tape drives/changers in recovery environment ) so TAPE_DEVICE has to be set either manually or using 43-init-cciss.sh somehow.

github-actions commented at 2023-05-28 02:32:¶