@gdha
many thanks for your careful code review.

Yes, the ';' was missing.

I also removed the '2>&8'.

Regarding GRUB 2 config using '--set=root' I don't know.
For me it did not work with "linux /rear-kernel"
and "initrd /rear-initrd.cgz" but for me it works with
"linux /boot/rear-kernel" and "initrd /boot/rear-initrd.cgz".

Now I changed it so that setting GRUB2 password
is only optionally (ugly quick and dirty if then fi added
without proper indentation for now).

I only liked to check hwo it behaves for me without
setting GRUB2 password i.e. with explicit specifying
empty values:

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD=""
GRUB_SUPERUSER=""

For me it behaves better now because now I can still boot
the default SLE12 entry without a password.
Of course now also the "Relax-and-Recover" boot entry
can be booted without password.
But to get his system replaced one must run "rear recover"
and from my current point of view this is sufficient protection
against accidentally overwriting his system in particular
because the whole GRUB_RESCUE is disabled by default.

I.e. who actively enables GRUB_RESCUE gets what he
actively asked for.

@jsmeix after a bit of comparing why Centos protects only ReaR entry with password and SLES12 does all, I've probably found the reason.

In order to allow boot entry without password you need to specify in grub.cfg option --unrestricted to entry you don't wish to protect with password.

e.g.
menuentry 'SLES 12-SP1' --class sles --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-simple-cc564292-9ed5-48d4-a186-30e7c3a0478e'

I guess RedHat guys are using this option as default, that why they don't had trouble with such setup ...

Yes, while working on it I also learned
about the --unrestricted option.

But I will never ever implement that via GRUB_RESCUE
also all the other boot entries get changed by adding
the --unrestricted option to all other boot entries.

I find it scaring enough that via GRUB_RESCUE
the bootloader of the currently running system gets
changed by adding one more boot entry to it but I will
never ever modify exitsing other entries.

Therefore my current code makes GRUB_RESCUE_PASSWORD
and GRUB_SUPERUSER optional so that the user can avoid
that "rear mkbackup" via the GRUB_RESCUE feature
changes the behaviour of all its other boot entries
because (at least on SLE12) now all boot entries become
password protected.

Meanwhile I think I like to change the default to empty
GRUB_RESCUE_PASSWORD and GRUB_SUPERUSER
because with current defaults

GRUB_RESCUE_PASSWORD="REAR"
GRUB_SUPERUSER="rearadmin"

the GRUB_RESCUE feature (at least on SLE12)
silently adds password protection to all boot entries
with username and password values that are unknown
for the user unless he had carefully read the defaults
in usr/share/rear/conf/default.conf

Now I implemented support to set GRUB2 password only optionally
in nice looking code.

Additionally one can (also optionally) use an existing
GRUB2 user via GRUB_RESCUE_USER without the need
to let rear create a GRUB2 superuser.
The GRUB_RESCUE_USER behaves backward compatible
because when GRUB_RESCUE_USER is empty it uses
the GRUB_SUPERUSER value.

Two examples how in now works for me on SLES12-SP1:

With

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="rear"
GRUB_SUPERUSER="root"
GRUB_RESCUE_USER=""

it does:

# usr/sbin/rear -d -D mkbackup
Relax-and-Recover 1.18 / Git
Using log file: /root/rear/var/log/rear/rear-f121.log
Creating disk layout
Creating root filesystem layout
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
Making ISO image
Wrote ISO image: /root/rear/var/lib/rear/output/rear-f121.iso (20M)
Setting up GRUB_RESCUE: Adding Relax-and-Recover rescue system to the local GRUB 2 configuration.
Setting up GRUB 2 password protection with GRUB 2 user 'root'.
Setting up GRUB 2 superuser 'root'.
Modifying local GRUB 2 configuration.
Finished GRUB_RESCUE setup: Added 'Relax-and-Recover' GRUB 2 menu entry.
Copying resulting files to nfs location
Encrypting disabled
Creating tar archive '/tmp/rear.W6BQduTst1CjlPk/outputfs/f121/backup.tar.gz'
Archived 1316 MiB [avg 7325 KiB/sec]OK
Archived 1316 MiB in 185 seconds [avg 7285 KiB/sec]

After manually

# rm /etc/grub.d/01_users

to get rid of the GRUB 2 superuser that was set before
with only

GRUB_RESCUE=y

it does:

# usr/sbin/rear -d -D mkbackup
Relax-and-Recover 1.18 / Git
Using log file: /root/rear/var/log/rear/rear-f121.log
Creating disk layout
Creating root filesystem layout
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
Making ISO image
Wrote ISO image: /root/rear/var/lib/rear/output/rear-f121.iso (73M)
Setting up GRUB_RESCUE: Adding Relax-and-Recover rescue system to the local GRUB 2 configuration.
Modifying local GRUB 2 configuration.
Finished GRUB_RESCUE setup: Added 'Relax-and-Recover' GRUB 2 menu entry.
Copying resulting files to nfs location
Encrypting disabled
Creating tar archive '/tmp/rear.cf0xFwJYsF0DF6F/outputfs/f121/backup.tar.gz'
Archived 1315 MiB [avg 7403 KiB/sec]OK
Archived 1315 MiB in 183 seconds [avg 7362 KiB/sec]

Now it works sufficiently well for me on SLES12-SP1.

From my current point of view it could be merged
provided others do not find bugs.

Note that this pull request is only about GRUB 2
i.e. only about 94_grub2_rescue.sh

If GRUB_RESCUE works sufficiently well for nowadays GRUB 2
I may also have a look at GRUB Legacy in 94_grub_rescue.sh
as time permits but that would be a separated task.

FYI:

The only left drawback from my current point of view is
that it does not yet automatically delete stuff
that had been added before.

For example if one does "rear mkbackup" with

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="bar"
GRUB_SUPERUSER="foo"

one gets a GRUB 2 superuser 'foo' set up
plus GRUB 2 password protection.

If later one changes local.conf to be only

GRUB_RESCUE=y

the previously set up GRUB 2 superuser 'foo' is
not deleted and the GRUB 2 password protection
is still active regardless that the rear menue entry
in /boot//grub2/grub.cfg does no longer contain
a "password_pbkdf2" line.

To get rid of previously set up GRUB 2 superuser
and GRUB 2 password protection one must manually

rm /etc/grub.d/01_users

@jsmeix maybe I've overlooked, but did you manage to solve problem on SLES12 when all grub entries were protected by password?

I did not (and I will not) deal with when all grub entries
get protected by password see #942 (comment)

I only documented that unexpected possible result in default.conf

When GRUB_RESCUE_PASSWORD is set
it may result password protection for all GRUB2
menue entries of the currently running system
unless the '--unrestricted' option is set for those
GRUB2 menue entries that should not have
password protection.

Currently the only way to avoid that unexpected result
is to not set up GRUB2 password protection.

Fair enough ...

Damn!

Seems to be again a nice mess how GRUB 2 works
on different Linux distributions:
On my SLES12-SP1 "linux /rear-kernel" and "initrd /rear-initrd.cgz"
just failed to boot so that I changed it to the absolute path
"/boot/rear-kernel" and "/boot/rear-initrd.cgz" but that
fails on CentOS Linux release 7.2.1511 (Core), see
#703 (comment)

Currently I don't know how to fix such Linux distribution mess
so that it works in a generic way on all Linux distributions.

Furthermore regarding the GRUB 2 password protection see
#703 (comment)

Bottom line:

I think I will remove GRUB 2 password protection setup from rear
because it can mess up the GRUB 2 setup in unexpected ways
and GRUB 2 password protection setup in the currently running
system is really not at all an expected native functionality of rear.
If a user wants GRUB 2 password protection he can do that
on his own as he likes and needs it.

With my latest commit I removed GRUB_SUPERUSER support
in a (hopefully) reasonably backward compatible way
(see my comments in default.conf).
Now one must use GRUB_RESCUE_USER
plus GRUB_RESCUE_PASSWORD
if the otional GRUB 2 password protection is wanted.

Wow!

With removed GRUB_SUPERUSER support
it seems to work perfectly well for me.

With old-style

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="bar"
GRUB_SUPERUSER="foo"

I get

Setting up GRUB_RESCUE: Adding Relax-and-Recover rescue system to the local GRUB 2 configuration.
Setting up GRUB 2 password protection with GRUB 2 user 'foo'.
Skipping GRUB 2 superuser setup: GRUB_SUPERUSER is no longer supported (see default.conf).
Modifying local GRUB 2 configuration.
Finished GRUB_RESCUE setup: Added 'Relax-and-Recover' GRUB 2 menu entry.

and a "password_pbkdf2 foo grub.pbkdf2.sha512..."
entry in /etc/grub.d/45_rear and accordingly
also in /boot//grub2/grub.cfg for 'Relax-and-Recover'.

But I have no /etc/grub.d/01_users file
so that I expected that I cannot boot 'Relax-and-Recover'
because there is no GRUB 2 user "foo".

But it "just boots" nevertheless (without password prompt).

I.e. it seems GRUB 2 behaves fail-safe when there is
a "password_pbkdf2" entry but that user does not exist.

Still can result a mess if one is not very careful.

With that manually created /etc/grub.d/01_users

#!/bin/sh
cat << EOF
set superusers="baz"
password baz rear
password foo bar
EOF

and non-matching /etc/rear/local.conf entries

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="blah"
GRUB_RESCUE_USER="foo"

I cannot boot 'Relax-and-Recover' as user foo
regardless what password (bar or blah) I use.
I can only boot it as GRUB 2 superuser with his password.

Therefore I am now thinking about also dropping support
for GRUB_RESCUE_PASSWORD in rear and only keep
support for GRUB_RESCUE_USER and make the
'Relax-and-Recover' menue entry not with
"password_pbkdf2"
but instead with "--users $GRUB_RESCUE_USER"
when GRUB_RESCUE_USER is non-empty or
with "--unrestricted" when GRUB_RESCUE_USER is empty
according to how that is described at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html

This would mean when GRUB_RESCUE_USER is non-empty
the user must have already set up this user for GRUB 2
because rear does not do that because GRUB 2 users setup
is general GRUB 2 configuration and rear will not mess up
with the general GRUB 2 configuration.

Perhaps I might implement a check that looks if a
non-empty GRUB_RESCUE_USER can be found
in /etc/grub.d/01_users but I do not like that because
as far as I know the filename '01_users' could be
anything else so that it could become the next nightmare
to implement such a check so that it works gererically
everywhere.

With my latest commit I also removed
GRUB_RESCUE_PASSWORD support
in a (hopefully) reasonably backward compatible way.

Now only GRUB_RESCUE_USER can be used
(which needs already setup GRUB 2 users)
if the otional GRUB 2 password protection is wanted.

Now the whole GRUB 2 password protection stuff
seems to work o.k. for me for the first time simple
and straightforward without unexpected behaviour.

What I tested:

I have a manually created /etc/grub.d/01_users

#!/bin/sh
cat << EOF
set superusers="root"
password root rootpw
password rear rearpw
EOF

With

GRUB_RESCUE=y
GRUB_RESCUE_USER="unrestricted"

I get this /etc/grub.d/45_rear

#!/bin/bash
cat << EOF
menuentry 'Relax-and-Recover' --class os --unrestricted {
          search --no-floppy --fs-uuid --set=root 45fd0fdf-b85e-4d10-9e0b-a4395ac6db11
          echo 'Loading kernel /boot/rear-kernel ...'
          linux  /boot/rear-kernel selinux=0 console=ttyS0,9600 console=tty0
          echo 'Loading initrd /boot/rear-initrd.cgz (may take a while) ...'
          initrd /boot/rear-initrd.cgz
}
EOF

which results that I can boot that without password dialog
regardless that for the default SLES12 boot entry I get
a password dialog (because I have a GRUB 2 superuser).

With

GRUB_RESCUE=y
GRUB_RESCUE_USER="rear"

I get this /etc/grub.d/45_rear

#!/bin/bash
cat << EOF
menuentry 'Relax-and-Recover' --class os --users rear {
          search --no-floppy --fs-uuid --set=root 45fd0fdf-b85e-4d10-9e0b-a4395ac6db11
          echo 'Loading kernel /boot/rear-kernel ...'
          linux  /boot/rear-kernel selinux=0 console=ttyS0,9600 console=tty0
          echo 'Loading initrd /boot/rear-initrd.cgz (may take a while) ...'
          initrd /boot/rear-initrd.cgz
}
EOF

which results that I can boot this as GRUB2 user 'rear'
with its password or as GRUB 2 superuser.

With only

GRUB_RESCUE=y

I get this /etc/grub.d/45_rear

#!/bin/bash
cat << EOF
menuentry 'Relax-and-Recover' --class os {
          search --no-floppy --fs-uuid --set=root 45fd0fdf-b85e-4d10-9e0b-a4395ac6db11
          echo 'Loading kernel /boot/rear-kernel ...'
          linux  /boot/rear-kernel selinux=0 console=ttyS0,9600 console=tty0
          echo 'Loading initrd /boot/rear-initrd.cgz (may take a while) ...'
          initrd /boot/rear-initrd.cgz
}
EOF

which results that I can boot it only as GRUB 2 superuser.

With my latest commit I use different
linux and initrd values for /boot/grub2/grub.cfg
depending on the Linux distribution
at least for now (until a generic solution is found).

Currently the absolute path for SLE and openSUSE
and for all others we assume Red Hat behaviour as
default/fallback which is the basename plus a leading slash.

This means for SLE and openSUSE
one gets in /etc/grub.d/45_rear

linux /boot/rear-kernel ...
initrd /boot/rear-initrd.cgz

for all others one gets

linux /rear-kernel ...
initrd /rear-initrd.cgz

which should (hopefully) fix
#703 (comment)

From my current point of view the GRUB_RESCUE functionality
should now work sufficiently well for GRUB 2
on SUSE and Red Hat based Linux distributions.

When there are no objections
I will merge it in a few hours
to have the current state in GitHub master code
so that also other rear users can test it more easily.

Ha!
Now #942 (comment)
reads "2 hours ago" which is sufficient for "a few hours"
so that now I can merge it!

See the follow-up issue #946