How to run from a Live ISO stored on VFAT with grub2

How to run from a Live ISO stored on VFAT with grub2 using GRUB’s loopback capability? I would like to run Endless OS but I want to keep it as an ISO file alongside all my other Live ISOs, and not install it exclusively into a partition.

For Ubuntu, I can use iso-scan/filename=...

menuentry "ubuntu-14.04.1-desktop-amd64.iso - casper 1.340" --class ubuntu {
        iso_path="/boot/iso/ubuntu-14.04.1-desktop-amd64.iso"
        search --no-floppy --file ${iso_path} --set
        loopback loop ${iso_path}
        linux (loop)/casper/vmlinuz.efi file=/cdrom/preseed/ubuntu.seed boot=casper iso-scan/filename=${iso_path} quiet splash -- 
        initrd (loop)/casper/initrd.lz /boot/iso/additional-initramfs/initramfs
}

For Fedora, I can use root=live:CDLABEL=...

menuentry "Fedora-Live-Workstation-x86_64-22-3.iso - dracut 041-10.fc22.1" --class fedora {
        iso_path="/boot/iso/Fedora-Live-Workstation-x86_64-22-3.iso"
        search --no-floppy --file ${iso_path} --set
        loopback loop ${iso_path}
        linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-WS-x86_64-22-3 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 selinux=0
        initrd (loop)/isolinux/initrd0.img /boot/iso/additional-initramfs/initramfs
}

What do I have to use for Endless OS os-eos3.1-amd64-amd64.170520-055517.base.iso?

That’s not supported. You need to dd the ISO to the disk.

Where could I best file a wishlist ticket for this?

Since you’re familiar with this kind of thing, what information about Endless OS do you need to duplicate what you’ve done for the others?

I’ve created a wishlist ticket in our internal tracker for this, but any specifics you can give me will help.

Thanks

This would actually not be all that easy to do. We generate our GRUB menu entries at runtime, using a downstream module that reads BLS files. The kernel parameters include the OSTree deployment ID which varies for each image.

Can you give some insight into why this is useful? It strikes me that your use case is a relatively narrow one – I’ve not heard of keeping multiple live images on one USB stick before. Bear in mind that the Endless OS live session is purely transient – there is no support for persistent live sessions.

Sure:
As an independent software developer, I run hundreds of different distributions/versions to ensure my software runs well on them. I keep all of the OSes as ISO files and boot them using SystemImageKit, a software that writes GRUB entries for ISO files since this allows me to keep each OS in one file, not having to deal with partitioning, etc. This model scales best when it comes to keep hundreds of OSes around and being able to natively boot into them. Virtualization is not an option for me.

Don’t worry, I could generate the GRUB entry myself if you tell me how it needs to look like. I am also not interested in persistence.

Thanks. GRUB can launch the kernel and initrd from inside an ISO stored on VFAT/EXT. So far so good. But once the initrd takes over, the initrd must loop-mount the rootfs and pivot there. archiso (Arch; img_loop=... img_dev=/dev/disk/by-uuid/...), debian-live (Debian; findiso=...), Dracut (Fedora; iso-scan/filename=...), casper (Ubuntu; iso-scan/filename=...), and Kiwi (openSUSE; isofrom_device=/dev/disk/by-uuid/... isofrom_system=...) can do this by the way of passing in extra parameters telling the initrd what to do. Check out the detect_* scripts in https://github.com/probonopd/SystemImageKit/tree/master/boot/bin for details.

I would like to know the kernel arguments that I have to pass to the Endless OS so that its initrd loop-mounts the ISO and switches to the root filesystem contained therein.

Yep, we use this capability on our ISOs (the kernel and initrd live inside a GPT disk image inside a SquashFS image inside the ISO).

tl;dr: I don’t believe such kernel arguments exist right now. More details:

Here’s the initrd script that we use to boot from an image file, optionally wrapped in a squashfs, from a device passed on the kernel command line with endless.image.device=..., which is parsed here. It’s the same mechanism we use to boot from an image file stored on a Windows filesystem. This does not support an additional layer of loopback-mounting, which you’d need if the ISO is itself stored on another filesystem. (Perhaps there’s something that runs earlier in the initramfs which can loopback mount a file – I’m not sure. Not as far as I know.) endless.image.device and endless.image.file are added to the kernel arguments in our GRUB config.

This is a bit non-standard because for NTFS and exFAT image host partitions we do not loopback-mount the file, we directly map its on-disk extents. Some more info on the how and why in this blog post if you’re interested.

The path to the kernel and initrd, as well as the path to the OSTree to boot, contain an ostree deployment ID which is different for every new release:

These are determined at boot time by invoking the BLS module I linked to earlier. For a given release (3.1.8, say) these parameters are the same for all ISOs, but by design they will be different for 3.2.0 and every subsequent release.

From 3.2.1 (probably) I expect we’ll support an intermediate squashfs on exFAT and NTFS, not just ISO-9660, and it might be pretty easy to add support for (VFAT or EXT) → squashfs → disk image, which would allow you to unpack the ISO to your USB stick and then write the appropriate GRUB config. Supporting (VFAT or EXT) → ISO → squashfs → disk image is likely to be more work unless I’m missing something.

Interesting – I can see why this might be useful, particularly when developing AppImage. Thanks for the explanation!

The reason is naturally there. It’s convenient for Linux users to directly boot the iso file from harddisk using the installed grub on their OS for a try on EOS. And it’s should’ve been a good part of marketing for a fresh linux distribution within the linux community in the first place.

1 Like