#3591 PR `open`: Save and reset GRUB environment block when env_block is used¶

Labels: enhancement

svlv opened issue at 2026-03-24 15:35:¶

Pull Request Details:¶

Type: Enhancement
Impact: Normal
Reference to related issue (URL): Fixes https://github.com/rear/rear/issues/3578
How was this pull request tested?
Manually recovered VM running openSUSE Leap 16
Description of the changes in this pull request:
Save grubenv when it is stored in an external raw filesystem block.
Currently, it is used on Btrfs. The external raw block is configured
using the env_block variable. The filesystem envblock may be accessible
at backup time only, which makes it essential to save it.

When the env_block variable is not set, the envblock is stored at
/boot/grub/grubenv or /boot/grub2/grubenv, where it is backed up
and restored as a regular file, so and saving it separately is not
required.

The PR includes changes from https://github.com/rear/rear/pull/3581

jsmeix commented at 2026-03-24 17:55:¶

@svlv
thank you for your continual valuable contributions to ReaR.
It is much appreciated!

jsmeix commented at 2026-03-31 13:39:¶

@svlv
would it be OK for you when I re-activate my
https://github.com/rear/rear/pull/3581
and merge it
and then you rebase your pull request here
on top of my merged https://github.com/rear/rear/pull/3581
as @pcahyna suggested in his
https://github.com/rear/rear/pull/3581#issuecomment-4120010673
?

svlv commented at 2026-03-31 14:06:¶

@jsmeix
It is totally fine for me. I’ll rebase the PR after your PR is merged.

codacy-production commented at 2026-03-31 14:54:¶

Up to standards ✅¶

🟢 Issues 0 issues

>
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3591/issues) >

_{TIP This summary will be updated as you push new changes. Give
us feedback}

pcahyna commented at 2026-03-31 15:43:¶

@svlv I have only minor comments - thank you a lot for this contribution!

jsmeix commented at 2026-04-09 08:14:¶

I am wondering if the run_in_target_fs_root function
could result problems with root cause RFC 1925 item 6a

It is always possible to add another level of indirection.

In particular I am wondering if the function indirection
may lead to "quoting hell" problems or "eval hell" problems?

What I have in mind are possible variable evaluation issues
together with possible command substitution issues
for example something as in

# TARGET_FS_ROOT=/var/tmp/rear.TRp118UDWCMMcvK/rootfs

# REAR_RELEASE=/etc/rear-release

# ( set -x ; chroot $TARGET_FS_ROOT /bin/bash --login -c "cat \$( ls $REAR_RELEASE )" )
+ chroot /var/tmp/rear.TRp118UDWCMMcvK/rootfs /bin/bash --login -c 'cat $( ls /etc/rear-release )'

Relax-and-Recover release 2.9

# ( set -x ; run_in_target_fs_root "cat \$( ls $REAR_RELEASE )" )
+ run_in_target_fs_root 'cat $( ls /etc/rear-release )'
+ local 'cmd=cat $( ls /etc/rear-release )'
+ chroot /var/tmp/rear.TRp118UDWCMMcvK/rootfs /bin/bash -c 'PATH=/sbin:/usr/sbin:/usr/bin:/bin cat $( ls /etc/rear-release )'

Relax-and-Recover release 2.9

It seems to "just work" at least in my example here
even with the additional run_in_target_fs_root() indirection.

It be on the safe side I would much appreciate it
if you @rear/contributors - in particular @pcahyna
could have a closer look whether or not
the run_in_target_fs_root() function indirection
may cause troubles with more complicated chroot commands.

What I have in mind are failures (bugs) because of
indirections when our ...IfError functions are used
which do not happen when bash is used directly,
see lib/_framework-setup-and-functions.sh
https://github.com/rear/rear/blob/master/usr/share/rear/lib/_framework-setup-and-functions.sh#L891

pcahyna commented at 2026-04-09 17:00:¶

@jsmeix @svlv sorry for my delay in review. One must be really careful about quoting and eval issues in bash indeed, thanks for pointing that out. Nevertheless, with extra care and proper design of the interface it can usually be implemented in a way that behaves correctly. I will have a look.

pcahyna commented at 2026-04-10 17:39:¶

@jsmeix so I had a look and I believe that the code is correct. There is no "quoting hell" that would not arise in the bash -c "..." case already. I.e. I believe that bash -c "<something>" and cmd="<something>"; bash -c "$cmd" are equivalent. If <something> contains quotes, they are left untouched by bash -c "$cmd", because the rule for quote removal is:
"After these expansions are performed, quote characters present in the original word are removed unless they have been quoted themselves"
or stated alternatively as
"After the preceding expansions, all unquoted occurrences of the characters '\', ''', and '"' that did not result from one of the above expansions are removed."

Of course, quotes in need to be protected (quoted themselves, via backslashes), in a command like bash -c "<something>" and cmd="<something>", but these two cases are equivalent in this respect, as you have found with $. The extra levels of indirection via variable expansion does not matter here. The $ case is safe, because variable expansion does not occur recursively on the expansion result.

[Export of Github issue for rear/rear.]

#3591 PR open: Save and reset GRUB environment block when env_block is used¶