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...
