#2681 Issue closed: Error when booting with rear uefi iso¶
Labels: support / question, won't fix / can't fix / obsolete
RolfWeilen opened issue at 2021-09-27 12:31:¶
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
RolfWeilen commented at 2021-09-27 12:32:¶
RolfWeilen commented at 2021-09-27 12:40:¶
Booting to rear menue work
Choosen the UEFI XCC virtual Media
gdha commented at 2021-09-27 13:47:¶
@RolfWeilen Please have a look at comment
https://github.com/rear/rear/issues/1193#issuecomment-451450705
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 commented at 2021-09-27 15:18:¶
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 commented at 2021-09-27 16:07:¶
@jsmeix Might it be that PR
https://github.com/rear/rear/commit/b81693f27a41482ed89da36a9af664fe808f8186
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 commented at 2021-09-27 16:36:¶
@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 commented at 2021-09-27 16:41:¶
Hi
The initrd is about 611MB. The hole iso is 729.606MB.
RolfWeilen commented at 2021-09-27 16:42:¶
# 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 commented at 2021-09-27 16:54:¶
@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 commented at 2021-09-28 07:40:¶
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
https://github.com/rear/rear/discussions/2640#discussioncomment-908335
RolfWeilen commented at 2021-09-28 07:54:¶
Hi
I will try to reduce the image and give feedback as soon as possible.
Rolf
RolfWeilen commented at 2021-09-28 13:57:¶
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 commented at 2021-09-28 14:17:¶
@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 commented at 2021-09-29 13:17:¶
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 commented at 2021-09-29 13:45:¶
@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 commented at 2021-09-29 14:15:¶
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 commented at 2021-09-29 14:38:¶
Should we address this to redhat support
Yes, please address it to support, and also try on a different hardware.
jsmeix commented at 2021-09-30 06:56:¶
@RolfWeilen
regarding your question
Should i generally exclude firmware for rear recover
or is there any need to include the firmware?
in your https://github.com/rear/rear/issues/2681#issuecomment-929246756 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 commented at 2021-11-30 02:01:¶
Stale issue message
RolfWeilen commented at 2021-12-01 10:03:¶
We can close the case. I will test it again with RHL 8.5 and will then open the case by redhat.
pcahyna commented at 2023-05-16 17:04:¶
Hi @RolfWeilen, I saw a similar issue, for me it is fixed in grub2-2.02-121.el8 - try this build of GRUB2.
[Export of Github issue for rear/rear.]