Suggestion: Use loopback.cfg for Ubuntu ISOs

[steve6375]

Most Ubuntu ISOs have a loopback.cfg menu file which should contain the correct kernel parameters to boot from the ISO. A typical grub2 menu used 'configfile /boot/grub/loopback.cfg' to use it. e.g.

menuentry "Ubuntu" {
        set iso_path=/_ISO/Ubuntu64.iso
        export iso_path
        search --set=root --file $iso_path
        loopback loop $iso_path
        set root=(loop)
        configfile /boot/grub/loopback.cfg
        loopback --delete loop
}

This means that the correct kernel parameters will always be used and you don't need to maintain the menu code,
I suggest you modify the Ubuntu inc menu so that it looks for the loopback file and uses it if it exists - if it does not exist then use the default linux and initrd commands as usual?

[thias]

This has been somewhat of a recurrent topic: Some iso images include grub configuration, and often ready to be "chained" using a loopback.cfg file. This allows to jump into the iso's original boot menu, including all options.

Pros:

• Less maintenance in GLIM
• All original boot options provided

Cons:

• Less straightforward and minimalistic user experience (now with a ton of extra memtest! 😄)
• Mixing GLIM's grub environment and the iso's can have a lot of side-effects

This last point is the most important one. The visible case is when returning from the iso's grub into GLIM, where things like fonts and images may be kept from the iso's menu. But that's just the tip of the iceberg, as many set variables will be traveling both ways...

One possible solution (or at least improvement) would be to try and re-initialize all of the GLIM grub when returning from an iso grub menu. The existing restore_root is already doing something in that direction to avoid full blown breakage, but it would need to be extended to make sure that:

• GLIM doesn't leak important variables into the iso's grub (renaming some variables? unsetting them?)
• GLIM fully re-initializes when returning from an iso's grub

Currently, this can be tested with Ubuntu and most of its derivatives:

    [...]
    use "${isoname}"
    loop $isofile
    change_root (loop)
    set iso_path=$isofile
    export iso_path
    configfile /boot/grub/loopback.cfg
    restore_root
  }

I actually revisited this today when trying to add support for NixOS (see #120), but the iso's grub, although displaying file, just freezes on all entries. I suspect some variable other than the requires iso_path causing issues, but haven't tried to debug it.

@slowpeek : Do you have any thoughts or insight on this?

[slowpeek]

many set variables will be traveling both ways

configfile creates a new context, var changes dont travel back to the caller if you return from it with Esc

The existing restore_root is already doing something in that direction to avoid full blown breakage

It is there because of the way you create the menus. In stuff like

  menuentry .. {
    ..
    change_root (loop)
    configfile /boot/grub/loopback.cfg
    restore_root
  }

the menuentry block works in the outer context, hence if you change root there you must restore it. If only you've replaced menuentry with submenu, the block would work in its own context and nothing would leak to the outer context. Also, if going for submenu, configfile is excessive, use source instead. Besides, configfile is not just "source in new context", it has more stuff under cover with weird side effects. So the block can look like this without any leaks back

  submenu .. {
    ..
    root=(loop)
    source /boot/grub/loopback.cfg
  }

Currently, this can be tested with Ubuntu and most of its derivatives

Some recent ubuntu live-server isos have loopback.cfg broken (iso-scan/filename= piece is missing). I reported it and it was fixed around Jul 1, 2023 in daily builds. Broken versions: 21.04 21.10 22.04 22.04.1 22.04.2 22.10 23.04. Fixed since: 22.04.3 23.10

Mixing GLIM's grub environment and the iso's can have a lot of side-effects

It became rly bad with Debian 12. They even use raw $prefix in a loopback config wannabe.

---

Other things aside, the most relevant application for native loopback configs would be Tails since there are security related boot options that change from time to time. But they dont provide loopback.cfg, even though it boots with casper. I asked the devs about providing loopback.cfg but they said it is bad for security.