#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"):
OUTPUT_URL=file:///var/tmp
BACKUP=NETFS
BACKUP_URL=iso://backup
BACKUP_PROG_EXCLUDE=( ${BACKUP_PROG_EXCLUDE[@]} '/var/tmp' ........ )
ISO_MAX_SIZE=4400
-
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):
x86 -
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):
local -
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
before:
linux /isolinux/kernel ...
initrd /isolinux/initrd.cgz
after:
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?
V.
gozora commented at 2020-06-22 17:54:¶
@dhoffend what version of ovmf are you using ?
V.
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:¶
@pcahyna
I don't think this is the case, On my Debian Buster:
# type -p grub; echo $?
1
I'm remembering to had similar issue with USB boot. Need to look it up.
V.
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
Buster rear-2.6 (grub-mkstandalone) Boot FAIL
Centos7 rear-2.6 (grub-mkstandalone) Boot OK
V.
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
V.
pcahyna commented at 2020-06-22 19:35:¶
Is it possible that search does not behave properly?
https://github.com/rear/rear/blob/01249e13dbcc6d1447069ff7cf172ad033eb6b8e/usr/share/rear/lib/bootloader-functions.sh#L516
gozora commented at 2020-06-22 19:47:¶
@pcahyna
Yes ...
V.
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 ...
V.
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:
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
EDIT:
search by label also works fine for OUTPUT=USB
V.
gozora commented at 2020-06-23 11:54:¶
@pcahyna will you work on fix for this issue or you want me to fix it?
V.
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:¶
@dhoffend
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.
FYI
you may have a look at the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
[Export of Github issue for rear/rear.]