gobolinux/LiveCD

Boot from loop-mounted ISO with GRUB2 using loopback.cfg

Opened this issue ยท 17 comments

GRUB2 can boot from loop-mounted ISO files if the OS support it, some examples can be seen at https://help.ubuntu.com/community/Grub2/ISOBoot/Examples. This allows tools like SystemImageKit to boot from a variety of Live ISOs stored on a disk.

It would be great if GoboLinux could boot from an ISO stored on disk in this way, ideally by providing a loopback.cfg file that would make this super easy.

How does this differ in practical terms from booting it from, say, QEMU?
Will it enable graphics rendering?

There is no overhead for virtualization. You are running the OS on "bare metal" and get native speeds and native graphics.

If so, how do you specify which toolkit (e.g., gtk, qt) to use when loopback-booting it?

I do not understand this question. Booting a loopback-mounted ISO does the exact thing as if you would boot the same ISO burned to a CD.

@probonopd I'm confused about which feature you are asking for:

(a) Do you want us to make any changes (which?) to the GoboLinux ISO so that it can be loopback-mounted and booted from within other OSes?

or

(b) Do you want to be able to boot loopback-mounted ISOs of other OSes from within GoboLinux? (If so, which changes would be needed?)

@hishamhm I am asking for (a), make it possible for the GoboLinux ISO to be loopback-mounted and booted. But not "from within other OSes", but from the GRUB2 boot loader (with no other OSes being involved).

Essentially the live-boot mechanism needs to have a way to loop-mount the ISO during boot up.

For example, Ubuntu Live ISOs allow the path to the ISO to be passed in using iso-scan/filename=/the/path/to/the.iso. The system in the initrd then knows how to boot from the ISO, essentially by loop-mounting the ISO and then continuing from it. The parameter is handled by the script scripts/casper-premount/20iso_scan in Ubuntu's casper initrd.

@probonopd ahh... please take a look at the BuildLiveCD repo. This doc page and the wiki also have information on how to use the scripts and rebuild the ISO. (Users have in the past successfully used this info to replace the kernel in the ISO, for example.) If you succeed at it, a PR adding the proper loopback.cfg file would be most welcome!

@hishamhm unfortunately I am entirely new to GoboLinux but I would really like to try it out, which is why I am asking for a way to boot it from an ISO without having to burn a CD first...

Anyhow, I believe the code needed would need to go somewhere in https://github.com/gobolinux/BuildLiveCD/blob/master/bin/MakeInitRDTree - the initrd would need to loop-mount the ISO and use that, instead of a real CD.

Examples of other projects using it: Here

@probonopd if a DVD-R is not handy (I no longer have an optical drive), you can also boot from an USB stick :) (just run dd if=GoboLinux-016-x86_64.iso of=/dev/sdb to overwrite the stick with the ISO (assuming the USB stick is sdb of course :) )

I know, but a USB stick per operating system (I have hundreds of them) is a bit much too ;-)

in my case writing to the iso to usb (I used rufus) doesn't let the iso boot as when it gets to Mounting GloboLinux Install CD... it fails as CD-ROM is not mounted/valid nor does /proc/ide/hd*/(forgot last part) exist

Just to be clear, I am not asking to put the image on a USB stick using dd, but I am asking for
https://www.supergrubdisk.org/wiki/Loopback.cfg

What is a loopback.cfg?

A loopback.cfg is basically just a grub.cfg that's designed to be used to boot a live distribution from an iso file on a filesystem rather than an actual physical CD.

What problem is it trying to solve?

First some background:
Most GNU/Linux distributions' LiveCDs support being booted with the iso file on a hard drive, without needing to actually burn the image to a CD. This works not by "chainloading" the iso (which is impossible) but by extracting the kernel from the iso, either before hand or at boot time with grub2's "loopback" command. The kernel is then passed a parameter that tells it that it needs to look for its root not in /dev/cdrom, but by loop mounting an iso file. This parameter also tells the kernel (more precisely the initrd scripts) what path the iso can be found at.

The problem is that to actually boot such a distribution you need to know the path to the kernel / initrd within the iso, the particular kernel parameter that distribution uses to specify the path to the iso, and any other kernel parameters relevant to the distribution. Even knowing that, when you boot the iso you don't get the menu and options you'd get when booting the CDROM. With a loopback.cfg you get the full menu of options at boot and don't have to worry about differences between different distributions.

Am I really the only one who wants to boot GoboLinux in this way?

grub

I come to this thread as I'm seeking suitable rescue environment ISOs for my server deployment.

Because of the involvement of EFI these days, if one one wants to be able to boot from an ISO file from Grub, the loopback.cfg is mandatory. I'm looking at this from the perspective of a sysadmin imagining how I'd go about repairing my servers software configuration if it has a problem once it's in the datacenter that's a 4 hour drive from my house. IPMI+OOBM "KVM" is great and all, but the faster you can get into rescue environment with the tools you need the better. Mounting an ISO over the network with the fancier OOBM solutions, like HPE's ILo5, would work, but is far from fast or ideal.

I'm suprised by how few have look at is from this perspective and seen this feature as imperative. The list is currently very short:
https://www.supergrubdisk.org/wiki/Loopback.cfg

Your distro probably wouldn't make a good rescue environment for me, but I thought I'd at least share my thoughts on the general rationale that tends to be behind those pushing for this feature.

We've just completed the development cycle for 017. I don't have an easy way to write and test a loopback.cfg file. However, if you can produce one based on our current grub.cfg then I can look into merging it.

Thanks @lucasvr. How does one tell the GoboLinux initrd to loop-mount the GoboLinux ISO and boot from there?

This is how it is done e.g., on Ubuntu:

iso-scan/filename=/boot/iso/some.iso

The source code that does the work is in lupin-casper:
http://archive.ubuntu.com/ubuntu/pool/main/l/lupin/lupin_0.57.tar.gz

Does the GoboLinux Live initrd have the capability to do this? If not, it would need to be implemented first.

Sorry I'm late to this party, but I was searching for a solution to this
issue and stumbled on this discussion and since I've managed to figure out
a means of getting this done, I'll go ahead and document it here.

On the first attempt I made, the Gobolinux ISO was stored on disk in the first
partition (sda1) as /gobo.iso and so the grub loopback entry looked like this:
menuentry 'Gobolinux 17' {
loopback loop (hd0,msdos1)/gobo.iso
linux (loop)/isolinux/kernel initrd=initramfs root=live:LABEL=GOBOLINUX_LIVE_INSTALLER Boot=LiveCD vt.default_utf8=1 audit=0 video=LVDS-1:e video=HDMI-1:e video=VGA=1:e rd.live.image rd.live.debug=1 rd.live.dir=/ rd.live.squashimg=gobolinux-live.squashfs rd.live.overlay.overlayfs rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 rd.live.ram=0
initrd (loop)/isolinux/initramfs
}

Booting from that grub menu entry failed with a hard hang.

After looking at the initramfs generation scripts in the Gobolinux source, I
realized it was using dracut to build the initramfs and after reading up on
dracut I noticed that iso-scan/filename was supposed to "just work". So the
second attempt at the grub entry was to append
iso-scan/filename=/gobo.iso
to the grub entry. Unfortunately, that failed as well.

After a bunch of experiments with qemu I realized that since it was a hybrid ISO
I could dd it to a partition. So the second attempt was to create a new (sda6)
partition on the disk (of size 2GB) and dd the ISO into that disk partition.
I tried to chainload from that partition using:
set root=(hd0,msdos6)
chainload +1

Unfortunately that didn't work either, so I decided to troubleshoot what was
going wrong with the earlier grub entries and tried it again and for some
reason it magically started working. After booting up into Gobolinux 17, I
realized that it had managed to see the ISO image that was dd'ed to /dev/sda6
and was using that (although I hadn't mentioned it anywhere in the grub menu).

So for now (and by dumb luck) I seem to have a workable solution but it
requires an additional partition on the disk - I guess I can live with that
additional constraint. The final grub menu entry I now have is:
menuentry 'Gobolinux 17' {
linux (hd0,msdos6)/isolinux/kernel initrd=initramfs root=live:LABEL=GOBOLINUX_LIVE_INSTALLER Boot=LiveCD vt.default_utf8=1 audit=0 video=LVDS-1:e video=HDMI-1:e video=VGA=1:e rd.live.image rd.live.debug=1 rd.live.dir=/ rd.live.squashimg=gobolinux-live.squashfs rd.live.overlay.overlayfs rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 rd.live.ram=0
initrd (hd0,msdos6)/isolinux/initramfs
}

I may go back and revist why iso-scan/filename didn't work if I ever need
that disk partition back.