rear mkbackup/mkrescue doesn't create a GRUB2 entry

[AmonBune]

• rear version (/usr/sbin/rear -V):
  Relax-and-Recover 2.1 / 2017-06-07

• OS version (cat /etc/rear/os.conf or lsb_release -a):

Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty

• rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

BACKUP=NETFS
BACKUP_TYPE=incremental
BACKUP_URL="file:///mnt/backupstorage0/rear-backups"
GRUB_RESCUE=1
GRUB_RESCUE_PASSWORD="Hello"

• Are you using legacy BIOS or UEFI boot?
  UEFI

• Brief description of the issue:
  My Ubuntu system is set up on an mdadm RAID1 installation. The OS is on a RAID1 and the backup partition is on another RAID1 (/mnt/backupstorage0). The GRUB installation is on a separate hard disk which is not in a RAID.
  The problem is, that when I execute "sudo rear -v mkbackup" it says everything is OK, I get no errors, but it doesn't create the GRUB2 menu entry. I also tried entering "sudo update-grub" but that doesn't help.
  The actual backup ISO is created successfully.

RAID devices info:

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [linear] [multipath] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sda[0] sdb[1]
      3906887488 blocks super 1.2 [2/2] [UU]
      [============>........]  resync = 64.8% (2531801472/3906887488) finish=170.1min speed=134694K/sec
      bitmap: 12/30 pages [48KB], 65536KB chunk

md0 : active raid1 sdd[1] sdc[0]
      31250240 blocks super 1.2 [2/2] [UU]
      
md20 : active raid0 sdh[1] sdg[0]
      976509440 blocks super 1.2 512k chunks
      
md2 : active raid0 sdj[2] sdi[1] md20[3] sdf[0]
      3906272256 blocks super 1.2 512k chunks

Mounted devices:

$ sudo df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             63G     0   63G   0% /dev
tmpfs            13G   11M   13G   1% /run
/dev/md0p1       30G  3.8G   24G  14% /
tmpfs            63G     0   63G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            63G     0   63G   0% /sys/fs/cgroup
/dev/md127p1    3.7T  6.8G  3.7T   1% /mnt/mainstorage0
/dev/sde1       1.9G  3.9M  1.9G   1% /boot/efi
/dev/md2p1      3.6T  2.8G  3.4T   1% /mnt/backupstorage0
tmpfs            13G     0   13G   0% /run/user/1000

The last few lines of the log:

2017-06-20 17:55:10 Including output/default/940_grub2_rescue.sh
2017-06-20 17:55:10 Setting up GRUB_RESCUE: Adding Relax-and-Recover rescue system to the local GRUB 2 configuration.
'/tmp/rear.xqT2NsLGbBLdXJi/tmp/initrd.cgz' -> '/boot/rear-initrd.cgz'
2017-06-20 17:55:12 Finished GRUB_RESCUE setup: Added 'Relax-and-Recover' GRUB 2 menu entry.
2017-06-20 17:55:12 Including output/default/940_grub_rescue.sh
2017-06-20 17:55:12 Including output/default/950_copy_result_files.sh
2017-06-20 17:55:12 Copying resulting files to file location
'/usr/share/rear/conf/templates/RESULT_usage_ISO.txt' -> '/tmp/rear.xqT2NsLGbBLdXJi/tmp/README'

• Work-around, if any:
  None so far

[gozora]

Hi @GamerBeast004,

By quickly checking ReaR sources GRUB_RESCUE with UEFI is a bit misleading.
ReaRs boot entry is not included in Grub but you should rather check your UEFI boot menu.
Executing efibootmgr -v should reveal ReaR boot entry.

V.

[gozora]

One more thing.
GRUB_RESCUE_PASSWORD was dropped some time ago.

Reading default.conf:

The former GRUB2 superuser setup support in ReaR via GRUB_SUPERUSER is dropped and
also the former GRUB2 password setup support in ReaR via GRUB_RESCUE_PASSWORD is dropped.
Both kind of setup can change the behaviour of the GRUB2 bootloader as a whole in unexpected ways
but ReaR is not meant to change the general GRUB2 configuration of the currently running system.
It works by default reasonably backward compatible when formerly a GRUB_SUPERUSER was used
which means a GRUB2 superuser was set up by ReaR in /etc/grub.d/01_users with GRUB_RESCUE_PASSWORD
so that the empty GRUB_RESCUE_USER results that the 'Relax-and-Recover' GRUB2 menue entry
can only be booted by the formerly set GRUB_SUPERUSER with the formerly set GRUB_RESCUE_PASSWORD.
For background information see #942 and #703
starting at #703 (comment)

[jsmeix]

Because there are no further comments
I assume this isssue is sufficiently answered
so that I can close it hereby.