Error when booting with rear uefi iso #2681

RolfWeilen · 2021-09-27T12:31:30Z

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
rpm: rear-2.6.5-1.el7.x86_64
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=8.3
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
AUTOEXCLUDE_MULTIPATH=N
OUTPUT=ISO
OUTPUT_URL=null
ISO_DEFAULT=manuel
TIMESYNC=NTP
BACKUP=TSM
TSM_RESULT_SAVE=n
TSM_RESULT_FILE_PATH=
USE_DHCLIENT=y
USE_STATIC_NETWORKING=
ONLY_INCLUDE_VG=(s53r010vg00)
GRUB_RESCUE=n
WAIT_SECS=31104000
SSH_ROOT_PASSWORD=rear
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
BareMetal
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
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
SAN
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME                                                KNAME      PKNAME    TRAN TYPE  FSTYPE         SIZE MOUNTPOINT
/dev/sda                                            /dev/sda             fc   disk  mpath_member   240G 
`-/dev/mapper/360060e8007e2ce000030e2ce00002041     /dev/dm-0  /dev/sda       mpath                240G 
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p1 /dev/dm-1  /dev/dm-0      part  vfat           200M /boot/efi
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p2 /dev/dm-2  /dev/dm-0      part  xfs              2G /boot
  `-/dev/mapper/360060e8007e2ce000030e2ce00002041p3 /dev/dm-3  /dev/dm-0      part  LVM2_member  237.9G 
    |-/dev/mapper/s53r010vg00-root                  /dev/dm-4  /dev/dm-3      lvm   xfs             50G /
    |-/dev/mapper/s53r010vg00-swap                  /dev/dm-5  /dev/dm-3      lvm   swap            16G [SWAP]
    |-/dev/mapper/s53r010vg00-alib                  /dev/dm-6  /dev/dm-3      lvm   xfs              5G /app/lib
    |-/dev/mapper/s53r010vg00-home                  /dev/dm-7  /dev/dm-3      lvm   xfs              5G /home
    |-/dev/mapper/s53r010vg00-vlsu                  /dev/dm-8  /dev/dm-3      lvm   xfs              5G /var/log/suva
    |-/dev/mapper/s53r010vg00-vlog                  /dev/dm-9  /dev/dm-3      lvm   xfs              5G /var/log
    `-/dev/mapper/s53r010vg00-uloc                  /dev/dm-10 /dev/dm-3      lvm   xfs              5G /usr/local
/dev/sdb                                            /dev/sdb             fc   disk  mpath_member   240G 
`-/dev/mapper/360060e8007e2ce000030e2ce00002041     /dev/dm-0  /dev/sdb       mpath                240G 
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p1 /dev/dm-1  /dev/dm-0      part  vfat           200M /boot/efi
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p2 /dev/dm-2  /dev/dm-0      part  xfs              2G /boot
  `-/dev/mapper/360060e8007e2ce000030e2ce00002041p3 /dev/dm-3  /dev/dm-0      part  LVM2_member  237.9G 
    |-/dev/mapper/s53r010vg00-root                  /dev/dm-4  /dev/dm-3      lvm   xfs             50G /
    |-/dev/mapper/s53r010vg00-swap                  /dev/dm-5  /dev/dm-3      lvm   swap            16G [SWAP]
    |-/dev/mapper/s53r010vg00-alib                  /dev/dm-6  /dev/dm-3      lvm   xfs              5G /app/lib
    |-/dev/mapper/s53r010vg00-home                  /dev/dm-7  /dev/dm-3      lvm   xfs              5G /home
    |-/dev/mapper/s53r010vg00-vlsu                  /dev/dm-8  /dev/dm-3      lvm   xfs              5G /var/log/suva
    |-/dev/mapper/s53r010vg00-vlog                  /dev/dm-9  /dev/dm-3      lvm   xfs              5G /var/log
    `-/dev/mapper/s53r010vg00-uloc                  /dev/dm-10 /dev/dm-3      lvm   xfs              5G /usr/local
/dev/sdc                                            /dev/sdc             fc   disk  mpath_member   240G 
`-/dev/mapper/360060e8007e2ce000030e2ce00002041     /dev/dm-0  /dev/sdc       mpath                240G 
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p1 /dev/dm-1  /dev/dm-0      part  vfat           200M /boot/efi
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p2 /dev/dm-2  /dev/dm-0      part  xfs              2G /boot
  `-/dev/mapper/360060e8007e2ce000030e2ce00002041p3 /dev/dm-3  /dev/dm-0      part  LVM2_member  237.9G 
    |-/dev/mapper/s53r010vg00-root                  /dev/dm-4  /dev/dm-3      lvm   xfs             50G /
    |-/dev/mapper/s53r010vg00-swap                  /dev/dm-5  /dev/dm-3      lvm   swap            16G [SWAP]
    |-/dev/mapper/s53r010vg00-alib                  /dev/dm-6  /dev/dm-3      lvm   xfs              5G /app/lib
    |-/dev/mapper/s53r010vg00-home                  /dev/dm-7  /dev/dm-3      lvm   xfs              5G /home
    |-/dev/mapper/s53r010vg00-vlsu                  /dev/dm-8  /dev/dm-3      lvm   xfs              5G /var/log/suva
    |-/dev/mapper/s53r010vg00-vlog                  /dev/dm-9  /dev/dm-3      lvm   xfs              5G /var/log
    `-/dev/mapper/s53r010vg00-uloc                  /dev/dm-10 /dev/dm-3      lvm   xfs              5G /usr/local
/dev/sdd                                            /dev/sdd             fc   disk  mpath_member   240G 
`-/dev/mapper/360060e8007e2ce000030e2ce00002041     /dev/dm-0  /dev/sdd       mpath                240G 
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p1 /dev/dm-1  /dev/dm-0      part  vfat           200M /boot/efi
  |-/dev/mapper/360060e8007e2ce000030e2ce00002041p2 /dev/dm-2  /dev/dm-0      part  xfs              2G /boot
  `-/dev/mapper/360060e8007e2ce000030e2ce00002041p3 /dev/dm-3  /dev/dm-0      part  LVM2_member  237.9G 
    |-/dev/mapper/s53r010vg00-root                  /dev/dm-4  /dev/dm-3      lvm   xfs             50G /
    |-/dev/mapper/s53r010vg00-swap                  /dev/dm-5  /dev/dm-3      lvm   swap            16G [SWAP]
    |-/dev/mapper/s53r010vg00-alib                  /dev/dm-6  /dev/dm-3      lvm   xfs              5G /app/lib
    |-/dev/mapper/s53r010vg00-home                  /dev/dm-7  /dev/dm-3      lvm   xfs              5G /home
    |-/dev/mapper/s53r010vg00-vlsu                  /dev/dm-8  /dev/dm-3      lvm   xfs              5G /var/log/suva
    |-/dev/mapper/s53r010vg00-vlog                  /dev/dm-9  /dev/dm-3      lvm   xfs              5G /var/log
    `-/dev/mapper/s53r010vg00-uloc                  /dev/dm-10 /dev/dm-3      lvm   xfs              5G /usr/local
/dev/sr0                                            /dev/sr0             usb  rom   udf          712.5M

Description of the issue (ideally so that others can reproduce it):
We trie to use uefi on linux. When i try to boot from rear iso on system i get the error on console:

Loading Kernel ....
Loading initial ramdisk ....
error: ../../grub-core/loader/i1386/efi/linux.c:119:can't allocate initrd.
Press any key to continue
...
...
Kernel panic

Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

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
```

Best Reagrds
Rolf Weilenmann

The text was updated successfully, but these errors were encountered:

RolfWeilen · 2021-09-27T12:32:56Z

RolfWeilen · 2021-09-27T12:40:06Z

Booting to rear menue work
Choosen the UEFI XCC virtual Media

gdha · 2021-09-27T13:47:38Z

@RolfWeilen Please have a look at comment #1193 (comment) it may help you.
Did you inspec the rear.log file for specific errors? Missing libraries? Looks like the inital ramdisk was not fully created as it should. You could attach the rear.log file as reference.

Did you try to boot ReaR in Secure Boot to see if it changes the boot behavior?

RolfWeilen · 2021-09-27T15:18:52Z

Hi
The package is installed: grub2-efi-x64-modules.noarch 1:2.02-99.el8

secure boot shows the same problem.
On ISO File the grub.cfg shows different entries for secure boot and normal boot:

menuentry "Relax-and-Recover (no Secure Boot)"  --class gnu-linux --class gnu --class os {
     echo 'Loading kernel ...'
     linux /isolinux/kernel root=UUID=b822c52d-63b1-492a-b31c-9ed40a9940d5 selinux=0 console=ttyS0,9600 console=ttyS1,115200 console=tty0
     echo 'Loading initial ramdisk ...'
     initrd /isolinux/initrd.cgz
}

menuentry "Relax-and-Recover (Secure Boot)"  --class gnu-linux --class gnu --class os {
     echo 'Loading kernel ...'
     linuxefi /isolinux/kernel root=UUID=b822c52d-63b1-492a-b31c-9ed40a9940d5 selinux=0 console=ttyS0,9600 console=ttyS1,115200 console=tty0
     echo 'Loading initial ramdisk ...'
     initrdefi /isolinux/initrd.cgz
}

I have attached the log.
Thanks a lot for your help.

Best regards
Rolf
rear-s53r010.log

gdha · 2021-09-27T16:07:20Z

@jsmeix Might it be that PR b81693f does not have the same effect on RHEL8 then it has on SLES12 SP1? Referring to the root_uuid=b822c52d-63b1-492a-b31c-9ed40a9940d5 saving via the function create_grub2_rear_boot_entry? Why does linux or linuxefi entries point to the internal root disk?

pcahyna · 2021-09-27T16:36:03Z

@RolfWeilen the error message

error: ../../grub-core/loader/i1386/efi/linux.c:119:can't allocate initrd.

seems to mean that grub is out of memory.
How large is the initrd file on the ISO?

RolfWeilen · 2021-09-27T16:41:40Z

Hi
The initrd is about 611MB. The hole iso is 729.606MB.

RolfWeilen · 2021-09-27T16:42:45Z

# ls -l /var/lib/rear/output/rear-s53r010.iso
-rw-------. 1 root root 747130880 Sep 27 14:03 /var/lib/rear/output/rear-s53r010.iso

pcahyna · 2021-09-27T16:54:01Z

@RolfWeilen are you able to recreate another ISO and test it? I suggest to omit BACKUP=TSM and produce an image using rear mkrescue (hopefully it will be smaller) and boot it. Of course, it will not contain the TSM utilities, so it will not be that useful for backup restoration, but at least it will help to isolate the problem.

jsmeix · 2021-09-28T07:40:42Z

By googling for "grub can't allocate initrd" I found in particular:

https://bugzilla.redhat.com/show_bug.cgi?id=1572126
which is an old issue where the initial comment reads (excerpts)

We use a rather large initrd, around 300-500MB
...
On a Dell XPS 15 9550 grub will state when loading initrd:
  error: can't allocate initrd.
This is the first system we see this issue on, whilst we run this
on a lot of different hardware configurations. One of the most notable
differences is that this system actually has much more memory than usual.

And that one is a more current issue
https://answers.launchpad.net/ubuntu/+question/695353
and its last comment tells (excerpt)

The image wasn't being loaded because the size was too big.
After reducing the size the new kernel is work.

In general regaring the size of the ReaR recovery system
and how it could be reduced see also
#2640 (comment)

RolfWeilen · 2021-09-28T07:54:32Z

Hi
I will try to reduce the image and give feedback as soon as possible.
Rolf

RolfWeilen · 2021-09-28T13:57:03Z

Hi
I tried the hint to exclude the firmware
FIRMWARE_FILES=( 'no' ):
The iso is now about 680MB big.
The initrd.cgz about 350MB.
The system is now booting with this iso.
Should i generally exclude firmware for rear recover or is there any need to include the firmware?

Best regards
Rolf

gdha · 2021-09-28T14:17:08Z

@RolfWeilen If the ISO image created is meant to recover this system only then there is not need to load all firmware (kernel) modules. If there is a need to clone on slightly different hardware than it is a good idea to include all firmware (kernel) modules.

RolfWeilen · 2021-09-29T13:17:06Z

Hi
I guess not booting from an to big initrd is not a rear problem.
Should we address this to redhat support or is it simple not possible booting from initrd with an size of 611MB.
I can try it on different hw.
regards
Rolf

pcahyna · 2021-09-29T13:45:07Z

@jsmeix thanks for locating the related bug reports. "It appears to me that there have been quite some changes to the memory allocation stuff already which seem to have resolved the issue.

It works with current git version. " indicates that maybe grub2 in RHEL 7 is too old and RHEL 8 could work (not sure if the fix is in RHEL 8, but it could be).

pcahyna · 2021-09-29T14:15:42Z

grub2 in RHEL 7 is too old and RHEL 8 could work (not sure if the fix is in RHEL 8, but it could be)

Sorry, I see now this is RHEL 8, I got confused by rear-2.6.5-1.el7.x86_64.

Is it 32-bit UEFI by chance? Do you have a grub2-efi-ia32 package?

pcahyna · 2021-09-29T14:38:18Z

Should we address this to redhat support

Yes, please address it to support, and also try on a different hardware.

jsmeix · 2021-09-30T06:56:53Z

@RolfWeilen
regarding your question

Should i generally exclude firmware for rear recover
or is there any need to include the firmware?

in your #2681 (comment) above:

You may need certain firmware to recover on exactly same hardware
when that hardware needs firmware.
E.g. some network interface cards need firmware so without their firmware
inside the ReaR recovery system those network interface cards won't work
within the ReaR recovery system so possibly no network for "rear recover".

According to
https://serverfault.com/questions/1026598/know-which-firmware-my-linux-kernel-has-loaded-since-booting

Background information:
You cannot query for "currently loaded" firmware, because
firmware doesn't necessarily remain in system memory.
It is often uploaded to some chip in some device outside the system.
Drivers usually load a firmware file into a kernel buffer,
use that buffer to program the device, then discard the buffer
without keeping any record of what the file was.
And the standard kernel firmware API does not keep a log by default.
Some drivers do log their firmware loading to the kernel log,
but it's not universal.

you need some "hacks" to find out what exact firmware files
are needed by your exact hardware (if any), see the details in
https://serverfault.com/questions/1026598/know-which-firmware-my-linux-kernel-has-loaded-since-booting

github-actions · 2021-11-30T02:01:17Z

Stale issue message

RolfWeilen · 2021-12-01T10:03:15Z

We can close the case. I will test it again with RHL 8.5 and will then open the case by redhat.

pcahyna · 2023-05-16T17:04:43Z

Hi @RolfWeilen, I saw a similar issue, for me it is fixed in grub2-2.02-121.el8 - try this build of GRUB2.

dragon299 · 2023-08-29T07:05:43Z

Hi, I am facing the same issue with OL8.8 and grub2-efi-x64-2.02-148.0.1.el8.x86_64. Has anyone find a better fix in the meantime than excluding the firmware files?

pcahyna · 2023-08-29T09:20:02Z

@dragon299 I was seeing the same issue on a HP ProLiant DL180 Gen9 machine. Is your problem also related to HP hardware? In may case it seems to be solved by a firmware upgrade. The error was also fixed (without a firmware upgrade) in grub2-2.02-121.el8 and then reappeared in grub2-1:2.02-142 . It is apparently related to this entry in %changelog (rpm -q --changelog grub2-efi-x64):

- Drop the arena size changes
- Resolves: #2118896

So I suggest to upgrade the firmware, of if this is not possible or does not help, to downgrade GRUB to a version between 2.02-121.el8 and grub2-1:2.02-141.el8.

pcahyna · 2023-08-29T09:20:23Z

https://bugzilla.redhat.com/show_bug.cgi?id=2207732

jsmeix added the support / question label Sep 27, 2021

gdha assigned gdha and jsmeix Sep 27, 2021

github-actions bot added the no-issue-activity label Nov 30, 2021

RolfWeilen closed this as completed Dec 1, 2021

jsmeix added won't fix / can't fix / obsolete and removed no-issue-activity labels Dec 1, 2021

pcahyna mentioned this issue Mar 27, 2024

error: ../../grub-core/loader/i386/efi/linux.c:158:can't allocate initrd #3186

Open

jsmeix added external tool The issue depends on other software e.g. third-party backup tools. not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. special hardware or VM The issue depends on non common (virtual) hardware. labels Mar 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error when booting with rear uefi iso #2681

Error when booting with rear uefi iso #2681

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix

RolfWeilen commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021

gdha commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix

gdha commented Sep 27, 2021

pcahyna commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix

pcahyna commented Sep 27, 2021

jsmeix commented Sep 28, 2021

RolfWeilen commented Sep 28, 2021

RolfWeilen commented Sep 28, 2021

gdha commented Sep 28, 2021

RolfWeilen commented Sep 29, 2021

pcahyna commented Sep 29, 2021

pcahyna commented Sep 29, 2021

pcahyna commented Sep 29, 2021

jsmeix commented Sep 30, 2021

github-actions bot commented Nov 30, 2021

RolfWeilen commented Dec 1, 2021

pcahyna commented May 16, 2023

dragon299 commented Aug 29, 2023

pcahyna commented Aug 29, 2023

pcahyna commented Aug 29, 2023

Error when booting with rear uefi iso #2681

Error when booting with rear uefi iso #2681

Comments

RolfWeilen commented Sep 27, 2021 • edited by jsmeix

Relax-and-Recover (ReaR) Issue Template

RolfWeilen commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021

gdha commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021 • edited by jsmeix

gdha commented Sep 27, 2021

pcahyna commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021

RolfWeilen commented Sep 27, 2021 • edited by jsmeix

pcahyna commented Sep 27, 2021

jsmeix commented Sep 28, 2021

RolfWeilen commented Sep 28, 2021

RolfWeilen commented Sep 28, 2021

gdha commented Sep 28, 2021

RolfWeilen commented Sep 29, 2021

pcahyna commented Sep 29, 2021

pcahyna commented Sep 29, 2021

pcahyna commented Sep 29, 2021

jsmeix commented Sep 30, 2021

github-actions bot commented Nov 30, 2021

RolfWeilen commented Dec 1, 2021

pcahyna commented May 16, 2023

dragon299 commented Aug 29, 2023

pcahyna commented Aug 29, 2023

pcahyna commented Aug 29, 2023

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix

RolfWeilen commented Sep 27, 2021 •

edited by jsmeix