openSUSE does have it if all of Grub is correctly installed, and in any case /boot is on a separate filesystem from /, that filesystem is mounted where it belongs.
/boot/grub2/custom.cfg only exists if you create it. Grub only ever reads it. It never writes to it.
The *buntu people created it for dummies who can't manage to run grub-mkconfig -o /boot/grub/grub.cfg. Not all distros find it necessary to include it.
YaST can handle Grub for you if you wish, but not to the extent you can do manually using a text editor and the tools Grub provides
I've searched openSUSE repos and https://software.opensuse.org/search without finding any such package.
It's one path. Note that by virtue of the number in its name, resulting stanzas at boot time will follow those produced by grub.cfg. It needs to be copied or symlinked to a number lower than 10 in order for custom.cfg entries to precede grub.cfg entries.

Well it ain't pretty yet but it's booting a single entry Custom menu. I'll clean it up and add the rest tomorrow. What was messing me up to where Grub couldn't find the kernel was that bit about root=, since it attaches to /boot apparently. Once I deleted "/boot" from "/boot/vmlinuz-5.12.12" so it reads "/vmlinuz-5.12.12" Bingo! Grub finds the kernel and away we go!

Thank you for your help and your patience mrmazda. You are very appreciated. Now that I have basic function I can start boning up on all the wildass syntax so I actually understand Grub.

FWIW I now have success in both Slackware and in OpenSuSe (Slackware was far more straightforward, as usual). Incidentally, neither has "/etc/grub2". They have "/etc/grub.d". I don't remember where I got Grub-Configurator but it's installed (in SuSe not in Slack... SuSe needs it 'cuz Yast is primitive and limited) and it works. Being a 20 year Slackware vet I'm far more comfortable with grub-mkconfig than update-grub. If Grub wasn't installed correctly in OpenSuSe it's SuSe's fault because it is literally DEfault.

Boot partitions, grub os-prober doesn't find other distros boot partitions, and mounting them similar to what works with lilo does nothing.

update-grub is wrapper for grub-mkconfig.

OpenSuSe and fedora based distros use grub2 naming for grub: grub2-install grub2-mkconfig /boot/grub2/grub.cfg

Most distros break grub up into 3 packages: grub-common grub-pc grub-efi. I think Slackware is the only distro that doesn't do this.

The big breakthrough for me happened by understanding that Grub's command line is it's own animal with it's own protocols, unlike anybody else's. Ther major A-Ha! moment came from using Grubs CLI and just entering "ls" which showed me that not only does Grub see and use drives differently with NVME drives last, but Grub reverses the order of the 2 NVME drives this rig has. This fouled up "hint" stanzas since os-prober basically just tries anything in a shotgun approach.

Naturally not realizing this compounded the scattershot way os-prober works, at least for the way I organize my drives where some past bootloaders needed all kernels in the same location to workaround chainload issues. Because of this, os-prober matches up kernels with distros that will inevitably fail which is why I vastly prefer telling my PC what to do over letting automation figure it out. I will be disabling os-prober ASAP now that a wee bit of dawn has arrived shedding some light on how Grub functions, thanks to you guys and a lot of work.

BTW colorpurple21859, I get it that "update-grub" is a wrapper for "grub-mkconfig -o /boot/grub/grub.cfg". The issue is the discrepancies in documentation over time and among different distros. It seems, again as usual, the most efficient way to learn is via command line,. so first order of business is to learn Grubs command structure and syntax. Hopefully then I can see distro-specific ways and means to get a grasp on consistencies within a distro to guide manual menuconfig.

As a Slack user, maybe you've never run into this before, but openSUSE, Mandrake, Fedora, RedHat and probably others did, and maybe still do, avoid that problem this way:This enables a bootloader to find the kernel in the "same place" whether the kernel is on a separate filesystem from / or not when specified as being in /boot/ rather than in /.

There are links at the bottom of each post you can click that do that.

I just fixed the typo in post #27 where you saw my mental error exposed (typing /etc/grub2 where should have been /boot/grub2).

OP I know its marked as solved but I too have disabled os-prober.

to boot W10 I use a 40_custom file that reads

menuentry "W10" {
insmod ntfs
set root=(hd1)
chainloader +1
}

Use root powers to run
mrmazda has mentioned the set root command, I prefer to explain this way.
For a linux system, grub2 is looking for the boot partition (or the partition that grub dir is on)
---the kernel line does not need UUID as discussed by smallpond, but it need root= (and I use /dev/sda1) (as I still use MBR)

And use can label ext2,3 and 4 partitions using e2label command, but I always use a live usb to do that so the parition is not mounted.
trivia, swap can also have a label but that is more relevant to /etc/fstab.

soo.....
IMHO if you prefer no os-prober, you should use simple /dev/sdxn style stuff.

For each distro, install its grub into the Partition Boot Record.
For all distro, have one grub2 in MBR
Yep none of that UEFI/GPT ...sorry got carried away there.

And then for each OS boot into the distro that controls MBR and create chainloader menuentry for each other OS

so a template would be for 40_custom from /etc/grub.d/

menuentry "P5" {
set root=(hd0,5)
chainloader +1
}

IMHO for linux chainloading you do not need to insert modules as most for linux have already been loaded by the header script.

grub2 counts menuentries and hard drives from zero and partitions from one.

If you like this way.....you will need to run the grub-install command from each OS to install into its PBR.

2) you should be able to find your update-grub command.
Mine is a script. I would not trust any distro that hides real commands from me.

Thanks Aus9 but I have returned to rEFInd. I am still a bit jealous that Grub apparently doesn't need a Fat32 ESP partition, but it's idiosyncrasies just put me off too much, especially how it sees drive order. Every other bit of software I know of lists NVME drives first. Only Grub2 afaik lists them last. It just tells me grub developers have little concern for compatibility and convention.

Personal Computers have been around for almost 50 years now and to me it makes zero sense that in almost a half century booting hasn't become absolutely trivial and basically universal. Much of the blame goes to Microsoft and what's left of the heavy Wintel "lobby" but that's a whole other soap opera.