#1264 Issue `closed`: Get "grub>" prompt and not booting, after "rear recover" done and reboot with UEFI¶

Labels: support / question, fixed / solved / done

DongIn0916 opened issue at 2017-03-27 04:34:¶

#### Relax-and-Recover (rear) Issue Template¶

Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):

rear version (/usr/sbin/rear -V): 1.19-2 and 2.00-2
OS version (cat /etc/rear/os.conf or lsb_release -a): RHEL 6.7
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

OUTPUT=ISO
BACKUP=NETFS
USING_UEFI_BOOTLOADER=1
AUTOEXCLUDE_MULTIPATH=n  
BOOT_OVER_SAN=y         
NETFS_URL=nfs://16.151.73.77/home/shindig
NETFS_KEEP_OLD_BACKUP_COPY=no
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/dev/shm' '/var/tmp/*' '/tmp/*' '/var/crash/*')
KERNEL_CMDLINE="biosdevname=1"

Are you using legacy BIOS or UEFI boot? UEFI Boot
Brief description of the issue:
Hello, last week, I have tested rear tool as the following environment:
Rear : 1.19-2 and 2.00-2
OS : RHEL V6.7
HW : HPE Superdome X + 3PAR Storage
Boot Mode : UEFI
Boot : SAN Boot Storage(3PAR).

I had succfully done rear backup and recover by the above configuration, but I have got to grub prompt "grub>" after booting.
I need your help about the reason and the solution of booting failure at grub.
I recreated bootloader by efibootmgr command, but this issue has occurred again by the follwing command:

# efibootmgr –c –d /dev/mapper/device-name –L “Redhat xxxxx” –l \EFI\redhat\grub.efi

Work-around, if any: None

jsmeix commented at 2017-03-27 08:32:¶

@gozora
I dare to assign this issue to you because it is about UEFI.

I noticed that in this case there is "BOOT_OVER_SAN=y"
together with "USING_UEFI_BOOTLOADER=1" and
I wonder if that is supported at all by ReaR?

jsmeix commented at 2017-03-27 08:34:¶

@DongIn0916
what exactly do you mean with

... this issue has occurred again by the follwing command:
# efibootmgr ...

jsmeix commented at 2017-03-27 08:40:¶

@DongIn0916
in general when after "rear recover" and reboot
the recreated system cannot successfully boot,
you should first redo "rear recover" but then do not
reboot from the running ReaR recovery system
but instead keep the ReaR recovery system running
(where you are still logged in as 'root') and try to manually
install the bootloader as you need it in your particular case.
Within the running ReaR recovery system after "rear recover"
the recreated system is mounted below "/mnt/local/" so that
with appropriate "chroot /mnt/local/" commands you can
manually install your bootloader in your recreated system.

gozora commented at 2017-03-27 08:45:¶

@jsmeix thanks for trusting in UEFI skills so much :-).

@DongIn0916 my guess is that you've somehow lost grub.cfg. You can try to locate it using GRUB shell.
On my system following worked for me
grub> configfile (hd1,gpt3)/boot/grub2/grub.cfg

or you can load kernel and initrd manually

V.

gozora commented at 2017-03-27 09:02:¶

Hello @jsmeix

I noticed that in this case there is "BOOT_OVER_SAN=y"
together with "USING_UEFI_BOOTLOADER=1" and
I wonder if that is supported at all by ReaR?

Checking BOOT_OVER_SAN doesen't do really much:

# 240_include_multipath_tools.sh
# Boot Over SAN executables and other goodies

[[ $BOOT_OVER_SAN != ^[yY1] ]] && return

PROGS=( "${PROGS[@]}" multipath dmsetup kpartx multipathd scsi_id  )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /etc/multipath/bindings /etc/multipath/wwids /etc/multipath.conf )

So I guess it is compatible with USING_UEFI_BOOTLOADER ...

V.

DongIn0916 commented at 2017-03-27 09:06:¶

Tank you very much for your update.
I run efibootmgr command after rear recover done and chroot /mnt/local.
and then I run reboot command. but this issue occurred again.

jsmeix commented at 2017-03-27 11:21:¶

As UEFI and general booting noob I mainly listen here
so that I may (hopefully) learn a bit.

As far as I meanwhile understand it
"BOOT_OVER_SAN=y" together with
"USING_UEFI_BOOTLOADER=1" means that
the disk wherefrom the system is booted is connected via SAN
and on that boot disk UEFI is used.

gozora commented at 2017-03-27 15:04:¶

efibootmgr will not help you much out of this!
Did you try to load kernel and initrd from grub prompt?

V.

DongIn0916 commented at 2017-03-27 23:40:¶

No, I did not try to load them from grub.

DongIn0916 commented at 2017-03-27 23:44:¶

I would like to know the root cause of this issue that does not recognize grub bootloader with san boot environment.

gozora commented at 2017-03-28 07:35:¶

@DongIn0916 you've told that your boot end up in grub shell. That means that your boot loader is recognized ...

DongIn0916 commented at 2017-03-28 07:50:¶

I agree with your information, but I do not know the root reason. I'll try to anlyze about rear and efi san boot.

gdha commented at 2017-03-28 08:16:¶

@jsmeix @gozora BOOT_OVER_SAN piece was added for a customer that needed it to clone from internal boot disks to SAN boot disks. Therefore, the code is rather small, and perhaps today it could be removed and added by default?

DongIn0916 commented at 2017-03-31 05:28:¶

now, the system is grub menu with grub> normal and then the system is normal booting.
but I do not know the reason to drop grub commant prompt.

My detail steps are :

Step1 : I run grub-install and efibootmgr commands.
Step2 : run "shutdown -r now" command
Step3 : Drop to grub command prompt
Step4 : run normal command
grub> normal
Step5 : display grub menu
Step6 : done normal booting

jsmeix commented at 2019-04-26 12:53:¶

Because there was no further update since a long time here
I assume this issue is meanwhile somehow sufficiently solved and
https://github.com/rear/rear/issues/1264#issuecomment-290619637
indicates there is at least some workaround how to get it booted.

[Export of Github issue for rear/rear.]

#1264 Issue closed: Get "grub>" prompt and not booting, after "rear recover" done and reboot with UEFI¶