#2039 PR merged: Fix for commit f9e53a33¶

Labels: fixed / solved / done, critical / security / legal

gozora opened issue at 2019-02-11 19:55:¶

Pull Request Details:¶

• Type: Bug Fix

• Impact: High

• Reference to related issue (URL): https://github.com/rear/rear/commit/f9e53a331c226fa305145866492bb978a1e66a2a

• How was this pull request tested?
  Created and UEFI booted ReaR recovery system on RHEL 7.6, SLES12 SP2 and Fedora29

• Brief description of the changes in this pull request:
  It looks like https://github.com/rear/rear/commit/f9e53a331c226fa305145866492bb978a1e66a2a introduced a regression for Linux distributions that ships Grub2 EFI modules (grub2-efi-x64-modules) only in /usr/lib/grub*/x86_64-efi but does not copy them to /boot when installed (observed on RHEL7.6 and Fedora29 so far, but there might be more ...).
  Missing modules in /boot combined with code from https://github.com/rear/rear/commit/f9e53a331c226fa305145866492bb978a1e66a2a

test "$( find /boot -type f -name "$grub_module.mod" 2>/dev/null )" && grub_modules="$grub_modules $grub_module"

are causing that resulting boot loader BOOTX64.efi is silently missing all the important modules because grub-mkimage is executed without any module as follows:

++ grub2-mkimage -v -O x86_64-efi -c /tmp/rear.XqviherDVAkuSdo/tmp/mnt/EFI/BOOT/embedded_grub.cfg -o /tmp/rear.XqviherDVAkuSdo/tmp/mnt/EFI/BOOT/BOOTX64.efi -p /EFI/BOOT

where command should look something like:

++ grub2-mkimage -v -O x86_64-efi -c /tmp/rear.0al2HwSlvQ5XsiC/tmp/mnt/EFI/BOOT/embedded_grub.cfg -o /tmp/rear.0al2HwSlvQ5XsiC/tmp/mnt/EFI/BOOT/BOOTX64.efi -p /EFI/BOOT part_gpt part_msdos fat ext2 normal chain boot configfile linux linuxefi multiboot jfs iso9660 usb usbms usb_keyboard video udf ntfs all_video gzio efi_gop reboot search test echo btrfs

ReaR rescue system is created, but after boot attempt following message appear:

This was originally proposed by @jsmeix in https://github.com/rear/rear/pull/2001#issuecomment-446536035 but somehow fall into oblivion.

V.

jsmeix commented at 2019-02-12 08:55:¶

As far as I see this issue is basically what I had meant with
https://github.com/rear/rear/pull/2001#issuecomment-446536035
and
https://github.com/rear/rear/pull/2001#issuecomment-446659273
but it was not finally answered there.

For the log:
On my SLES12-like openSUSE Leap 15.0 UEFI system
I get for rear -D mkrescue in the log

++ grub2-mkimage -v -O x86_64-efi -c /tmp/rear.h4XFbmUFzskCRHg/tmp/mnt/EFI/BOOT/embedded_grub.cfg -o /tmp/rear.h4XFbmUFzskCRHg/tmp/mnt/EFI/BOOT/BOOTX64.efi -p /EFI/BOOT part_gpt part_msdos fat ext2 normal chain boot configfile linux linuxefi multiboot jfs iso9660 usb usbms usb_keyboard video udf ntfs all_video gzio efi_gop reboot search test echo btrfs

jsmeix commented at 2019-02-12 08:59:¶

@gozora
apparently I did not see much far so "early" in the morning when I wrote
https://github.com/rear/rear/pull/2039#issuecomment-462673120
because you had already mentioned exactly that.

gozora commented at 2019-02-12 09:22:¶

@jsmeix

For the log:
On my SLES12-like openSUSE Leap 15.0 UEFI system
I get for rear -D mkrescue in the log

Yes, there is "something" in SLE (12 & 15), I did not found so far that, that copies some modules from /usr/lib/grub2/x86_64-efi to /boot/grub2/x86_64-efi. RHEL on the other hand, does not have such behavior.

V.

---

[Export of Github issue for rear/rear.]