Here's what I found so far regarding the wildcard support in GRUB2: https://unix.stackexchange.com/questions/415049/generating-menuentry-for-iso-images-dynamically-in-grub-cfg

How would that work if there is more than one matching ISO, e.g., multiple versions of the same distribution?

I don't think it'd be a problem, but if otherwise, then perhaps another for loop could take care of giving options for different versions. Take a look at how this person's approaching it in their repo https://github.com/aguslr/multibootusb

All valid points. The grub2 regex module looks very interesting indeed, I'll definitely be having a closer look and trying it out.

The grub2 regex module looks very interesting indeed

Indeed! 👍

I've been trying to create version-agonstic menus, but I've hit a blocker. The context for variables when looping has them overwritten inside a submenu, making their assignment for the last menuentry being used for all menuentries. It seems like a possible workaround would be to change menuentries to become submenus, but that's less user-friendly (one extra menu level) and might require duplicating some logic (filename regexps). This is what I've tried, with GNOME and KDE variants, variables are for KDE when the GNOME entry is booted:

# CentOS
for isofile in $isopath/centos/CentOS-*-Live*.iso; do
  if [ ! -e "$isofile" ]; then break; fi
  regexp \
    --set=1:isoname \
    --set=2:version \
    --set=3:arch \
    --set=4:variant \
    --set=5:build \
    "^${isopath}/centos/(CentOS-([^-]+)-([^-]+)-Live([^-]+)-([^-]+)\.iso)\$" "${isofile}"
  menuentry "CentOS ${version} build ${build} ${arch} Live ${variant}" --class centos {
    echo "Using ${isoname}..."
    loopback loop $isofile
    probe --label --set=isolabel (loop)
    linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=${isolabel} rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 iso-scan/filename=${isofile}
    initrd (loop)/isolinux/initrd0.img
  }
done

Quick followup. The menuentry arguments are available inside it, so the following seems to be a valid workaround:

menuentry "CentOS ${version} build ${build} ${arch} Live ${variant}" "${isofile}" "${isoname}" --class centos {
  set isofile=$2
  set isoname=$3

Not ideal, as it seems useless at first, but it seems to work.

I have converted a first batch of menu entries to be "dynamic", meaning that they will likely keep working when new distribution releases come out (though boot options and kernel/initrd locations changes could break them, of course). See 2f7b6de.

The points about git pull and the greyed out images might be moot with dynamic menus, no?

I think only the installation point is still relevant, and I've been giving it some thought and looking around. The best I could come up with for now is a small-ish image which includes a GParted Live image. It can be dd'ed to an USB memory, and once GParted is run (loaded to RAM), it's quick and easy to expand the partition+filesystem to the maximum available size. Here's a working proof-of-concept (315MB download): http://dl.marmotte.net/tmp/GLIM-gparted.img.gz

It would be best to have something even smaller and automatic, similar to what Raspbian does with the Raspberry Pi SD image, but I haven't found anything quick to integrate. A minimal Linux distro that would execute parted through a single robust script would do... hints on some existing bits would be great 😅

I'll respectfully disagree and found this in fact to be by far the easiest multiboot procedure I could do from Linux for Live ISOs.

mount
run script
cp or wget, your call

3 super basic linux commands, while prior to this I wasted hours with other GUI or CLI-based ones, which had various incompatibilities, issues, and bugs, and in the end didn't end up working. While this worked flawlessly.

However, additional adaptibility to other ISOs would be great to have out of the box.

Yeah... my idea with the recent changes isn't to change much, just add options. The glim.sh script will always stay the main install method, and will just be used to create a .img.gz file that people can dd or similar) to an USB memory if that's easier for them (Im guessing Windows and macOS users).

Right now I've been testing .img.gz files that are about 5MB in size and create a 1GB uncompressed .img. Once written, it just needs to be mounted, a gparted iso copied to boot/iso/, and it can then be booted to trivially resize partition+filesystem to fill the entire USB memory. Or people can resize from their OS, though I don't intend to explicitly support that: Both the underlying dos partition and the fat filesytem need to be resized... I could easily write instructions to do that on GNU/Linux, which is what I know and use, but those users are better off just using the glim.sh script.

The installation procedure is not complicated at all. It is super easy.