#1388 Issue closed
: rear mkbackup/mkrescue doesn't create a GRUB2 entry¶
Labels: support / question
, fixed / solved / done
AmonBune opened issue at 2017-06-20 17:00:¶
-
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 commented at 2017-06-20 17:32:¶
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 commented at 2017-06-20 17:36:¶
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 https://github.com/rear/rear/pull/942 and https://github.com/rear/rear/issues/703
starting at https://github.com/rear/rear/issues/703#issuecomment-235506494
jsmeix commented at 2018-07-18 10:29:¶
Because there are no further comments
I assume this isssue is sufficiently answered
so that I can close it hereby.
[Export of Github issue for rear/rear.]