#2388 Issue `closed`: "rear mkrescue" does not error out when required GRUB2 modules are missing¶

Labels: bug, fixed / solved / done

shaunsJM opened issue at 2020-05-06 14:27:¶

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.5-git.0.36106f4.unknown.changed / 2020-01-30
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
OS_VENDOR=SUSE_LINUX
OS_VERSION=15.1
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

HOSTNAME="$( uname -n | cut -d. -f1 )"
OUTPUT=ISO
BACKUP=NETFS
USING_UEFI_BOOTLOADER=1
BACKUP_OPTIONS="nolock,credentials=/etc/rear/cifs-rear"
BACKUP_URL=cifs://den-vmutility/Linux-Rear-Migrations
NETFS_KEEP_OLD_BACKUP_COPY=yes
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default /etc/rear/cifs-rear )
BACKUP_PROG_INCLUDE=( /var/cache /var/lib/mailman /var/tmp /var/lib/pgsql /usr/local /opt /var/lib/libvirt/images /boot/grub2/i386-pc /var/opt /srv /boot/grub2/x86_64-efi /var/lib/mariadb /var/spool /var/lib/mysql /tmp /home /var/log /var/lib/named /var/lib/machines )
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' )
ONLY_INCLUDE_VG=( "system" )
AUTOEXCLUDE_MULTIPATH=n
ISO_MKISOFS_BIN=/usr/bin/ebiso
EXCLUDE_VG=( "vgapp" "vgarchlog" "vgu00-04" "vgu05-09" )
EXCLUDE_MOUNTPOINTS=('/app' '/archlog' '/u00' '/u01' '/u02' '/u03' '/u04' '/u05' '/u06' '/u07' '/u08' '/u09')
CLONE_ALL_USERS_GROUPS="true"

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
Product Name: ThinkSystem SR650
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86.
This is a SUSE SLES 15 SP1 server running BTRFS on a Lenovo ThinkSystem SR650
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI with GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local disk
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                 disk             278.5G
|-/dev/sda1                 /dev/sda1 /dev/sda       part vfat          500M /boot/efi
`-/dev/sda2                 /dev/sda2 /dev/sda       part LVM2_member   278G
  |-/dev/mapper/system-root /dev/dm-0 /dev/sda2      lvm  btrfs          40G /
  |-/dev/mapper/system-swap /dev/dm-1 /dev/sda2      lvm  swap           15G [SWAP]
  `-/dev/mapper/system-home /dev/dm-2 /dev/sda2      lvm  ext4           10G /home

Description of the issue (ideally so that others can reproduce it):
Rear backup works, but during restore this is shown:

error: file '/boot/grub/x86_64-efi/video_bochs.mod' not found
error: file '/boot/grub/x86_64-efi/video_cirrus.mod' not found

Workaround, if any:
I haven't found one
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

Relax-and-Recover 2.5-git.0.36106f4.unknown.changed / 2020-01-30
Running rear mkbackup (PID 17236)
Using log file: /var/log/rear/rear-slc-lxnbu1p.log
Using backup archive '/tmp/rear.go8q7sa6eQq3gwR/outputfs/slc-lxnbu1p/backup.tar.gz'
Found EFI system partition /dev/sda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-4.12.14-197.34-default' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/mapper/system-root (default subvolume path contains '@/.snapshots/')
Added  /dev/mapper/system-root to BTRFS_SUBVOLUME_SLES_SETUP in /tmp/rear.go8q7sa6eQq3gwR/rootfs/etc/rear/rescue.conf
Excluding Volume Group vgapp.
Excluding Volume Group vgarchlog.
Excluding Volume Group vgu00-04.
Excluding Volume Group vgu05-09.
Using sysconfig bootloader 'grub2-efi'
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct ...
Creating recovery system root filesystem skeleton layout
Handling network interface 'eth3'
eth3 is a physical device
Handled network interface 'eth3'
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-slc-lxnbu1p.log into initramfs as '/tmp/rear-slc-lxnbu1p-partial-2020-05-05T15:11:00-06:00.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/4.12.14-197.34-default (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Skip copying broken symlink '/etc/mtab' target '/proc/29568/mounts' on /proc/ /sys/ /dev/ or /run/
Testing that the recovery system in /tmp/rear.go8q7sa6eQq3gwR/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (316919467 bytes) in 37 seconds
GRUB2 modules to load: btrfs fat lvm part_gpt
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-slc-lxnbu1p.iso (355M)
Copying resulting files to cifs location
Saving /var/log/rear/rear-slc-lxnbu1p.log as rear-slc-lxnbu1p.log to cifs location
Copying result files '/var/lib/rear/output/rear-slc-lxnbu1p.iso /tmp/rear.go8q7sa6eQq3gwR/tmp/VERSION /tmp/rear.go8q7sa6eQq3gwR/tmp/README /tmp/rear.go8q7sa6eQq3gwR/tmp/rear-slc-lxnbu1p.log' to /tmp/rear.go8q7sa6eQq3gwR/outputfs/slc-lxnbu1p at cifs location
Making backup (using backup method NETFS)
Creating tar archive '/tmp/rear.go8q7sa6eQq3gwR/outputfs/slc-lxnbu1p/backup.tar.gz'
Archived 1314 MiB [avg 7046 KiB/sec] OK
WARNING: tar ended with return code 1 and below output:
  ---snip---
  tar: /var/lib/named: Warning: Cannot stat: No such file or directory
  tar: /var/lib/machines: Warning: Cannot stat: No such file or directory
  tar: /sys: file changed as we read it
  ----------
This means that files have been modified during the archiving
process. As a result the backup may not be completely consistent
or may not be a perfect copy of the system. Relax-and-Recover
will continue, however it is highly advisable to verify the
backup in order to be sure to safely recover this system.

Archived 1314 MiB in 192 seconds [avg 7010 KiB/sec]
Exiting rear mkbackup (PID 17236) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.go8q7sa6eQq3gwR

rear-failure2

jsmeix commented at 2020-05-07 07:33:¶

In our current ReaR GitHub master code we have support for
GRUB2_MODULES and GRUB2_MODULES_LOAD
see the description in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2798

If you do not have GRUB2_MODULES and GRUB2_MODULES_LOAD
in your locally installed usr/share/rear/conf/default.conf
try out if it works with our current ReaR GitHub master code, see
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

Regarding how GRUB2_MODULES and GRUB2_MODULES_LOAD
actually work see the function build_bootx86_efi
in usr/share/rear/lib/uefi-functions.sh
The function build_bootx86_efi is called in the scripts
usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
when you have OUTPUT=ISO or alternatively in
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh
if you had OUTPUT=USB and/or additionally in
usr/share/rear/output/default/940_grub2_rescue.sh
if you dared to use GRUB_RESCUE="yes" (read default.conf about that).

pcahyna commented at 2020-05-07 08:19:¶

I think the problem is in https://github.com/rear/rear/blob/2037ebb20699bc5d4a1c87b0a81b8cbfc6c56454/usr/share/rear/lib/bootloader-functions.sh#L509 where some GRUB2 modules are loaded unconditionally from the generated configuration file (i.e. GRUB2_MODULES and GRUB2_MODULES_LOAD most likely will not help). I recently removed some hardcoded module stuff from the GRUB2 code, but I have not touched that part. Yet another reason for less hardcoded values.... Isn't the insmod all_video enough?
https://github.com/rear/rear/blob/2037ebb20699bc5d4a1c87b0a81b8cbfc6c56454/usr/share/rear/lib/bootloader-functions.sh#L511

pcahyna commented at 2020-05-07 08:43:¶

@shaunsJM are those modules absent also on the installed system, or only in the rescue system? Maybe they got removed from recent GRUB2 packages on SLES.

pcahyna commented at 2020-05-07 08:55:¶

If the modules are actually present on the installed system, and just not installed to the rescue image, then adding them to GRUB2_MODULES could actually help, but this is weird, since the default is to include all modules. If you remove

insmod video_bochs
insmod video_cirrus

from usr/share/rear/lib/bootloader-functions.sh and recreate the rescue image, will it work fine, or suffer from some other problem?

shaunsJM commented at 2020-05-07 09:44:¶

@pcahyna you are correct, the video_bochs and video_cirrus are not on the installed system.
From the running system trying to insmod these files:

insmod video_bochs
insmod: ERROR: could not load module video_bochs: No such file or directory
insmod video_cirrus
insmod: ERROR: could not load module video_cirrus: No such file or directory

I removed the insmod lines from the usr/share/rear/lib/bootloader-functions.sh and this fixed the recovery issue.
You may be correct when you say "Maybe they got removed from recent GRUB2 packages on SLES."

Thanks for the help!

pcahyna commented at 2020-05-07 09:53:¶

@pcahyna you are correct, the video_bochs and video_cirrus are not on the installed system.
From the running system trying to insmod these files:
insmod video_bochs
insmod: ERROR: could not load module video_bochs: No such file or directory
insmod video_cirrus
insmod: ERROR: could not load module video_cirrus: No such file or directory

That's a misunderstanding - those are GRUB modules, not kernel modules, but insmod in the running system works on kernel modules. So it could not have found them in any case.

I think the GRUB modules are located under /usr/lib/grub/x86_64-efi or under /boot. Could you please look there? @jsmeix where would one find them on SLES?

I removed the insmod lines from the usr/share/rear/lib/bootloader-functions.sh and this fixed the recovery issue.

Thanks for testing!

I think this issue should stay open, this looks like an actual problem, it should work out of the box.

jsmeix commented at 2020-05-07 10:06:¶

@shaunsJM
regarding your https://github.com/rear/rear/issues/2388#issuecomment-625147460
"video_bochs and video_cirrus are not on the installed [SLES15-SP1] system":

Om my current homeoffice laptop openSUSE Leap 15.1 system
that should be same for the basic system packages
as SLES15-SP1 is (except exceptions! ;-)
I do have those GRUB2 modules installed

# rpm -ql grub2-i386-pc | grep video_

/usr/share/grub2/i386-pc/video_bochs.mod
/usr/share/grub2/i386-pc/video_bochs.module
/usr/share/grub2/i386-pc/video_cirrus.mod
/usr/share/grub2/i386-pc/video_cirrus.module
/usr/share/grub2/i386-pc/video_colors.mod
/usr/share/grub2/i386-pc/video_colors.module
/usr/share/grub2/i386-pc/video_fb.mod
/usr/share/grub2/i386-pc/video_fb.module

via the RPM package grub2-i386-pc that is required by GRUB2

# rpm -e --test grub2-i386-pc

error: Failed dependencies:
grub2-i386-pc = 2.02-lp151.21.15.1 is needed
by (installed) grub2-2.02-lp151.21.15.1.x86_64

so I would assume that also on SLES15-SP1
you should have grub2-i386-pc installed and that
should provide those GRUB2 modules.

shaunsJM commented at 2020-05-07 10:10:¶

@pcahyna Thanks for the clarification about the GRUB vs. kernel modules.
@jsmeix From checking several of my other servers, I find the video_bochs and video_cirrus under /boot/grub2/i386-pc/ for those servers not running UEFI. Is your Leap 15.1 system running UEFI or Legacy?

pcahyna commented at 2020-05-07 10:12:¶

@jsmeix but this is not i386-pc, this is x86_64-efi. Do those modules also exist in the appropriate subpackage for EFI?

pcahyna commented at 2020-05-07 10:13:¶

(ReaR does not use GRUB at all for i386-pc right? It uses SYSLINUX/ISOLINUX.)

jsmeix commented at 2020-05-07 10:16:¶

Ah!
My current homeoffice laptop openSUSE Leap 15.1 system boots via legacy boot.
Currently I do not have a UEFI booting system at home.
But I can check what files we provide in our GRUB2 RPMs...

pcahyna commented at 2020-05-07 10:16:¶

@shaunsJM

From checking several of my other servers, I find the video_bochs and video_cirrus under /boot/grub2/i386-pc/ for those servers not running UEFI.

And have you found them in the appropriate directory for efi GRUB on server that is running UEFI?

jsmeix commented at 2020-05-07 10:24:¶

@pcahyna
regarding your https://github.com/rear/rear/issues/2388#issuecomment-625105141

I am not at all a sufficient bootloader expert to know whether or not
it is needed or makes sense or whatever to enforce loading
this or that GRUB2 modules.

In general we must much better care about possible errors in ReaR
and error out early with a reasonable error message for the user
during "rear mkbackup/mkrescue" when things cannot work later
than to blindly proceed and let the user find out later when it is too late
that things fail when booting the recovery system or during "rear recover".

So for each GRUB2 module that will be enforced loaded
we must first and foremost at least check during "rear mkrescue"
that the GRUB2 module is actually there and made available for
the GRUB2 bootloader on the ReaR recovery system.

shaunsJM commented at 2020-05-07 10:26:¶

@shaunsJM

From checking several of my other servers, I find the video_bochs and video_cirrus under /boot/grub2/i386-pc/ for those servers not running UEFI.

And have you found them in the appropriate directory for efi GRUB on server that is running UEFI?

on my UEFI system the only "video" modules are these:

all_video.mod
fixvideo.mod
video.lst
video.mod
video_colors.mod
video_fb.mod
videoinfo.mod
videotest.mod
videotest_checksum.mod

pcahyna commented at 2020-05-07 10:35:¶

So for each GRUB2 module that will be enforced loaded
we must first and foremost at least check during "rear mkrescue"
that the GRUB2 module is actually there and made available for
the GRUB2 bootloader on the ReaR recovery system.

Laudable but ambitious goal - @jhlavac do you know if there is a clean way to do this, please?

In the short term, the fix could be to reduce the number of modules that we insmod in the generated configuration file and try to restrict ourselves to those that are in some sense "public" or "stable", if Grub has such concepts. In this particular case, I suspect that loading all_video should be enough and Grub knows better what modules it actually loads (when I checked, on a system that has them, video_bochs and video_cirrus is among them, so loading them explicitly seems superfluous).

jsmeix commented at 2020-05-07 10:36:¶

@pcahyna
thank you so much for your analysis what the root cause is
and your explanations that correct my misunderstanding!

FWIW: I would have never ever guessed that UEFI vs. BIOS could
make a difference what video related GRUB2 modules are there
so I din't pay attention on the booting method.

pcahyna commented at 2020-05-07 10:47:¶

FWIW: I would have never ever guessed that UEFI vs. BIOS could
make a difference what video related GRUB2 modules are there
so I din't pay attention on the booting method.

They definitely used to be available for both, I checked RHEL 8 on UEFI and they are there. @jhlavac do you please know why they are disappearing?

jsmeix commented at 2020-05-07 10:52:¶

Our usual sufficiently clean way in ReaR would be
to have the list of enforced loaded GRUB2 modules
in a user config variable which we have already
as GRUB2_MODULES_LOAD.

So instead of hardcoded values in the scripts we have to set the
default list of enforced loaded GRUB2 modules in default.conf
so the user knows about it and can adapt it if needed.

We have way too many hardcoded values in our scripts
that lead to a "works magically right in most cases" behaviour
which leads to weird errors that our users do not understand which
further leads to issue reports here that are hard to debug for us
because at least one of us (I myself) does not understand it ;-)

Imagine what @shaunsJM may have reported to us
if "rear mkbackup/mkrescue" would have failed for him
with a helpful error message like

Required GRUB2 modules 'video_bochs video_cirrus' not found in '/boot/grub/x86_64-efi/'

jsmeix commented at 2020-05-07 14:07:¶

What GRUB2 video modules SUSE provides for SLES15-SP1
for i386-pc

# rpm -qlp grub2-i386-pc-2.02-24.12.noarch.rpm | grep video

/usr/share/grub2/i386-pc/all_video.mod
/usr/share/grub2/i386-pc/all_video.module
/usr/share/grub2/i386-pc/video.lst
/usr/share/grub2/i386-pc/video.mod
/usr/share/grub2/i386-pc/video.module
/usr/share/grub2/i386-pc/video_bochs.mod
/usr/share/grub2/i386-pc/video_bochs.module
/usr/share/grub2/i386-pc/video_cirrus.mod
/usr/share/grub2/i386-pc/video_cirrus.module
/usr/share/grub2/i386-pc/video_colors.mod
/usr/share/grub2/i386-pc/video_colors.module
/usr/share/grub2/i386-pc/video_fb.mod
/usr/share/grub2/i386-pc/video_fb.module
/usr/share/grub2/i386-pc/videoinfo.mod
/usr/share/grub2/i386-pc/videoinfo.module
/usr/share/grub2/i386-pc/videotest.mod
/usr/share/grub2/i386-pc/videotest.module
/usr/share/grub2/i386-pc/videotest_checksum.mod
/usr/share/grub2/i386-pc/videotest_checksum.module

versus for x86_64-efi

# rpm -qlp grub2-x86_64-efi-2.02-24.12.noarch.rpm | grep video
/usr/share/grub2/x86_64-efi/all_video.mod
/usr/share/grub2/x86_64-efi/all_video.module
/usr/share/grub2/x86_64-efi/fixvideo.mod
/usr/share/grub2/x86_64-efi/fixvideo.module
/usr/share/grub2/x86_64-efi/video.lst
/usr/share/grub2/x86_64-efi/video.mod
/usr/share/grub2/x86_64-efi/video.module
/usr/share/grub2/x86_64-efi/video_colors.mod
/usr/share/grub2/x86_64-efi/video_colors.module
/usr/share/grub2/x86_64-efi/video_fb.mod
/usr/share/grub2/x86_64-efi/video_fb.module
/usr/share/grub2/x86_64-efi/videoinfo.mod
/usr/share/grub2/x86_64-efi/videoinfo.module
/usr/share/grub2/x86_64-efi/videotest.mod
/usr/share/grub2/x86_64-efi/videotest.module
/usr/share/grub2/x86_64-efi/videotest_checksum.mod
/usr/share/grub2/x86_64-efi/videotest_checksum.module

jsmeix commented at 2020-05-07 14:25:¶

What GRUB2 modules that are enforced loaded
by the create_grub2_cfg function
in usr/share/rear/lib/bootloader-functions.sh

# grep '^insmod ' usr/share/rear/lib/bootloader-functions.sh

insmod efi_gop
insmod efi_uga
insmod video_bochs
insmod video_cirrus
insmod all_video
insmod gzio
insmod part_gpt
insmod ext2

do exist or are missing in the SLE15-SP1 RPM
for i386-pc

found all_video in grub2-i386-pc-2.02-24.12.noarch.rpm
found ext2 in grub2-i386-pc-2.02-24.12.noarch.rpm
found gzio in grub2-i386-pc-2.02-24.12.noarch.rpm
found part_gpt in grub2-i386-pc-2.02-24.12.noarch.rpm
found video_bochs in grub2-i386-pc-2.02-24.12.noarch.rpm
found video_cirrus in grub2-i386-pc-2.02-24.12.noarch.rpm
missing efi_gop in grub2-i386-pc-2.02-24.12.noarch.rpm
missing efi_uga in grub2-i386-pc-2.02-24.12.noarch.rpm

versus for x86_64-efi

found all_video in grub2-x86_64-efi-2.02-24.12.noarch.rpm
found efi_gop in grub2-x86_64-efi-2.02-24.12.noarch.rpm
found efi_uga in grub2-x86_64-efi-2.02-24.12.noarch.rpm
found ext2 in grub2-x86_64-efi-2.02-24.12.noarch.rpm
found gzio in grub2-x86_64-efi-2.02-24.12.noarch.rpm
found part_gpt in grub2-x86_64-efi-2.02-24.12.noarch.rpm
missing video_bochs in grub2-x86_64-efi-2.02-24.12.noarch.rpm
missing video_cirrus in grub2-x86_64-efi-2.02-24.12.noarch.rpm

The

missing efi_gop in grub2-i386-pc-2.02-24.12.noarch.rpm
missing efi_uga in grub2-i386-pc-2.02-24.12.noarch.rpm

are false positives because GRUB2 is used as bootloader
for the ReaR recovery system only in case of UEFI.

So the only actually missing GRUB2 modules are

missing video_bochs in grub2-x86_64-efi-2.02-24.12.noarch.rpm
missing video_cirrus in grub2-x86_64-efi-2.02-24.12.noarch.rpm

which should therefore not be enforced loaded
by the create_grub2_cfg function
in usr/share/rear/lib/bootloader-functions.sh

jsmeix commented at 2020-05-07 14:43:¶

I submitted https://github.com/rear/rear/pull/2390
that should fix this particular issue.

It does not implement a generic enhancement to make the code
that does "GRUB2 install as bootloader for the recovery system"
behave more fail-safe.

jsmeix commented at 2020-05-08 10:02:¶

What GRUB2 video modules SUSE provides for SLES12-SP5
for i386-pc in grub2-i386-pc-2.02-12.15.1.x86_64.rpm

/usr/lib/grub2/i386-pc/all_video.mod
/usr/lib/grub2/i386-pc/all_video.module
/usr/lib/grub2/i386-pc/video.lst
/usr/lib/grub2/i386-pc/video.mod
/usr/lib/grub2/i386-pc/video.module
/usr/lib/grub2/i386-pc/video_bochs.mod
/usr/lib/grub2/i386-pc/video_bochs.module
/usr/lib/grub2/i386-pc/video_cirrus.mod
/usr/lib/grub2/i386-pc/video_cirrus.module
/usr/lib/grub2/i386-pc/video_colors.mod
/usr/lib/grub2/i386-pc/video_colors.module
/usr/lib/grub2/i386-pc/video_fb.mod
/usr/lib/grub2/i386-pc/video_fb.module
/usr/lib/grub2/i386-pc/videoinfo.mod
/usr/lib/grub2/i386-pc/videoinfo.module
/usr/lib/grub2/i386-pc/videotest.mod
/usr/lib/grub2/i386-pc/videotest.module
/usr/lib/grub2/i386-pc/videotest_checksum.mod
/usr/lib/grub2/i386-pc/videotest_checksum.module

versus for x86_64-efi in grub2-x86_64-efi-2.02-12.15.1.x86_64.rpm

/usr/lib/grub2/x86_64-efi/all_video.mod
/usr/lib/grub2/x86_64-efi/all_video.module
/usr/lib/grub2/x86_64-efi/fixvideo.mod
/usr/lib/grub2/x86_64-efi/fixvideo.module
/usr/lib/grub2/x86_64-efi/video.lst
/usr/lib/grub2/x86_64-efi/video.mod
/usr/lib/grub2/x86_64-efi/video.module
/usr/lib/grub2/x86_64-efi/video_colors.mod
/usr/lib/grub2/x86_64-efi/video_colors.module
/usr/lib/grub2/x86_64-efi/video_fb.mod
/usr/lib/grub2/x86_64-efi/video_fb.module
/usr/lib/grub2/x86_64-efi/videoinfo.mod
/usr/lib/grub2/x86_64-efi/videoinfo.module
/usr/lib/grub2/x86_64-efi/videotest.mod
/usr/lib/grub2/x86_64-efi/videotest.module
/usr/lib/grub2/x86_64-efi/videotest_checksum.mod
/usr/lib/grub2/x86_64-efi/videotest_checksum.module

so there is an all_video GRUB2 module also for SLES12-SP5.

jsmeix commented at 2020-05-08 10:06:¶

What GRUB2 video modules SUSE provides for SLES11-SP4
for x86_64-efi in grub2-x86_64-efi-2.00-0.50.34.x86_64.rpm

/usr/lib/grub2/x86_64-efi/all_video.mod
/usr/lib/grub2/x86_64-efi/all_video.module
/usr/lib/grub2/x86_64-efi/fixvideo.mod
/usr/lib/grub2/x86_64-efi/fixvideo.module
/usr/lib/grub2/x86_64-efi/video.lst
/usr/lib/grub2/x86_64-efi/video.mod
/usr/lib/grub2/x86_64-efi/video.module
/usr/lib/grub2/x86_64-efi/video_bochs.mod
/usr/lib/grub2/x86_64-efi/video_bochs.module
/usr/lib/grub2/x86_64-efi/video_cirrus.mod
/usr/lib/grub2/x86_64-efi/video_cirrus.module
/usr/lib/grub2/x86_64-efi/video_fb.mod
/usr/lib/grub2/x86_64-efi/video_fb.module
/usr/lib/grub2/x86_64-efi/videoinfo.mod
/usr/lib/grub2/x86_64-efi/videoinfo.module
/usr/lib/grub2/x86_64-efi/videotest.mod
/usr/lib/grub2/x86_64-efi/videotest.module

so there is an all_video GRUB2 module also for SLES11-SP4.

As fas as I see for SLES11-SP4 there is no grub2-i386-pc RPM
with GRUB2 modules.

jsmeix commented at 2020-05-08 10:31:¶

What GRUB2 efi_ modules SUSE provides in grub2-x86_64-efi-*.rpm
for SLES15-SP1

/usr/share/grub2/x86_64-efi/efi_gop.mod
/usr/share/grub2/x86_64-efi/efi_gop.module
/usr/share/grub2/x86_64-efi/efi_netfs.mod
/usr/share/grub2/x86_64-efi/efi_netfs.module
/usr/share/grub2/x86_64-efi/efi_uga.mod
/usr/share/grub2/x86_64-efi/efi_uga.module

for SLES12-SP5

/usr/lib/grub2/x86_64-efi/efi_gop.mod
/usr/lib/grub2/x86_64-efi/efi_gop.module
/usr/lib/grub2/x86_64-efi/efi_netfs.mod
/usr/lib/grub2/x86_64-efi/efi_netfs.module
/usr/lib/grub2/x86_64-efi/efi_uga.mod
/usr/lib/grub2/x86_64-efi/efi_uga.module

for SLES11-SP4

/usr/lib/grub2/x86_64-efi/efi_gop.mod
/usr/lib/grub2/x86_64-efi/efi_gop.module
/usr/lib/grub2/x86_64-efi/efi_uga.mod
/usr/lib/grub2/x86_64-efi/efi_uga.module

so efi_gop and efi_uga are always there.

jsmeix commented at 2020-05-08 10:34:¶

Summary:
For SLES15-SP1, SLES12-SP5, and SLES11-SP4
the GRUB2 modules all_video efi_gop and efi_uga
are always there.

jsmeix commented at 2020-05-08 12:42:¶

For the cleanup and enhancement part I made this new issue
https://github.com/rear/rear/issues/2391

jsmeix commented at 2020-05-08 14:21:¶

With https://github.com/rear/rear/pull/2390 merged
this particular issue should be sufficiently avoided for now
so that this issue can be closed.

Futher cleanup and enhancements should happen via
https://github.com/rear/rear/issues/2391

jsmeix commented at 2020-05-13 14:39:¶

For documentation regarding what GRUB2 moddep.lst
contains for all_video: in SUSE GRUB2 RPMS, cf.
https://github.com/rear/rear/pull/2390#discussion_r422352690

For SLE11-SP4 in grub2-x86_64-efi-2.00-0.50.34.x86_64.rpm
/usr/lib/grub2/x86_64-efi/moddep.lst contains

all_video: efi_gop efi_uga video_bochs video_cirrus

For SLE12-SP5 in grub2-x86_64-efi-2.02-12.15.1.x86_64.rpm
/usr/lib/grub2/x86_64-efi/moddep.lst contains

all_video: efi_gop efi_uga

For SLE15-SP1 grub2-x86_64-efi-2.02-24.12.noarch.rpm
/usr/share/grub2/x86_64-efi/moddep.lst contains

all_video: efi_gop efi_uga

So for SLES15-SP1, SLES12-SP5, and SLES11-SP4
loading the GRUB2 module all_video is sufficient, cf.
https://github.com/rear/rear/pull/2390#discussion_r421802979

jsmeix commented at 2020-05-13 14:47:¶

Also the GRUB2 modules efi_gop and efi_uga are no longer loaded via
https://github.com/rear/rear/commit/2470edf534bc836a3f13d8c48e3007a24bb63bf4

[Export of Github issue for rear/rear.]

#2388 Issue closed: "rear mkrescue" does not error out when required GRUB2 modules are missing¶