#3426 Issue open: SLES15 SP6: update defaults or documentation to make EFI-bootable rescue ISO work/boot¶
Labels: support / question, external tool,
Dedicated Priority Support
thomas-merz opened issue at 2025-03-14 09:05:¶
ReaR version¶
Relax-and-Recover 2.7 / 2022-07-13
Describe the ReaR bug in detail¶
On SLES15 SP6 the EFI-boot-ISO won't boot on my EFI-boot VM on VMware (and also not on KVM/QEMU). Is this still a bug in later versions or has this been fixed in a later version?
The general info on https://documentation.suse.com/sle-ha/15-SP6/html/SLE-HA-all/cha-ha-rear.html#ex-ha-rear-config-UEFI DOESN'T help in my particular case.
My local.conf:
OUTPUT=ISO
BACKUP=CDM
OUTPUT_URL=file:///rear/iso
OUTPUT_PREFIX="hostname.example.com"
export TMPDIR="/tmp"
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/systemd/
USING_UEFI_BOOTLOADER=1
ISO_MKISOFS_BIN="/usr/bin/xorrisofs"
TIMESYNC=NTP
NETFS_KEEP_OLD_BACKUP_COPY=N
EXCLUDE_VG=()
ONLY_INCLUDE_VG=()
WAIT_SECS=120
SKIP_CFG2HTML=Y
USE_CFG2HTML=N
And no site.conf at all.
Platform¶
Linux x64
OS version¶
SUSE Linux Enterprise Server 15 SP6
Backup¶
CDM
Storage layout¶
$ lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda disk 120G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat 512M /boot/efi
|-/dev/sda2 /dev/sda2 /dev/sda part ext3 512M /boot
`-/dev/sda3 /dev/sda3 /dev/sda part LVM2_member 119G
|-/dev/mapper/systemvg-root_lv /dev/dm-0 /dev/sda3 lvm xfs 15G /
|-/dev/mapper/systemvg-usr_lv /dev/dm-1 /dev/sda3 lvm xfs 15G /usr
|-/dev/mapper/systemvg-swap_lv /dev/dm-2 /dev/sda3 lvm swap 16G [SWAP]
|-/dev/mapper/systemvg-opt_lv /dev/dm-3 /dev/sda3 lvm xfs 5G /opt
|-/dev/mapper/systemvg-tmp_lv /dev/dm-6 /dev/sda3 lvm xfs 10G /tmp
|-/dev/mapper/systemvg-var_lv /dev/dm-8 /dev/sda3 lvm xfs 10G /var
|-/dev/mapper/systemvg-varlog_lv /dev/dm-10 /dev/sda3 lvm xfs 10G /var/log
|-/dev/mapper/systemvg-varlogaudit_lv /dev/dm-12 /dev/sda3 lvm xfs 10G /var/log/audit
|-/dev/mapper/systemvg-vartmp_lv /dev/dm-15 /dev/sda3 lvm xfs 10G /var/tmp
`-/dev/mapper/systemvg-home_lv /dev/dm-16 /dev/sda3 lvm xfs 15G /home
/dev/sdb /dev/sdb disk 200G
`-/dev/sdb1 /dev/sdb1 /dev/sdb part LVM2_member 200G
|-/dev/mapper/binvg-saphome_lv /dev/dm-9 /dev/sdb1 lvm xfs 2G /home/sap
|-/dev/mapper/binvg-uc4home_lv /dev/dm-11 /dev/sdb1 lvm xfs 2G /home/uc4
|-/dev/mapper/binvg-usrsap_lv /dev/dm-13 /dev/sdb1 lvm xfs 50G /usr/sap
`-/dev/mapper/binvg-sapinst_lv /dev/dm-14 /dev/sdb1 lvm xfs 115G /sapinst
/dev/sdc /dev/sdc disk 100G
`-/dev/sdc1 /dev/sdc1 /dev/sdc part LVM2_member 100G
`-/dev/mapper/hanadatavg-hanadata_lv /dev/dm-4 /dev/sdc1 lvm xfs 100G /hana/data
/dev/sdd /dev/sdd disk 100G
`-/dev/sdd1 /dev/sdd1 /dev/sdd part LVM2_member 100G
`-/dev/mapper/hanasharedvg-hanashared_lv /dev/dm-7 /dev/sdd1 lvm xfs 100G /hana/shared
/dev/sde /dev/sde disk 50G
`-/dev/sde1 /dev/sde1 /dev/sde part LVM2_member 50G
`-/dev/mapper/hanalogvg-hanalog_lv /dev/dm-5 /dev/sde1 lvm xfs 50G /hana/log
What steps will reproduce the bug?¶
No response
Workaround, if any¶
Boot ISO with BIOS instead of EFI.
Additional information¶
No response
thomas-merz commented at 2025-03-14 09:07:¶
Does the UEFI firmware load the ReaR recovery system bootloader?
No
Does the ReaR recovery system bootloader show something?
Nothing at all
Does the ReaR recovery system bootloader load kernel and initrd?
No
Does the kernel start up?
No
Does the ReaR recovery system start up?
No
thomas-merz commented at 2025-03-14 09:10:¶
rear -D mkrescue
🦎 root@sap-testdt8-02.lxdev:~# rear -D mkrescue
Relax-and-Recover 2.7 / 2022-07-13
Running rear mkrescue (PID 263619 date 2025-03-14 10:06:17)
Command line options: /usr/sbin/rear -D mkrescue
Using log file: /var/log/rear/rear-sap-testdt8-02.log
Using build area: /var/tmp/rear.qOl2ebmVsgizNoL
Running 'init' stage ======================
Running workflow mkrescue on the normal/original system
Running 'prep' stage ======================
Found EFI system partition /dev/sda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using '/usr/bin/xorrisofs' to create ISO filesystem images
Using autodetected kernel '/boot/vmlinuz-6.4.0-150600.23.38-default' as kernel in the recovery system
Running 'layout/save' stage ======================
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Disabling excluded components in /var/lib/rear/layout/disklayout.conf
Using sysconfig bootloader 'grub2-efi' for 'rear recover'
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /var/lib/rear/layout/disklayout.conf)
Running 'rescue' stage ======================
Creating recovery system root filesystem skeleton layout
Handling network interface 'eth0'
eth0 is a physical device
Handled network interface 'eth0'
Included current keyboard mapping (via 'dumpkeys -f')
Included default US keyboard mapping /usr/share/kbd/keymaps/i386/qwerty/defkeymap.map.gz
Included other keyboard mappings in /usr/share/kbd/keymaps
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/sles/grubx64.efi' as UEFI bootloader file
Copying logfile /var/log/rear/rear-sap-testdt8-02.log into initramfs as '/tmp/rear-sap-testdt8-02-partial-2025-03-14T10:06:29+01:00.log'
Running 'build' stage ======================
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.4.0-150600.23.38-default (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Skip copying broken symlink '/etc/mtab' target '/proc/280360/mounts' on /proc/ /sys/ /dev/ or /run/
Skip copying broken symlink '/etc/resolv.conf' target '/run/netconfig/resolv.conf' on /proc/ /sys/ /dev/ or /run/
Testing that the recovery system in /var/tmp/rear.qOl2ebmVsgizNoL/rootfs contains a usable system
Testing each binary with 'ldd' and look for 'not found' libraries within the recovery system
Testing that the existing programs in the PROGS array can be found as executable command within the recovery system
Testing that each program in the REQUIRED_PROGS array can be found as executable command within the recovery system
Running 'pack' stage ======================
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (835144846 bytes) in 40 seconds
Running 'output' stage ======================
Configuring GRUB2 kernel /isolinux/kernel
Configuring GRUB2 initrd /isolinux/initrd.cgz
Configuring GRUB2 root device as 'set root=cd0'
GRUB2 modules to load: ext2 fat part_gpt part_msdos
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-sap-testdt8-02.iso (922M)
Copying resulting files to file location
Saving /var/log/rear/rear-sap-testdt8-02.log as rear-sap-testdt8-02.log to file location
Copying result files '/var/lib/rear/output/rear-sap-testdt8-02.iso /var/tmp/rear.qOl2ebmVsgizNoL/tmp/VERSION /var/tmp/rear.qOl2ebmVsgizNoL/tmp/README /var/tmp/rear.qOl2ebmVsgizNoL/tmp/rear-sap-testdt8-02.log' to /rear/iso/sap-testdt8-02.lxdev.ka.de.dm-drogeriemarkt.com at file location
Exiting rear mkrescue (PID 263619) and its descendant processes ...
Running exit tasks
Caution - there is something mounted within the build area
/var/tmp/rear.qOl2ebmVsgizNoL/tmp/isofs/boot/efiboot.img on /var/tmp/rear.qOl2ebmVsgizNoL/tmp/efi_virt type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
You must manually umount that before you may remove the build area
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.qOl2ebmVsgizNoL
🦎 root@sap-testdt8-02.lxdev:~#
thomas-merz commented at 2025-03-14 09:10:¶
isoinfo -l -i *iso shows something that really looks like EFI instead
of another ISO on a BIOS-boot VM that doesn't show EFI at all:
# isoinfo -l -i *iso
Setting input-charset to 'UTF-8' from locale.
Directory listing of /
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 20 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 20 02] ..
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 22 02] BOOT
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 24 02] EFI
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 30 02] ISOLINUX
Directory listing of /BOOT/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 22 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 20 02] ..
-r-xr-xr-x 1 0 0 100663296 Mar 14 2025 [ 45 00] EFIBOOT.IMG;1
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 23 02] GRUB
Directory listing of /EFI/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 24 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 20 02] ..
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 25 02] BOOT
Directory listing of /ISOLINUX/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 30 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 20 02] ..
-r-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 44 00] BOOT.CAT;1
-r-xr-xr-x 1 0 0 19784 Mar 14 2025 [ 56221 00] CHAIN.C32;1
-r-xr-xr-x 1 0 0 278552 Mar 14 2025 [ 56231 00] HDT.C32;1
-r-xr-xr-x 1 0 0 835144846 Mar 14 2025 [ 56368 00] INITRD.CGZ;1
-r-xr-xr-x 1 0 0 24576 Mar 14 2025 [ 49197 00] ISOLINUX.BIN;1
-r-xr-xr-x 1 0 0 2026 Mar 14 2025 [ 464154 00] ISOLINUX.CFG;1
-r-xr-xr-x 1 0 0 14179680 Feb 6 2025 [ 464155 00] KERNEL.;1
-r-xr-xr-x 1 0 0 54388 Mar 14 2025 [ 471079 00] MENU.C32;1
-r-xr-xr-x 1 0 0 276 Mar 14 2025 [ 471106 00] MESSAGE.;1
-r-xr-xr-x 1 0 0 1484872 Mar 14 2025 [ 471107 00] PCI.IDS;1
-r-xr-xr-x 1 0 0 239 Mar 14 2025 [ 471833 00] POWEROFF.COM;1
-r-xr-xr-x 1 0 0 962 Mar 14 2025 [ 471834 00] REAR.HELP;1
-r-xr-xr-x 1 0 0 812 Mar 14 2025 [ 471835 00] REBOOT.C32;1
-r-xr-xr-x 1 0 0 151740 Mar 14 2025 [ 471836 00] VESAMENU.C32;1
Directory listing of /BOOT/GRUB/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 23 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 22 02] ..
-r-xr-xr-x 1 0 0 1178 Mar 14 2025 [ 49209 00] GRUB.CFG;1
Directory listing of /EFI/BOOT/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 25 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 24 02] ..
-r-xr-xr-x 1 0 0 8884224 Mar 14 2025 [ 49210 00] BOOTX64.EFI;1
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 26 02] FONTS
-r-xr-xr-x 1 0 0 1178 Mar 14 2025 [ 54273 00] GRUB.CFG;1
dr-xr-xr-x 1 0 0 6144 Mar 14 2025 [ 27 02] LOCALE
Directory listing of /EFI/BOOT/FONTS/
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 26 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 25 02] ..
-r-xr-xr-x 1 0 0 1484762 Mar 14 2025 [ 53548 00] UNICODE.PF2;1
Directory listing of /EFI/BOOT/LOCALE/
dr-xr-xr-x 1 0 0 6144 Mar 14 2025 [ 27 02] .
dr-xr-xr-x 1 0 0 2048 Mar 14 2025 [ 25 02] ..
-r-xr-xr-x 1 0 0 118891 Mar 14 2025 [ 54274 00] AST.MO;1
-r-xr-xr-x 1 0 0 119530 Mar 14 2025 [ 54333 00] CA.MO;1
-r-xr-xr-x 1 0 0 111312 Mar 14 2025 [ 54392 00] DA.MO;1
-r-xr-xr-x 1 0 0 140494 Mar 14 2025 [ 54447 00] DE.MO;1
-r-xr-xr-x 1 0 0 140501 Mar 14 2025 [ 54516 00] DE_CH.MO;1
-r-xr-xr-x 1 0 0 129109 Mar 14 2025 [ 54585 00] EN_QUOT.MO;1
-r-xr-xr-x 1 0 0 42309 Mar 14 2025 [ 54649 00] EO.MO;1
-r-xr-xr-x 1 0 0 121864 Mar 14 2025 [ 54670 00] ES.MO;1
-r-xr-xr-x 1 0 0 122523 Mar 14 2025 [ 54730 00] FI.MO;1
-r-xr-xr-x 1 0 0 147167 Mar 14 2025 [ 54790 00] FR.MO;1
-r-xr-xr-x 1 0 0 96338 Mar 14 2025 [ 54862 00] GL.MO;1
-r-xr-xr-x 1 0 0 83723 Mar 14 2025 [ 54910 00] HE.MO;1
-r-xr-xr-x 1 0 0 120574 Mar 14 2025 [ 54951 00] HR.MO;1
-r-xr-xr-x 1 0 0 127448 Mar 14 2025 [ 55010 00] HU.MO;1
-r-xr-xr-x 1 0 0 27734 Mar 14 2025 [ 55073 00] ID.MO;1
-r-xr-xr-x 1 0 0 116556 Mar 14 2025 [ 55087 00] IT.MO;1
-r-xr-xr-x 1 0 0 43864 Mar 14 2025 [ 55144 00] JA.MO;1
-r-xr-xr-x 1 0 0 145765 Mar 14 2025 [ 55166 00] KO.MO;1
-r-xr-xr-x 1 0 0 94480 Mar 14 2025 [ 55238 00] LT.MO;1
-r-xr-xr-x 1 0 0 118683 Mar 14 2025 [ 55285 00] NB.MO;1
-r-xr-xr-x 1 0 0 118723 Mar 14 2025 [ 55343 00] NL.MO;1
-r-xr-xr-x 1 0 0 57713 Mar 14 2025 [ 55401 00] PA.MO;1
-r-xr-xr-x 1 0 0 139470 Mar 14 2025 [ 55430 00] PL.MO;1
-r-xr-xr-x 1 0 0 122075 Mar 14 2025 [ 55499 00] PT.MO;1
-r-xr-xr-x 1 0 0 81011 Mar 14 2025 [ 55559 00] PT_BR.MO;1
-r-xr-xr-x 1 0 0 147701 Mar 14 2025 [ 55599 00] RO.MO;1
-r-xr-xr-x 1 0 0 158221 Mar 14 2025 [ 55672 00] RU.MO;1
-r-xr-xr-x 1 0 0 87662 Mar 14 2025 [ 55750 00] SL.MO;1
-r-xr-xr-x 1 0 0 177796 Mar 14 2025 [ 55793 00] SR.MO;1
-r-xr-xr-x 1 0 0 118670 Mar 14 2025 [ 55880 00] SV.MO;1
-r-xr-xr-x 1 0 0 77340 Mar 14 2025 [ 55938 00] TR.MO;1
-r-xr-xr-x 1 0 0 186344 Mar 14 2025 [ 55976 00] UK.MO;1
-r-xr-xr-x 1 0 0 151654 Mar 14 2025 [ 56067 00] VI.MO;1
-r-xr-xr-x 1 0 0 129531 Mar 14 2025 [ 56142 00] ZH_CN.MO;1
-r-xr-xr-x 1 0 0 29133 Mar 14 2025 [ 56206 00] ZH_TW.MO;1
jsmeix commented at 2025-03-14 13:33:¶
On my KVM/QEMU VM
with OVMF "TianoCore" UEFI firmware without Secure Boot
(i.e. Secure Boot disabled in the UEFI firmware menu)
with SLES15-SP6 and its default btrfs structure
with ReaR 2.7:
# git clone https://github.com/rear/rear.git
# mv rear rear.github.rear-2.7
# cd rear.github.rear-2.7
# git checkout -f -b rear-2.7 rear-2.7
Switched to a new branch 'rear-2.7'
# cat etc/rear/local.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://192.168.178.66/nfs
REQUIRED_PROGS+=( snapper chattr lsattr )
COPY_AS_IS+=( /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
#USE_SERIAL_CONSOLE="no" # enable to avoid kernel console issues
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
# usr/sbin/rear -D mkrescue
Relax-and-Recover 2.7 / Git
...
Running 'prep' stage ======================
Found EFI system partition /dev/vda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using '/usr/bin/xorrisofs' to create ISO filesystem images
.
.
.
Running 'rescue' stage ======================
...
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/sles/grubx64.efi' as UEFI bootloader file
.
.
.
Running 'output' stage ======================
Configuring GRUB2 kernel /isolinux/kernel
Configuring GRUB2 initrd /isolinux/initrd.cgz
Configuring GRUB2 root device as 'set root=cd0'
GRUB2 modules to load: btrfs fat part_gpt part_msdos
Making ISO image
Wrote ISO image: /root/rear.github.rear-2.7/var/lib/rear/output/rear-localhost.iso (198M)
...
Exiting rear mkrescue (PID 29535) and its descendant processes ...
# ls -lh var/lib/rear/output/
total 198M
-rw------- 1 root root 198M Mar 14 13:31 rear-localhost.iso
# mkdir /tmp/iso
# mount -t iso9660 -o loop var/lib/rear/output/rear-localhost.iso /tmp/iso
mount: /tmp/iso: WARNING: source write-protected, mounted read-only.
# find /tmp/iso -ls | tr -s ' ' | cut -d ' ' -f4,8,12
drwx------ 2048 /tmp/iso
drwx------ 2048 /tmp/iso/boot
-rw------- 100663296 /tmp/iso/boot/efiboot.img
drwxr-xr-x 2048 /tmp/iso/boot/grub
-rw------- 1248 /tmp/iso/boot/grub/grub.cfg
drwx------ 2048 /tmp/iso/EFI
drwxr-xr-x 2048 /tmp/iso/EFI/BOOT
-rwx------ 9068544 /tmp/iso/EFI/BOOT/BOOTX64.efi
drwx------ 2048 /tmp/iso/EFI/BOOT/fonts
-rw------- 1484762 /tmp/iso/EFI/BOOT/fonts/unicode.pf2
-rw------- 1248 /tmp/iso/EFI/BOOT/grub.cfg
drwx------ 6144 /tmp/iso/EFI/BOOT/locale
-rw------- 118891 /tmp/iso/EFI/BOOT/locale/ast.mo
...
-rw------- 29133 /tmp/iso/EFI/BOOT/locale/zh_TW.mo
drwx------ 2048 /tmp/iso/isolinux
-r-------- 2048 /tmp/iso/isolinux/boot.cat
-rw------- 19784 /tmp/iso/isolinux/chain.c32
-rw------- 278552 /tmp/iso/isolinux/hdt.c32
-rw------- 75375223 /tmp/iso/isolinux/initrd.cgz
-rw------- 24576 /tmp/iso/isolinux/isolinux.bin
-rw------- 2130 /tmp/iso/isolinux/isolinux.cfg
-rw-r--r-- 14191584 /tmp/iso/isolinux/kernel
-rw------- 54388 /tmp/iso/isolinux/menu.c32
-rw------- 266 /tmp/iso/isolinux/message
-rw------- 1431735 /tmp/iso/isolinux/pci.ids
-rw------- 239 /tmp/iso/isolinux/poweroff.com
-rw------- 962 /tmp/iso/isolinux/rear.help
-rw------- 812 /tmp/iso/isolinux/reboot.c32
-rw------- 151740 /tmp/iso/isolinux/vesamenu.c32
So as far as I see at first glance
all looks same for me as it is on your system.
When I boot another KVM/QEMU VM
with OVMF "TianoCore" UEFI firmware without Secure Boot
(i.e. Secure Boot disabled in the UEFI firmware menu)
from that ISO
the UEFI firmware loads the ReaR recovery system bootloader
and the ReaR recovery system bootloader shows its boot menue
with in particular those two choices
Relax-and-Recover (BIOS or UEFI without Secure Boot)
Relax-and-Recover (UEFI and Secure Boot)
where I select the first entry and then
the ReaR recovery system bootloader loads kernel and initrd
but there I get now (I see this for the first time):
This seems to be only a meaningless warning
because it continues automatically after about 10 seconds.
But then I get a black screen for about 30 seconds
i.e. I do not see the usual kernel startup messages
which is the known issue with kernel console setting
see
https://github.com/rear/rear/issues/2843
and
https://github.com/rear/rear/pull/2961
which is fixed since ReaR 2.8
which one can avoid in ReaR 2.7 in etc/rear/local.conf with
USE_SERIAL_CONSOLE="no"
cf. my etc/rear/local.conf in
https://github.com/rear/rear/issues/3084#issuecomment-1835773844
But this is also no really severe problem because
after those about 30 seconds of black screen
the usual initial ReaR recovery system screen shows up
where I can log in as 'root' as usual.
By the way:
As always with UEFI things do not "just work".
I had to tinker with the Secure Boot settings
in the OVMF "TianoCore" UEFI firmware setup menu
because by default Secure Boot is enabled
in the OVMF "TianoCore" UEFI firmware
and then (when the EFI binary in the ISO image
which is to be booted by the UEFI firmware
is not sufficiently prepared for Secure Boot)
the UEFI firmware - as always - does of course
not show any helpful info but "just fails"
with some UEFI firmware internal gibberish
where non-UEFI experts cannot make sense of.
So it is crucial that Secure Boot is disabled
in the UEFI firmware when the ISO image is made
for UEFI booting without Secure Boot.
jsmeix commented at 2025-03-14 13:58:¶
@thomas-merz
another blind shot into the dark because you use
BACKUP=CDM
and now I see that you get
Created initrd.cgz with gzip default compression (835144846 bytes) in 40 seconds
...
Wrote ISO image: /var/lib/rear/output/rear-sap-testdt8-02.iso (922M)
I vaguely remember certain ISO size limits
and/or initrd size limits also on x86_64
(on POWER rather small initrd size limits are known)
where booting "just somehow fails" with
a too big ISO and/or a too big initrd.
So to verify whether or not your ISO size and/or initrd size
could be the cause of your booting failure, try as a test
if booting the ReaR recovery system works for you with
BACKUP=NETFS
cf. what ISO size I have
Wrote ISO image: /root/rear.github.rear-2.7/var/lib/rear/output/rear-localhost.iso (198M)
...
-rw------- 75375223 /tmp/iso/isolinux/initrd.cgz
i.e. I have only about 72MiB compressed initrd size
in contrast to you with about 796MiB compressed initrd size.
I guess the 'BACKUP=CDM' stuff that gets included
in the ReaR recovery system is rather (too?) big.
jsmeix commented at 2025-03-14 14:12:¶
FYI
Regarding the known initrd size limits on POWER
see
https://github.com/rear/rear/issues/3189
and
https://github.com/rear/rear/pull/3233
Regarding rather obscure initrd size limits on x86
see
https://github.com/rear/rear/issues/3324
therein in particular
https://github.com/rear/rear/issues/3324#issuecomment-2421673731
where some 462M size limit for the initrd on x86_64 is mentioned
and see
https://github.com/rear/rear/issues/2681#issuecomment-928937450
where GRUB had failed with a "rather large initrd, around 300-500MB".
jsmeix commented at 2025-03-14 14:27:¶
Generic things which make the ReaR recovery system big
(so ReaR's initrd which contains the ReaR recovery system gets big)
are firmware files and kernel modules.
On VMs usually no firmware files are needed and
only the loaded kernel modules are needed
in the ReaR recovery system so
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
help generically to reduce the size of the ReaR recovery system.
If you need firmware files for your particular VM
you can include only what you actually need,
see the FIRMWARE_FILES description in default.conf
but also see
https://github.com/rear/rear/issues/2681#issuecomment-930879162
why it is not easy to know or to find out what
firmware files get used on one's own hardware.
In general see also
https://github.com/rear/rear/issues/3270
jsmeix commented at 2025-03-14 14:52:¶
In its current state this issue is not a bug because
a bug is when the code does not do what it is meant to do
see
https://github.com/rear/rear/labels
In its current state this issue is a support question
i.e. how to setup ReaR with BACKUP=CDM and OUTPUT=ISO
to make the ReaR recovery system ISO image
bootable with UEFI firmware.
Later - as things go on - this issue may evolve
into whatever appropriate other type(s).
thomas-merz commented at 2025-03-17 10:51:¶
BACKUP=CDM
…
I guess the 'BACKUP=CDM' stuff that gets included in the ReaR recovery system is rather (too?) big.
That sounds… "weird" because I can boot exactly this "too big ISO" with
BIOS-boot - but not with EFI-boot. And I really could imagine that EFI
breaks some limits that BIOS had?!
But I tested it nevertheless and I got a slightly smaller ISO image:
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (735192996 bytes) in 31 seconds
GRUB2 modules to load: ext2 fat part_gpt part_msdos
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-sap-testdt8-02.iso (827M)
This ISO also can't be booted with EFI.
thomas-merz commented at 2025-03-17 10:57:¶
In its current state this issue is not a bug because a bug is when the code does not do what it is meant to do see https://github.com/rear/rear/labels
In its current state this issue is a support question i.e. how to setup ReaR with BACKUP=CDM and OUTPUT=ISO to make the ReaR recovery system ISO image bootable with UEFI firmware.
I don't think so that "the code does do what it is meant to do". Because
it should create a bootable ISO also with EFI when it already
automatically identifies a system as "EFI" and using
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1) without
being set anything like this in any conf in /etc/rear. @roseswe what do
you think? Are we more popely as the pope? 🤷♂
jsmeix commented at 2025-03-17 16:44:¶
The above mentioned
https://github.com/rear/rear/issues/2681
is further described in
https://github.com/rear/rear/issues/3186
i.e. certain GRUB versions seem to have issues
with loading bigger initrds on UEFI which apparently
also depends on UEFI firmware manufacturer and version.
@thomas-merz
because I am not at all a sufficient booting expert
to properly analyze and debug such issues, I recommend
that you also (i.e. in addition to this issue here)
open an official SUSE internal support case so that
the booting experts at SUSE could have a closer look.
If you have a SUSE product/extension
where SUSE officially supports ReaR,
I recommend that you file in any case
an official support request at SUSE
via your official support contact at SUSE
to get official support from SUSE in addition
to the voluntary support here at ReaR upstream
(i.e. German "viel hilft viel" / English "more is better").
If you do that please provide an URL to this issue
in your SUSE support request.
thomas-merz commented at 2025-03-18 09:10:¶
I asked via SUSE ticket 01573307 if they can officially help here with the right experts for this with a link to this GH issue.
thomas-merz commented at 2025-03-25 11:59:¶
rear-2.8-3.x86_64.rpm also doesn't produce a bootable ISO at all.
rear-2.9-2.x86_64.rpm produces a bootable but "not working at all"
ISO:
Loading kernel /isolinux/kernel ...
error: ../../grub-core/loader/i386/efi/linux.c:248:invalid magic number.
Loading initial randisk /isolinux/initrd.cgz ...
error: ../../grub-core/loader/i386/efi/linux.c:168:you need to load the kernel first.
SUSE support / developers are on it.
[Export of Github issue for rear/rear.]