Re: GRUB2 entries missing / misconfigured / etc?

[ylluminate]

Thank you - very good catch Andrei regarding both SeaBIOS indicating MBR and 
the version numbers..

A few things:

$ grub2-mkconfig --version
grub2-mkconfig (GRUB) 2.03
$ /usr/sbin/grub2-install --version
/usr/sbin/grub2-install (GRUB) 2.03

$ rpm -qa | grep grub
grub2-tools-extra-2.02-123.el8.alma.x86_64
grub2-common-2.02-123.el8.alma.noarch
grub2-pc-2.02-123.el8.alma.x86_64
grub2-tools-efi-2.02-123.el8.alma.x86_64
grub2-tools-minimal-2.02-123.el8.alma.x86_64
grub2-tools-2.02-123.el8.alma.x86_64
grub2-pc-modules-2.02-123.el8.alma.noarch

$ dnf repoquery --installed -l grub2-tools # or rpm -ql grub2-tools
...
/usr/bin/grub2-mkimage
...
/usr/sbin/grub2-install
...

And yes, 2.04 is showing on boot...

When I attempt to install grub2 again on /dev/sda:
$ grub2-install /dev/sda
Installing for i386-pc platform.
grub2-install: warning: File system `ext2' doesn't support embedding.
grub2-install: warning: Embedding is not possible. GRUB can only be installed 
in this setup by using blocklists. However, blocklists are UNRELIABLE and their 
use is discouraged..
grub2-install: error: will not proceed with blocklists.

And a bit of looking:

$ fdisk -l /dev/sda
Disk /dev/sda: 95.5 GiB, 102546538496 bytes, 200286208 sectors
...
$ gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
 MBR: not present
 BSD: not present
 APM: not present
 GPT: not present

Creating new GPT entries.
Disk /dev/sda: 200286208 sectors, 95.5 GiB
Model: QEMU HARDDISK
...
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 95.5G 0 disk /
sdb 8:16 0 260M 0 disk [SWAP]

So seeing this and your remarks made me take a step back and reconsider the 
situation. It turns out that I found some remarks that say Linode injects its 
own version of GRUB2 when the Linode is booted, so it doesn’t need to be 
installed in the MBR... Thus this would explain why GRUB 2.04 is showing up 
instead of 2.02... or 2.03 as per above... strangeness all around I suppose.

However I did read that to update GRUB2 for Linode, you simply can execute 
`grub2-mkconfig -o /boot/grub2/grub.cfg`, but doing this really didn't change 
anything and generates precisely the same config that I've already had and have 
been trying to get to work.

Following all of this I noticed a comment by someone who said they had to 
change change GRUB_ENABLE_BLSCFG=false and then were able to rebuild the config 
file and boot properly, so I tried:
$ nano /etc/default/grub
# set GRUB_ENABLE_BLSCFG=false
$ grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
Found initrd image: /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-4f09fa5fdd3642fa85221d7c11370603
Found initrd image: 
/boot/initramfs-0-rescue-4f09fa5fdd3642fa85221d7c11370603.img
done

Lo and behold, as you notice this time it actually found the kernel images and 
created entries! Apparently the real root of the issue all along was perhaps 
having BLS active...?

I do still see the "error: variable `prefix' isn't set." message, but it booted 
on through it... even with GRUB version mismatches...