The installation procedure is too complicated

[snshn]

I believe there's a bottleneck in making glim a more popular way of booting distros due to the overly complex way of installing it on a USB drive when compared to using dd to "cat" the image of hybrid ISOs onto the drive. It's a real shame, as it's in my opinion, could be a safer, faster, and more convenient way of booting ISOs from USB drives if only more people could take advantage of it by having a more basic way of getting glim onto their USB drives.

I'd like to suggest to introduce these features, which some of I could take care of myself if the idea is welcome:

• [ ] start issuing releases of glim which can be dd'd and then expanded to the full size of the USB stick/drive as the primary way to install glim
• [ ] include a script inside of the boot partition which could be used to git pull the latest set of config files from the GitHub repo to keep things up-to-date
• [ ] if possible, make the menu display information regarding which ISOs can be booted from the boot menu upon load (e.g. greying out missing ISOs)
• [x] using a wildcard-based mechanism of locating ISO images to boot, to make glim more version-agnostic when it comes to releases of various distros

[snshn]

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

[probonopd]

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

[snshn]

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

[thias]

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

[probonopd]

The grub2 regex module looks very interesting indeed

Indeed! 👍

[thias]

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

[thias]

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.

[thias]

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

[thias]

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 :sweat_smile:

[D-Nice]

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.

[thias]

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.

[LaKing]

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