#2585 Issue closed: REAR image does not boot in UEFI ( only on physical machine ). Used latest rear 2.6 version

Labels: support / question, no-issue-activity

cvijayvinoth opened issue at 2021-03-09 07:32:

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 / Git

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    NAME="CentOS Linux"
    VERSION="7 (Core)"
    ID="centos"
    ID_LIKE="rhel fedora"
    VERSION_ID="7"
    PRETTY_NAME="CentOS Linux 7 (Core)"
    ANSI_COLOR="0;31"
    CPE_NAME="cpe:/o:centos:centos:7"
    HOME_URL="https://www.centos.org/"
    BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
    OUTPUT=ISO
    BACKUP=RSYNC
    RSYNC_PREFIX="yuvaraj1_${HOSTNAME}"
    BACKUP_PROG="/var/www/html/imageBackup/rsync"
    OUTPUT_URL=rsync://yuvaraj1@192.168.1.123::rsync_backup
    BACKUP_URL=rsync://yuvaraj1@192.168.1.123::rsync_backup
    ISO_DIR="/var/www/html/imageBackup/iso/$HOSTNAME"
    MESSAGE_PREFIX="$$: "
    PROGRESS_MODE="plain"
    AUTOEXCLUDE_PATH=( /tmp )
    PROGRESS_WAIT_SECONDS="1"
    export TMPDIR="/var/www/html/imageBackup/iso/"
    PXE_RECOVER_MODE=automatic
    ISO_FILES=("/var/www/html/imageBackup/rsync")
    ISO_PREFIX="${HOSTNAME}"

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): PC

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

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI and GRUB

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

(DM or NVMe): local disk

  • 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):
    NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
    /dev/sda /dev/sda ata disk 298.1G
    |-/dev/sda1 /dev/sda1 /dev/sda part vfat 200M /boot/efi
    |-/dev/sda2 /dev/sda2 /dev/sda part xfs 1G /boot
    -/dev/sda3 /dev/sda3 /dev/sda part LVM2_member 296.9G |-/dev/mapper/centos-root /dev/dm-0 /dev/sda3 lvm xfs 50G / |-/dev/mapper/centos-swap /dev/dm-1 /dev/sda3 lvm swap 7.8G [SWAP]-/dev/mapper/centos-home /dev/dm-2 /dev/sda3 lvm xfs 239.1G /home
    /dev/sdb /dev/sdb ata disk 465.8G
    |-/dev/sdb1 /dev/sdb1 /dev/sdb part ext4 238.4G
    `-/dev/sdb2 /dev/sdb2 /dev/sdb part ext4 227.4G

  • Workaround, if any:
    error: file `/isolinux/kernel' not found.
    Loading initial ramdisk ...
    error: you need to load the kernel first.
    Press any key to continue...

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files): mkbackup
    rear-centos-7.log

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
verbatim content
```

pcahyna commented at 2021-03-09 09:30:

Hello. There were some changes in the UEFI bootloader support, can you please try a version without those changes? You can try the rear-2.4 package included in CentOS, because it does not have the changes in question.

By the way, does "only on physical machine" mean that on a virtual machine it is working properly?

cvijayvinoth commented at 2021-03-09 09:53:

Yes it is working fine in virtual machine. Ok let me try with rear-2.4

pcahyna commented at 2021-03-09 10:01:

Note that you will need the grub2-efi-x64-modules package, I believe it is not installed by default.

cvijayvinoth commented at 2021-03-09 10:17:

@pcahyna : Thanks for your update. I haven't install this package. let me install it and verify once again.

pcahyna commented at 2021-03-09 10:19:

ReaR from CentOS should warn you that you need this package if you don't have it.

cvijayvinoth commented at 2021-03-09 12:19:

Thanks @pcahyna. Its working fine with rear2.4. Looks I can't use rear-2.6.

pcahyna commented at 2021-03-09 12:51:

@cvijayvinoth if you press any key to continue when GRUB stops, do you get to the GRUB command line? If so, can you please try echo ${root} at the command line?

pcahyna commented at 2021-03-09 12:59:

By the way, do you use ReaR from Git? If so, does your version contain the commit 60f28eea7864227a8cea4d543031babee290d1fc? I am asking because you say that you are using 2.6 and your issue looks a lot like #2434 (resolved in #2453), and this fix is planned for 2.7, not for 2.6.

jsmeix commented at 2021-03-09 13:03:

@cvijayvinoth
to try out our current ReaR GitHub master code see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

cvijayvinoth commented at 2021-03-09 13:09:

@jsmeix : yes I have been used 2.6 version from git only.

pcahyna commented at 2021-03-09 13:10:

@jsmeix thanks, indeed GitHub master should fix the issue.
I am thinking what would be possible workaround for those that have created rescue media using 2.6 and the media don't boot...
I suspect it could be as simple as issuing the commands

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

manually in the GRUB command line.
@cvijayvinoth can you please attempt this workaround?

cvijayvinoth commented at 2021-03-09 13:15:

sure let me try once @pcahyna. I have used edit option on the menu ( pressed e ) and updated (cd0) before the /isolinux. It didn't work. Let me check with GRUB command line manually and update.

pcahyna commented at 2021-03-09 13:17:

I am asking because you say that you are using 2.6

My bad, I have not realized that the latest Git version identifies itself as "Relax-and-Recover 2.6 / Git", not as 2.7.

cvijayvinoth commented at 2021-03-09 13:18:

Could you please share the link location for 2.7 version? Let me try with that too once.

pcahyna commented at 2021-03-09 13:22:

2.7 has not been released yet, if you use master branch from Github, you get what will eventually become 2.7 when released. Is that what you have been using?

cvijayvinoth commented at 2021-03-09 13:28:

yes... I am using the master branch only.

pcahyna commented at 2021-03-09 13:32:

Can you please try several other things?
git commit 2be7f8b1728d0b8b1eacbd476fe011211a14f052 - that's the git version just before the merge that possibly caused the issue
git commit c9e61bad2cb365f42b500f07bc43b3c9e38d41f4 - that's immediately after
and in a version which works (like 2.4), try interrupting GRUB in the rescue CD and in the command line, enter
echo ${root} ${prefix}
and report the result.

cvijayvinoth commented at 2021-03-09 13:37:

sure @pcahyna. Now the restore is going on with rear 2.4 version. Let me verify post completing the current restore process.

cvijayvinoth commented at 2021-03-10 09:54:

Yes you are correct @pcahyna . After reverting the code it is working fine. Its booting now.
For rear 2.6
echo ${root} ${prefix}
hd0,msdos1 (cd0)/EFI/BOOT

pcahyna commented at 2021-03-10 10:00:

Thank you for testing. Can we make a summary what works and what does not? First iteration:

current ReaR master - broken
ReaR 2.4 from CentOS 7 repos - works
ReaR revision 2be7f8b - works?
ReaR revision c9e61ba - ?

pcahyna commented at 2021-03-10 10:04:

rear 2.6

You mean rear from Git master, not the 2.6 release, right? Anyway,

echo ${root} ${prefix}
hd0,msdos1 (cd0)/EFI/BOOT

That's very interesting. I did not expect this. I guess that it finds the EFI partition on the hard disk, instead of the EFI files on the CD.
I also think that if the disk content were completely destroyed and you were restoring entirely from scratch, this problem would not occur.

cvijayvinoth commented at 2021-03-10 10:17:

First tried with ReaR revision 2be7f8b - not working.
echo ${root} ${prefix}
cd0 (memdisk)/boot/grub

Post that with ReaR revision c9e61ba and revision 2be7f8b
works fine as expected

I missed to check ReaR revision c9e61ba only. Sorry my bad.

pcahyna commented at 2021-03-10 10:30:

so revision 2be7f8b never worked after all?

That's strange because 2be7f8b is before my changes that I suspect were causing the problem. c9e61ba is after. So my changes seem to have improved it, if I understand correctly. Now the question is, why 2.4 works, even if it is way older, and current Git version does not, even though it contains my change.

pcahyna commented at 2021-03-10 10:31:

First tried with ReaR revision 2be7f8b - not working.
echo ${root} ${prefix}
cd0 (memdisk)/boot/grub

That's strange, 2be7f8b did not use memdisk yet.

cvijayvinoth commented at 2021-03-10 10:31:

also think that if the disk content were completely destroyed and you were restoring entirely from scratch

yes, rear from Git master only.
Yes you are correct. It is finds the EFI partition on the hard disk, if the OS is exists.

cvijayvinoth commented at 2021-03-10 10:38:

so revision 2be7f8b never worked after all?

That's strange because 2be7f8b is before my changes that I suspect were causing the problem. c9e61ba is after. So my changes seem to have improved it, if I understand correctly. Now the question is, why 2.4 works, even if it is way older, and current Git version does not, even though it contains my change.

Tried with revision 2be7f8b couple of times. It never worked. Even I am trying to understand the changes in rear 2.6 code base and 2.4 version.

pcahyna commented at 2021-03-10 10:54:

Can you please try 60f28eea7864227a8cea4d543031babee290d1fc and f3469353ea4e305bf1822eb4c28b5c614ffb0535? The former is after a recent change that touched UEFI code, the latter is immediately before it.

cvijayvinoth commented at 2021-03-10 11:42:

Can you please try 60f28ee and f346935? The former is after a recent change that touched UEFI code, the latter is immediately before it.

Let me try and update you.

cvijayvinoth commented at 2021-03-10 11:46:

Found one more issue on https://github.com/rear/rear/blob/master/usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
Line number 89.

local grubdir="$( echo -n ${boot_dir}/grub* )"
test -d "$grubdir" || grubdir="${boot_dir}/grub"

grubdir For me output is: /boot/grub /boot/grub2

[root@centos-7 rear-master]# ls -al /boot/grub*
/boot/grub:
total 8
drwxr-xr-x. 2 root root   27 Feb  3 04:16 .
dr-xr-xr-x. 5 root root 4096 Mar  8 02:13 ..
-rw-r--r--. 1 root root 1350 Nov 15  2011 splash.xpm.gz

/boot/grub2:
total 28
drwx------. 5 root root   82 Mar  9 05:16 .
dr-xr-xr-x. 5 root root 4096 Mar  8 02:13 ..
drwxr-xr-x. 2 root root   25 Feb 25 23:28 fonts
-rw-r--r--. 1 root root 6075 Feb 25 01:09 grub.cfg
lrwxrwxrwx. 1 root root   25 Mar  9 05:16 grubenv -> ../efi/EFI/centos/grubenv
drwxr-xr-x. 2 root root 4096 Feb 26 00:10 locale
drwxr-xr-x. 2 root root 8192 Feb 26 00:10 x86_64-efi

Actually /boot/grub2 should be assigned for grubdir.
But As per the logic grubdir="${boot_dir}/grub" is assigned.

pcahyna commented at 2021-03-10 13:04:

Good catch, the code does not take into account the possibility of having both /boot/grub and /boot/grub2.
But this does not seem to be your problem, as this will affect only GRUB fonts and locales.
Also this code has been there for a long time.

pcahyna commented at 2021-04-15 18:26:

Can you please try 60f28ee and f346935? The former is after a recent change that touched UEFI code, the latter is immediately before it.

Let me try and update you.

Hello @cvijayvinoth , do you have any updates?

cvijayvinoth commented at 2021-04-16 06:27:

@pcahyna : sorry missed to update you. Lost the access for that device. Let me try to reproduce it on my local machine and update you on this.

github-actions commented at 2021-06-16 02:22:

Stale issue message

[Export of Github issue for rear/rear.]