Install Failure at "grub2_common" scriptlet

Please forgive me for posting a question here for what is probably an unsupported system but

1) I'm figuring the Installer method should be nearly identical

2) LQN has some of the best minds on it of any message board I've ever subscribed to

3) Rocky Linux claims it is "Redhat Compatible"

and finally,

4) Since the fail is with simply completing the grub2 bootloader install, it seems rather generic at least to Grub users if not Redhat installers.

I have had success with one trial install on a spinner but after so many fails I chose that drive just because it was somewhat convenient to repartition but hadn't the space I'd prefer for a "real" install let alone the bandwidth I'd prefer with an EVO Pro NVME install.

I literally wiped a working distro all on Drive 0, - /, /boot, and /boot/efi (properly checked and flagged) with the single exception of keeping swap on the spinner.

Anyway I apologize if this is not an appropriate place for such a fundamental question so I will certainly understand if this post is ignored or deleted, but I hope you don't.

All I want is to understand why this fails repeatedly no matter what I try (there is no guidance as to why grub2-common should fail) and by using rEFInd I can even after the fail, manage to boot to an emergency prompt that complains that switch root failed. I have been a SysV guy too long to know much of what to do to fix such a problem especially when no log I've found explains what exactly failed to complete so I can at least attempt to provide what it needs to load actual root. That alone might be a good start.

Thank you in advance for any assistance anyone might render.

Is context BIOS, or EFI? If GPT with BIOS, was a BIOS/Grub partition provided?

Switchroot failure is a common result of initrd failing to include required module for reading required filesystem(s). It seems to be more common with NVME presence, as if the installer was incompetent to include modules for both SATA and NVME in the initrd at the same time, or with the presence of both, not including modules for both VFAT and whatever the / filesystem is. Absent LVM support could also do this. AFAIK, this is all required before time for systemd or sysvinit to start.

I don't have any Rockys installed, and I stopped installing Grub in Fedora when it dropped Grub legacy. I boot MBR PCs using openSUSE 13.1's Grub Legacy regardless of distro. On UEFI, I use only Tumbleweed's grub-efi, for which no companion gru*common package exists. I find it hard to surmise why an installer would be blocked from installing Grub unless some checkbox set or not was incompatible with the type or location for Grub installation.

# inxi -S
System:
  Host: ab250 Kernel: 6.6.11-1-default arch: x86_64 bits: 64
  Console: pty pts/1 Distro: openSUSE Tumbleweed 20240304
# rpm -qa | grep grub | sort
grub2-2.12-11.1.x86_64
grub2-i386-pc-2.12-11.1.noarch
grub2-x86_64-efi-2.12-11.1.noarch
ruby3.3-rubygem-cfa_grub2-2.0.0-1.21.x86_64
#

AFAIK scriptlets are called from the rpm spec file - if they are failing, open a bug against Rocky, and let them decide if it needs to be pushed upstream.

Thank you, mrmazda. This is an EFI system though I have a few legacy based systems on it as well. You post has me considering attempting enabling CPM Legacy Boot options just as I do for those few systems but as a Rocky installation alternative just to avoid the whole EFI Grub2 added complexity.

Thank you svg00. I have mentioned in Rocky message boards that I do suspect a bug but have not officially filed a claim yet. I may soon but hope to find some workaround sooner. I've ordered a PCIe NVME caddy that basically treats NVME drives as portable drives, sort of a floppy drive on steroids. Before I give up and file a bug report, I intend to turn off all other drives, load a blank one in the caddy and let Rocky try an automatic install. I hate the very idea of that but at least I won't have to worry about any collateral damage and it might work since many devs assume all users are incapable of administration, and prefer "just let me do it for you".

Originally Posted by enorbet I've ordered a PCIe NVME caddy that basically treats NVME drives as portable drives, sort of a floppy drive on steroids.

Sounds reasonable - not all NVME are created equal; new gens popping up all the time, and the support can be spotty.

Bug reports aren't (always) a bummer. They can ensure updated support gets out to everyone sooner ...
I have no qualms about reporting issues.

All my existing NVME drives on my Main are EVO Pros. I don't suspect them at all. I've witnessed far too many cases where devs make assumptions based on how they like to work instead of according to capabilities and limitations. In short, many enforce preferences as if they were rules and Grub is rife among them..

Originally Posted by syg00 ... and the support can be spotty.

Yeah, that was a bit lazy of me. I also meant "support from the distros (and thus devs)" can be a bit spotty.

Personally I'd blame the packaging of the grub install rather than grub itself - with no evidence myself of course.

Thanks everyone but this is Solved by abandonment. After 2 weeks it appears few if any other people are having this problem so I'm done with Rocky. The only reason I actually wanted to try it, despite disliking Gnome, was because BlackMagicDesign, the authors of DaVinci Resolve (a rather fine free video editor gaining ground on Adobe Premier) specifies Redhat/Rocky as the designed-for distro. After all this incredible trouble over such a little thing as installing grub support files, it was just easier to get my working Suse Tumbleweed system to work perfectly with Resolve. All it took was installing a handful of support libraries and it's golden.

If any mods wish to delete this as it isn't technically Redhat it's fine with me since I won't mark it solved since I merely gave up trying and moved on .