#1426 Issue closed: Cannot boot from rear iso uefi

Labels: support / question, fixed / solved / done

cocampbe opened issue at 2017-07-20 13:54:

  • rear version (/usr/sbin/rear -V):

Relax-and-Recover 1.17.2 / Git

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

Oracle Linux Server release 7.3

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

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://server/rear/"
NETFS_KEEP_OLD_BACKUP_COPY=1
ONLY_INCLUDE_VG=( vg00 )

  • Are you using legacy BIOS or UEFI boot?

UEFI

  • Brief description of the issue:

We are testing rear recovery on new HP Synergy compute nodes. They are setup using UEFI. The process to make the recovery is fine. When booting from the ISO, we get the following output.

Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found

This makes sense since the iso image does not contain that file. It does contain BOOTx64.efi. I have not tried a newer version on rear as I want to stick with the one that comes with the distro. I have oracle support, so I should be able to take any info and supply it to them. They could then update the package.

I have noticed that when I run mkbackup with verbosity, I see this in the output.

Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)

So I can only assume it is not necessary in the local.conf file.

  • Work-around, if any:

cocampbe commented at 2017-07-20 15:43:

Adding log

cocampbe commented at 2017-07-20 15:44:

rear-host.zip

gozora commented at 2017-07-20 16:33:

Hello @cocampbe,

There have been lots of changes in ReaRs UEFI code since 1.17.2 so I don't even dare to guess what can be wrong in your case.
My best advice to you would be to update to version 2.1 or if you are using secure boot to HEAD of ReaRs master branch.

V.

cocampbe commented at 2017-07-20 16:39:

@gozora

I was going to try that, but since I have oracle support, I figured I would stay with the version they supply with the distro. I will open a case with them. It was worth a shot.

gozora commented at 2017-07-20 16:41:

Maybe something that might help you.
When booting, try to escape to EFI shell, cd to directory EFI/BOOT on your ISO and launch BOOTX64.efi manually.

V.

cocampbe commented at 2017-07-20 16:55:

@gozora

I did try that. It prodices this output when executed:

Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found

I am not very familiar with UEFI from this perspective. I ran the mkresuce with debugging. I noticed that shim.efi was copied to BOOTX64.efi. That seemed strange to me, but when you don't know what your looking for it's all pretty strange. ;)

cocampbe commented at 2017-07-20 17:04:

@gozora

I am going to go ahead and try the latest rear. There are a few things that do not seem correct. I noticed that the grub.cfg that is generated is not using linuxefi, nor initrdefi. That does not look correct.

cocampbe commented at 2017-07-20 17:24:

I just made a build of the latest git. It failed creating the backup. Which is fine at this point. I did notice that the verbosity is much better in the latest release. I was able to see the efi file that was going to be copied, and it wasn't the shim.efi. I beleive the correct file is /boot/efi/EFI/redhat/grubx64.efi. I am going to edit the file /usr/share/rear/output/ISO/Linux-i386/25_populate_efibootimg.sh and see what happens now.

If you don't mind, I would like to use this issue to keep track of my progress. Maybe it will help someone else. If not, please let me know. I will close the issue and track it under my repo.

gozora commented at 2017-07-20 17:34:

@carragom take a look on defaul.conf and search for UEFI_BOOTLOADER. If you set this variable to whatever *.efi booloader you are using, it should disable guess work ReaR is doing to find right files to copy.

V

cocampbe commented at 2017-07-20 18:15:

Ah, that makes sense. I will do that. Thanks.

cocampbe commented at 2017-07-20 18:55:

@gozora

That resolved my issue. Now I just don't understand the menu entries for "secure boot" vs "no secure boot". The "secure boot" entry uses linuxefi and initrdefi, but the "no secure boot entry" uses just linux and initrd. I don't think that matters, why should both be using the *efi commands.

Thanks for your assistance.

gozora commented at 2017-07-20 20:05:

That menu entries exists for compatibily reasons.
You would not believe how variable can UEFI boot be.
To put it simple, if one of the entries doesnt work you can try anther one ;-).

V.

[Export of Github issue for rear/rear.]