Comment # 68 on bug 1226122 from Felix Miata

(In reply to Martin Wilck from comment #53)
> Out of curiosity, if any of these many distros get a kernel update, you'll
> have to adapt the "main" distro's grub.cfg. I suppose you use some custom
> scripting for that purpose? This is one of the reasons I prefer using
> "configfile", it allows me to update each individual distro's config
> separately to keep in sync with updates.

The primary bootloader's stanzas include no kernel versions. Booting is done
entirely with symlinks to kernels and initrds. e.g.:

# ls -gGlh vmlinuz-??? vmlinuz initrd initrd-???
lrwxrwxrwx 1 22 Jul  1 08:44 initrd -> initrd-6.7.9-1-default
lrwxrwxrwx 1 22 Jul  1 08:44 initrd-cur -> initrd-6.7.9-1-default
lrwxrwxrwx 1 24 Jun  5 19:55 initrd-prv -> initrd-6.6.32-2-longterm
lrwxrwxrwx 1 23 Jul  1 08:44 vmlinuz -> vmlinuz-6.7.9-1-default
lrwxrwxrwx 1 23 Jul  1 08:44 vmlinuz-cur -> vmlinuz-6.7.9-1-default
lrwxrwxrwx 1 25 Jun  5 19:55 vmlinuz-prv -> vmlinuz-6.6.32-2-longterm
#

Anytime I wish to boot prior kernel, it's a simple matter to edit the
applicable Grub stanza.

AFAICT, my methodology rules out any booting system that requires hosting
kernel and initrd on an ESP, unless FAT32 somehow gains symlink support. Even
if it did, I wouldn't want to see kernels & initrds from multiple installations
sharing one ESP, while one ESP per PC is my strong preference.

(In reply to Mario Guzman from comment #67)
> Do you want this issue to remain open until that is fixed, or do
> you want me to close this issue and open another for the missing nvram/mbr
> options for sdboot installation?

Missing nvram/mbr options would seem to be a distinct issue worthy of its own
bug.