#3024 Issue `closed`: GRUB2 on ISO with UEFI has 'root' hardcoded set to 'cd0' so booting from 'cd1' fails (regression from #2662)¶

Labels: bug, fixed / solved / done

prontok opened issue at 2023-07-04 19:45:¶

Hello,
I am getting a problem at the GRUB loading stage

Relax-and-Recover 2.7 / 2022-07-13
OS: Ubuntu Server 22.04
LUKS1 (LUKS1/2 there is not much difference)
UEFI

OUTPUT=ISO
OUTPUT_URL=null
BACKUP=NETFS
BACKUP_URL="iso:///etc/rear/"
ISO_DIR="/etc/rear"
REAR_INITRD_COMPRESSION=fast
USE_DHCLIENT=yes
ISO_FILE_SIZE_LIMIT=0
USER_INPUT_TIMEOUT=40
LUKS_CRYPTSETUP_OPTIONS+=" --align-payload 32768"

P.S. If I use Bios Legacy with LUKS, then there are no such errors.

Please help.

jsmeix commented at 2023-07-05 12:02:¶

@prontok
see
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
therein in particular

* Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT")
...
* Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files)

At least a "rear -D mkrescue" or a "rear -D mkbackup"
debug log file is needed plus the output of

# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT

on your original system.

FYI, see
https://github.com/rear/rear/blob/master/usr/share/rear/output/ISO/Linux-i386/820_create_iso_image.sh#L7

prontok commented at 2023-07-06 07:34:¶

Hello,
I collected the debug log and lsblk command
rear-ubuntu-server.log
lsblk.zip

jsmeix commented at 2023-07-06 08:43:¶

@prontok
I think LUKS has nothing to do with this issue here
because the ReaR recovery system does not use LUKS.
The ReaR recovery system is unencrypted in ReaR's initrd.

What fails here - as far as I see - is that the
ReaR recovery system bootloader cannot load
the ReaR recovery system kernel '/isolinux/kernel'
because of 'unknown filesystem'.

In your log file
https://github.com/rear/rear/files/11965596/rear-ubuntu-server.log
I don't see something obviously wrong,
in particular I don't see something obviously wrong
while the /usr/share/rear/output/*.sh scripts are run,
no real errors as far as I see - I think the many
grub-mkstandalone info messages

grub-mkstandalone: info: cannot open '/usr/share/locale/.../LC_MESSAGES/grub.mo': No such file or directory.

can be ignored because I think '/usr/share/locale/.../LC_MESSAGES/grub.mo'
are only optional localization messages.

For an easier overview here excerpts from that log file:

# egrep -o "Print '.*| source /usr/share/rear/output/.*" rear-ubuntu-server.log | uniq

Print 'Running workflow mkbackup on the normal/original system'
Print 'Using backup archive '\''/var/tmp/rear.qMnV9Tz7ac3UMgh/tmp/isofs/etc/rear//backup.tar.gz'\'''
Print 'Found EFI system partition /dev/sda1 on /boot/efi type vfat'
Print 'Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)'
Print 'Using '\''/usr/bin/mkisofs'\'' to create ISO filesystem images'
Print 'Using autodetected kernel '\''/boot/vmlinuz-5.15.0-76-generic'\'' as kernel in the recovery system'
Print 'Creating disk layout'
Print 'Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf'
Print 'Disabling excluded components in /var/lib/rear/layout/disklayout.conf'
Print 'Using guessed bootloader '\''EFI'\'' for '\''rear recover'\'' (found in first bytes on /dev/sda)'
Print 'Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct'
Print 'Created disk layout (check the results in /var/lib/rear/layout/disklayout.conf)'
Print 'Creating recovery system root filesystem skeleton layout'
Print 'Handling network interface '\''enp0s3'\'''
Print 'enp0s3 is a physical device'
Print 'Handled network interface '\''enp0s3'\'''
Print 'Included current keyboard mapping (via '\''dumpkeys -f'\'')'
Print 'No default US keyboard mapping included (no KEYMAPS_DEFAULT_DIRECTORY specified)'
Print 'No support for different keyboard layouts (neither KEYMAPS_DEFAULT_DIRECTORY nor KEYMAPS_DIRECTORIES specified)'
Print 'Trying to find what to use as UEFI bootloader...'
Print 'Trying to find a '\''well known file'\'' to be used as UEFI bootloader...'
Print 'Using '\''/boot/efi/EFI/ubuntu/grubx64.efi'\'' as UEFI bootloader file'
Print 'Copying logfile /var/log/rear/rear-ubuntu-server.log into initramfs as '\''/tmp/rear-ubuntu-server-partial-2023-07-06T07:04:49+00:00.log'\'''
Print 'Copying files and directories'
Print 'Copying binaries and libraries'
Print 'Copying all kernel modules in /lib/modules/5.15.0-76-generic (MODULES contains '\''all_modules'\'')'
Print 'Copying all files in /lib*/firmware/'
Print 'Skip copying broken symlink '\''/etc/resolv.conf'\'' target '\''/run/systemd/resolve/stub-resolv.conf'\'' on /proc/ /sys/ /dev/ or /run/'
Print 'Skip copying broken symlink '\''/etc/mtab'\'' target '\''/proc/63937/mounts'\'' on /proc/ /sys/ /dev/ or /run/'
Print 'Testing that the recovery system in /var/tmp/rear.qMnV9Tz7ac3UMgh/rootfs contains a usable system'
Print 'Testing each binary with '\''ldd'\'' and look for '\''not found'\'' libraries within the recovery system'
Print 'Testing that the existing programs in the PROGS array can be found as executable command within the recovery system'
Print 'Testing that each program in the REQUIRED_PROGS array can be found as executable command within the recovery system'
Print 'Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip fast compression'
Print 'Created initrd.cgz with gzip fast compression (711074778 bytes) in 42 seconds'
Print 'Making backup (using backup method NETFS)'
Print 'Creating tar archive '\''/var/tmp/rear.qMnV9Tz7ac3UMgh/tmp/isofs/etc/rear//backup.tar.gz'\'''
Print 'Archived 1241 MiB in 183 seconds [avg 6948 KiB/sec]'
 source /usr/share/rear/output/default/010_set_umask.sh
 source /usr/share/rear/output/default/100_mount_output_path.sh
 source /usr/share/rear/output/default/150_save_copy_of_prefix_dir.sh
 source /usr/share/rear/output/default/200_make_boot_dir.sh
 source /usr/share/rear/output/default/200_make_prefix_dir.sh
 source /usr/share/rear/output/default/250_create_lock.sh
 source /usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
Print 'Configuring GRUB2 kernel /isolinux/kernel'
Print 'Configuring GRUB2 initrd /isolinux/initrd.cgz'
Print 'Configuring GRUB2 root device as '\''set root=cd0'\'''
Print 'GRUB2 modules to load: ext2 fat part_gpt part_msdos'
Print 'Did not find /boot/grub/locale files (minor issue for UEFI ISO boot)'
 source /usr/share/rear/output/ISO/Linux-i386/260_EFISTUB_populate.sh
 source /usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh
 source /usr/share/rear/output/default/400_copy_disk_struct_files.sh
 source /usr/share/rear/output/ISO/Linux-i386/700_create_efibootimg.sh
 source /usr/share/rear/output/ISO/Linux-i386/800_create_isofs.sh
 source /usr/share/rear/output/ISO/Linux-i386/810_prepare_multiple_iso.sh
 source /usr/share/rear/output/ISO/Linux-i386/820_create_iso_image.sh
Print 'Making ISO image'
Print 'Wrote ISO image: /etc/rear/rear-ubuntu-server.iso (2.1G)'
 source /usr/share/rear/output/ISO/Linux-i386/830_create_iso_image_EFISTUB.sh
 source /usr/share/rear/output/ISO/Linux-i386/850_check_for_errors.sh
 source /usr/share/rear/output/default/940_grub2_rescue.sh
 source /usr/share/rear/output/default/940_grub_rescue.sh
 source /usr/share/rear/output/default/950_copy_result_files.sh
 source /usr/share/rear/output/default/950_email_result_files.sh
 source /usr/share/rear/output/default/970_remove_lock.sh
 source /usr/share/rear/output/default/980_umount_output_dir.sh
Print 'Exiting rear mkbackup (PID 53813) and its descendant processes ...'
Print 'Running exit tasks'
Print 'To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.qMnV9Tz7ac3UMgh'

In particular
"Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)"
and
"Using /boot/efi/EFI/ubuntu/grubx64.efi as UEFI bootloader file"
are properly autodetected.

I am not at all a sufficient expert in the ReaR recovery system
bootloader area or the ISO generation area to be able to imagine
what may go wrong in this specific case here.

In particular regarding Ubuntu:
I am not a Ubuntu user (and I won't find time
to test ReaR with Ubuntu) and we at ReaR upstream
do not have an active maintainer who uses Ubuntu
(it seems Canonical is not interested to support ReaR)
so ReaR support for Ubuntu can be only as good as voluntary
contributors who use Ubuntu contribute - which is much appreciated!

jsmeix commented at 2023-07-06 13:19:¶

Only an offhanded guess (I am not at all a GRUB expert):
When I read

Print 'Configuring GRUB2 kernel /isolinux/kernel'
Print 'Configuring GRUB2 initrd /isolinux/initrd.cgz'
Print 'Configuring GRUB2 root device as '\''set root=cd0'\'''
Print 'GRUB2 modules to load: ext2 fat part_gpt part_msdos'

I am wondering on what filesystem /isolinux/kernel
and /isolinux/initrd.cgz are?
Perhaps for GRUB2 that filesystem is
an 'unknown filesystem' (neither ext2 nor fat)?

prontok commented at 2023-07-07 06:53:¶

Good afternoon,
I think i found the problem while recovery.
Ubuntu has been using ext4 file system on /boot, but R&R load "ext2 fat part_gpt part_msdos" modules at the time of creation an iso image. R&R doesn't use ext4 module.
I tried to use this environment:
GRUB2_MODULES_UEFI_LOAD=( ext4 fat part_gpt part_msdos ), but it didn't work out.

prontok commented at 2023-07-07 06:59:¶

By the way, R&R successfully collected the image from Debian (LUKS2, UEFI) because Debian use "ext2 /boot"

jsmeix commented at 2023-07-07 08:37:¶

By "googling" for 'grub ext2 module'
I found this 10 years old info
https://unix.stackexchange.com/questions/59332/how-is-grub-able-to-read-its-config-file-on-ext3-fileystem
which tells (excerpts)

The grub ext2 module also understands ext3 and ext4

Grub (0.9x) supports ext2 and ext3 but not ext4
(unless backward-incompatible features are turned-off).
Whereas, Grub2 (since 1.97) supports ext2, ext3 and ext4
with the same module [ext2.mod] ...

Accordingly on my openSUSE Leap system I don't have
a GRUB module named 'ext4' - I only have

/usr/share/grub2/i386-pc/ext2.mod
/usr/share/grub2/x86_64-efi/ext2.mod

and your
https://github.com/rear/rear/files/11965596/rear-ubuntu-server.log
contains

grub-mkstandalone: info: copying `/usr/lib/grub/x86_64-efi/ext2.mod' -> `/var/tmp/grub.5prE3u/boot/grub/x86_64-efi/ext2.mod'.
...
grub-mkstandalone: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(memdisk)/boot/grub' --output '/var/tmp/rear.qMnV9Tz7ac3UMg
h/tmp/mnt/EFI/BOOT/BOOTX64.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   --memdisk '/var/tmp/grub.70v7P0' 'ext2' 'fat' 'pa
rt_gpt' 'part_msdos' 'memdisk' 'tar'
...
grub-mkstandalone: info: reading /usr/lib/grub/x86_64-efi/ext2.mod.

so things look good regarding ext2/3/4 support in GRUB2
but actually things aren't good.

My blind guess is that in this case the filesystem
(or whatever kind of "filesystem" is used in an ISO)
where /isolinux/kernel and /isolinux/initrd.cgz are
is not ext2 ext3 ext4 or fat but "something different"?

E.g. on my my openSUSE Leap system I have

/usr/share/grub2/i386-pc/iso9660.mod
/usr/share/grub2/x86_64-efi/iso9660.mod

Perhaps the GRUB module 'iso9660' is needed on ISO?
Cf.
https://github.com/rear/rear/blob/master/usr/share/rear/output/ISO/Linux-ppc64/310_create_grub2.sh#L39
and
https://github.com/rear/rear/blob/master/usr/share/rear/output/ISO/Linux-ppc64le/300_create_grub2.sh#L34

But if the GRUB module 'iso9660' is needed on ISO
why does it then work with BIOS?

Probably the reason why it fails with UEFI is "something else".

pcahyna commented at 2023-07-10 13:47:¶

"GRUB2 modules to load: ext2 fat part_gpt part_msdos" means that these modules are loaded by default, but other modules should be available as well embedded in the GRUB image, and should be autoloaded as needed, so I wonder what the problem is (see https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/lib/uefi-functions.sh#L123). Can you please execute the set command and the lsmod on the GRUB command line and show us the result? To find whether the module is available, please execute ls (memdisk)/boot/grub/x86_64-efi/ and also report the result. You can also try insmod iso9660 manually and if it works, try to boot again.

prontok commented at 2023-07-11 06:52:¶

Hello,
Our EFI boot partition has VFAT filesystem type.
I have a guess - Ubuntu or Linux Mint kernels have embedded support of fat/vfat file systems and subsequently don't use fat/vfat modules for mounting such partitions (it can be detected by lsmod command - no modules with name fat/vfat will be shown in Ubuntu)
And I think that rear try to use vfat module for addressing to efi partition but can't do it due to missing that module.
It just a guess and I can be mistaken after all.

jsmeix commented at 2023-07-11 09:17:¶

@prontok

my current understanding is according to those excerpts from
https://github.com/rear/rear/issues/3024#issuecomment-1623235464

What fails here - as far as I see - is that the
ReaR recovery system bootloader cannot load
the ReaR recovery system kernel '/isolinux/kernel'
because of 'unknown filesystem'.
...
Print 'Configuring GRUB2 kernel /isolinux/kernel'
Print 'Configuring GRUB2 initrd /isolinux/initrd.cgz'

GRUB2 is used as bootloader in the recovery system and
GRUB2 cannot load the Linux kernel '/isolinux/kernel'
because of 'unknown filesystem'.

So talking about "modules" above means GRUB2 modules
but not Linux kernel modules because there is
no Linux kernel running at that point in time.

pcahyna commented at 2023-07-11 09:24:¶

@prontok

Our EFI boot partition has VFAT filesystem type.

In addition to what @jsmeix wrote, aren't you booting from a ReaR rescue DVD? How is the EFI boot partition (on a hard disk) related to the inability to read the kernel from the DVD? Or does the DVD also contain an EFI boot partition?

pcahyna commented at 2023-07-11 09:26:¶

@prontok have you tried anything of what I suggested in https://github.com/rear/rear/issues/3024#issuecomment-1629006262 ?

prontok commented at 2023-07-11 11:37:¶

I prepared the screenshots
grub2.tar.gz

prontok commented at 2023-07-11 11:59:¶

In Debian system:
grub> ls
(proc) (memdisk) (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0)
grub>

In Ubuntu system:
grub> ls
(proc) (memdisk) (hd0) (cd0) (cd1)
grub>

pcahyna commented at 2023-07-11 12:08:¶

@prontok thanks, I believe we can make progress thanks to this.

Everything looks good, except that your root is set to cd0 and you have two DVD drives apparently and your rescue DVD is cd1, not cd0 (note that this is not the case in Debian, thats IMO why Debian works). Try set root=cd1 and then ls /isolinux and if it succeeds, return to the menu (ESC) and boot again.

prontok commented at 2023-07-11 13:49:¶

@pcahyna I applied set root=cd1 and after that the system has been normal restored.
The original system has one cdrom (cd1) device and it is not used by default in ISO image during restore, but uses some cd0 device.
I don't understand why there are two cdrom devices during restore process.

jsmeix commented at 2023-07-11 14:06:¶

I found some reason (perhaps not the root cause)
why it fails:

In output/ISO/Linux-i386/250_populate_efibootimg.sh
there is hardcoded grub2_set_root=cd0 in

    grub2_set_root=cd0
    create_grub2_cfg /isolinux/kernel /isolinux/$REAR_INITRD_FILENAME > $efi_boot_tmp_dir/grub.cfg

The create_grub2_cfg function
in lib/bootloader-functions.sh works appropriately
to respect when grub2_set_root is set which means
the config variable GRUB2_SEARCH_ROOT_COMMAND is ignored
(which is against "final power to the user")

function create_grub2_cfg {
...
    local grub2_search_root_command="$3"
    if ! test "$grub2_search_root_command" ; then
        test "$grub2_set_root" && grub2_search_root_command="set root=$grub2_set_root"
    fi
    if ! test "$grub2_search_root_command" ; then
        test "$GRUB2_SEARCH_ROOT_COMMAND" && grub2_search_root_command="$GRUB2_SEARCH_ROOT_COMMAND"
    fi
    test "$grub2_search_root_command" || grub2_search_root_command="search --no-floppy --set=root --file /boot/efiboot.img"
    DebugPrint "Configuring GRUB2 root device as '$grub2_search_root_command'"

This appears in
https://github.com/rear/rear/files/11965596/rear-ubuntu-server.log
as

+ source /usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
...
++ grub2_set_root=cd0
++ create_grub2_cfg /isolinux/kernel /isolinux/initrd.cgz
...
++ local grub2_search_root_command=
++ test ''
++ test cd0
++ grub2_search_root_command='set root=cd0'
++ test 'set root=cd0'
++ test 'set root=cd0'
++ DebugPrint 'Configuring GRUB2 root device as '\''set root=cd0'\'''
++ Debug 'Configuring GRUB2 root device as '\''set root=cd0'\'''
++ test 1
++ Log 'Configuring GRUB2 root device as '\''set root=cd0'\'''

jsmeix commented at 2023-07-11 14:18:¶

@prontok
your
https://github.com/rear/rear/files/11965618/lsblk.zip
shows only one device '/dev/sr0' of lsblk TYPE 'rom'.

So during "rear mkrescue/mkbackup" it would be impossible
to autodetect that later during ReaR recovery system boot
there are two devices of lsblk TYPE 'rom' and that the
ReaR recovery system bootloader boots from the second one.

As far as I see I think your case is a very special case
where the only way to boot the ReaR recovery system
is to manually set in GRUB2 the right 'root' for GRUB2.

jsmeix commented at 2023-07-11 14:21:¶

@prontok
are your systems (the original and the replacement)
both real hardware or are they virtual machines?

prontok commented at 2023-07-11 14:33:¶

Both the original and replacement systems are running on VirtualBox virtual machines.

jsmeix commented at 2023-07-11 14:36:¶

Then I guess that the second CDROM device was added by accident
instead of assigning the ReaR recovery system ISO image
to the already existing first CDROM device
or something like that.

I am not a VirtualBox user.
I only use QEMU/KVM virtual machines.

jsmeix commented at 2023-07-11 14:43:¶

Because GRUB2_SEARCH_ROOT_COMMAND is empty in default.conf
I can improve the code of the create_grub2_cfg function
to provide final power to the user and always respect
GRUB2_SEARCH_ROOT_COMMAND when the user has set it.

prontok commented at 2023-07-11 14:54:¶

Our main goal is to create "gold" image using R&R from VirtualBox virtual machine and then distribute it on hardware PC computer park. But at the current stage we are testing it just on VirtualBox and allready faced to problems.

jsmeix commented at 2023-07-11 15:23:¶

Perhaps a GRUB2 expert could make a GRUB2_SEARCH_ROOT_COMMAND
which works reasonably well in practice "out there"
to let GRUB2 automatically find its right 'root'
regardless from what device GRUB2 is booting?

In default.conf

# GRUB2_SEARCH_ROOT_COMMAND="search --no-floppy --set=root --file /EFI/BOOT/BOOTX64.efi"

looks interesting.
Perhaps we could place a special file at "the right place"
in the ReaR recovery system so that GRUB2 could automatically
find the right 'root' to boot the ReaR recovery system?

pcahyna commented at 2023-07-11 15:23:¶

That's the point, it should be working already. not sure what's wrong.

pcahyna commented at 2023-07-11 15:35:¶

Ooops. In create_grub2_cfg‎
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/lib/bootloader-functions.sh#L549
but this function is never called with 3 arguments AFAICT.
GRUB2_SEARCH_ROOT_COMMAND is set here:
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh#L99
and here:
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/output/USB/Linux-i386/300_create_grub.sh#L83
but this is valid only for USB output and I can't find any corresponding code for ISO.
This explains what I wrote in #2453 "Sometimes the search command in GRUB2 used in UEFI ISO does not find the root device." - no search command gets executed in the first place. Seems strange that there was no search command executed at all at the time when I made that PR. Maybe the code has changed since then?

pcahyna commented at 2023-07-11 15:42:¶

Now, the line
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/lib/bootloader-functions.sh#L556
would set grub2_search_root_command to a sensible default. But since grub2_set_root is set already here:
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh#L73
the sensible default is never reached, as grub2_search_root_command is set before:
https://github.com/rear/rear/blob/23977a19101b6e6eaeebbe8ce013332ddf9ea517/usr/share/rear/lib/bootloader-functions.sh#L551

pcahyna commented at 2023-07-11 15:44:¶

@prontok could I ask you to boot the DVD again and when it drops to the GRUB prompt, try this command

search --no-floppy --set=root --file /boot/efiboot.img

and then examine the value of root again? This command should set it to cd1.

pcahyna commented at 2023-07-11 16:07:¶

It seems that the problem was introduced here:
https://github.com/rear/rear/pull/2662/files#diff-0f08921736e9ccdea612e80a0fa8c57bee8e07b1a70cb25da4700b3017ff00cdL624
previously, search --no-floppy --file /boot/efiboot.img --set was introduced unconditionally after set root=$grub2_set_root https://github.com/rear/rear/pull/2662/files#diff-0f08921736e9ccdea612e80a0fa8c57bee8e07b1a70cb25da4700b3017ff00cdL609

But now, it is executed only if $grub2_set_root is empty (which it is not).

pcahyna commented at 2023-07-11 16:15:¶

I see I was asked for review on #2662 and never did it. My bad.

prontok commented at 2023-07-11 19:15:¶

@pcahyna It is worked, I entered the command search --no-floppy --set=root --file /boot/efiboot.img in Grub commandline and root value has become root=cd1 and after that recovery is being carried out correctly

jsmeix commented at 2023-07-12 05:33:¶

@pcahyna
thank you so much for finding the root cause!

jsmeix commented at 2023-07-13 11:51:¶

https://github.com/rear/rear/pull/3025
should fix this issue,
see in particular boot/grub/grub.cfg inside the ISO
in my tests
https://github.com/rear/rear/pull/3025#issuecomment-1634049686
and (with two CDROM drivers)
https://github.com/rear/rear/pull/3025#issuecomment-1634118226

prontok commented at 2023-07-18 14:26:¶

Hello,
Draw your attention! This problem "GRUB2 on ISO with UEFI has 'root' hardcoded set to 'cd0' so booting from 'cd1' fails" only occurs when using LUKS on the original operating system.
Without the use of LUKS, this problem does not exist !

jsmeix commented at 2023-07-19 14:10:¶

@prontok
can you provide evidence why it depends on LUKS?
Cf. my above
https://github.com/rear/rear/issues/3024#issuecomment-1623235464

jsmeix commented at 2023-07-21 12:57:¶

With https://github.com/rear/rear/pull/3025 merged
this regression should be fixed.

[Export of Github issue for rear/rear.]

#3024 Issue closed: GRUB2 on ISO with UEFI has 'root' hardcoded set to 'cd0' so booting from 'cd1' fails (regression from #2662)¶