#2434 Issue closed: UEFI ISO won't boot with rear 2.6

Labels: bug, fixed / solved / done

dhoffend opened issue at 2020-06-22 16:13:

Relax-and-Recover (ReaR) Issue Template

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

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.6 / 2020-06-17

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    Debian GNU/Linux 10 (buster)

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

BACKUP_PROG_EXCLUDE=( ${BACKUP_PROG_EXCLUDE[@]} '/var/tmp' ........ )
  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    KVM VM

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI (ovmf, tianocore on debian9 libvirt) + grub 2.0.2+dfsg1-20

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

  • Description of the issue (ideally so that others can reproduce it):
    With rear-2.5-0 we could create bootable UEFI ISOs. With rear-2.6-0 we get the error message

Loading kernel ...
error: file '/isolinux/kernel' not found.
Loading initial ramdisk
error: you need to load the kernel first.

It looks like the grub load doesn't search for the kernel on the loaded iso image. We downgraded to rear-2.5-0 and created the same
  • Workaround, if any:
edit the grub commands

linux /isolinux/kernel ...
initrd /isolinux/initrd.cgz

linux (cd0)/isolinux/kernel ...
initrd (cd0)/isolinux/initrd.cgz

F10 to boot

gozora commented at 2020-06-22 16:46:

Strange, was booting on Qemu Tianocore yesterday without problem.
Either way we have changed a bit way how bootable image is created.
@pcahyna can you please take a look what can be wrong here?


gozora commented at 2020-06-22 17:54:

@dhoffend what version of ovmf are you using ?


dhoffend commented at 2020-06-22 18:04:

Afaik I’m using the ovmf version shipped with Debian 9 ovmf (0~20161202.7bbe0b3e-1+deb9u1)

EFI booting works again after downgrading to 2.5. I've to analyze the logs to find a difference in both logs

pcahyna commented at 2020-06-22 18:10:

I changed the way how Grub works in UEFI ISOs in #2293. We tested that change on SLES and RHEL, but not on Debian (nor Ubuntu).

pcahyna commented at 2020-06-22 18:25:

@dhoffend what does type -p grub print when executed as root? I suspect in your case ReaR may be taking this branch:


gozora commented at 2020-06-22 19:09:

I don't think this is the case, On my Debian Buster:

# type -p grub; echo $?

I'm remembering to had similar issue with USB boot. Need to look it up.


gozora commented at 2020-06-22 19:14:

I think that something is grub-mkstandalone behaves differently on different distros:

Buster rear-2.5 (grub-mkimage) - Boot OK
Screenshot from 2020-06-22

Buster rear-2.6 (grub-mkstandalone) Boot FAIL
Screenshot from 2020-06-22

Centos7 rear-2.6 (grub-mkstandalone) Boot OK
Screenshot from 2020-06-22


gozora commented at 2020-06-22 19:27:

Screenshots in https://github.com/rear/rear/issues/2434#issuecomment-647721588 were made on Qemu.

Funny enough, same image that doesn't boot on Qemu boots in VirtualBox just fine:

Buster rear-2.6 VirtualBox (grub-mkstandalone) Boot OK
Screenshot from 2020-06-22


pcahyna commented at 2020-06-22 19:35:

Is it possible that search does not behave properly?

gozora commented at 2020-06-22 19:47:


Yes ...
Screenshot from 2020-06-22


pcahyna commented at 2020-06-22 19:52:

we then have to set a fallback: if search does not succeed, set root to cd0. (Actually, it will be enough to set root to cd0 before calling search.) This will be equivalent to the previous behavior: https://github.com/rear/rear/pull/2293/files#diff-2299bb436f1322dbe98ff15c1a26ba37L66

gozora commented at 2020-06-22 20:02:

We have to be cautious with setting root=cd0 because create_grub2_cfg() is used to create bootable USB too ...


gozora commented at 2020-06-22 20:04:


gozora commented at 2020-06-22 21:00:

Another fun fact.
I just tried search when booted from USB in Qemu with ReaR recovery system created with rear-2.6 and it looks to be working:
Screenshot from 2020-06-22

Apart from that I was able to successfully boot from USB (rear-2.6) in Qemu, so it looks like this issue does not affect OUTPUT=USB

search by label also works fine for OUTPUT=USB
Screenshot from 2020-06-22


gozora commented at 2020-06-23 11:54:

@pcahyna will you work on fix for this issue or you want me to fix it?


pcahyna commented at 2020-06-23 16:13:

@gozora I am working on it.

pcahyna commented at 2020-06-23 16:29:

Please look at https://github.com/pcahyna/rear/tree/uefi_unset_grub_root (not tested yet).

pcahyna commented at 2020-06-23 16:31:

@yontalcar can you please test it?

yontalcar commented at 2020-06-24 11:12:

I'll do tests on RHEL 7 and 8. I might do tests on Debian later.

yontalcar commented at 2020-06-26 12:01:

RHEL 7 and 8 look good.

pcahyna commented at 2020-07-03 15:47:

@gozora @dhoffend does #2453 fix the problem for you please?

dhoffend commented at 2020-07-13 14:00:

@pcahyna @gozora @dhoffend does #2453 fix the problem for you please?

Sorry for being late. I can confirm this change fixed the problem and using rear 2.6 with fixed files (manually patched) made the created ISO boots up. Thank you all.

jsmeix commented at 2020-07-13 14:14:

thank you for your explicit confirmation that it also works for you. It is much appreciated.
Don't worry about being late - no rush - we are not doing a ReaR release right now.

you may have a look at the section
"Testing current ReaR upstream GitHub master code" in

[Export of Github issue for rear/rear.]