The officially official Devuan Forum!

Simplicio

Member

Registered: 2017-04-21

Posts: 23  

Feature Request:Include a loopback.cfg in the iso

It would be nice if a maintainer could find the time to include a loopback.cfg as part of the iso build.

Details here: https://www.supergrubdisk.org/wiki/Loopback.cfg

Examples of its use are here: https://www.aioboot.com/en/boot-linux-iso/

The benefit is that it allows easy booting off a downloaded iso without needing to find a blank USB memory drive to write the ISO to.
Of course, there might be good reasons for not doing this that I am not aware of.

Simplicio

Last edited by Simplicio (2018-08-29 10:12:26)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: Feature Request:Include a loopback.cfg in the iso

I've done it this way, without a loopback.cfg in the iso.

menuentry 'Live ISO Boot' {
        insmod part_msdos
        insmod part_gpt
        insmod ext2

        set isofile='(hd0,gpt13)/isos/refracta8_xfce_i386-20161014_1432.iso'

        loopback loop "$isofile"
        linux (loop)/live/vmlinuz boot=live findiso="$isofile" noeject
        initrd (loop)/live/initrd.img
}

It looks like the advantage of using the loopback.cfg is the ability to just drop the isos into a directory and get a list of them at the boot screen. But that requires the isodetect.lua script from Super GRUB2, which only works if grub is compiled with lua support. I don't know if debian's grub can use that.

Most times, I just boot isos in virtualbox or qemu, so I don't have to reboot.

Simplicio

Member

Registered: 2017-04-21

Posts: 23  

Re: Feature Request:Include a loopback.cfg in the iso

Thank-you for that.

Unfortunately, the way that I have my system set up[1] means the grub script you kindly gave as an example doesn't work for me. It fails in initramfs with a message about not being able to find some media (I didn't write down the details). The odd thing is, something very similar does work for a (L)ubuntu ISO - 18.04.1, which inhabits the same partition as the Devuan ISO. It would have been quicker to write out a USB memory drive - but the itch I have is: 'Huh? Why doesn't this work?'.

menuentry "Lubuntu 18.04.1 ISO" {
insmod iso9660
insmod ext2
insmod udf
insmod part_gpt
set root='hd1,gpt5'
set isofile="/lubuntu-18.04.1-desktop-amd64.iso"
loopback loop (hd1,gpt5)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject toram --
initrd (loop)/casper/initrd.lz
}

I can't swear the above is the correct script: I was modifying scripts on-the-fly in the grub command line, so I'll have to go back and double check and see if I can validate the above.

It's not preventing me from booting an installer from a USB memory drive, so no reply is needed - there are more valuable things to do with your time.

The reason I'm doing this is to allow me to do a quick check that my hardware is supported by Devuan, which is why loading it up in a virtual machine is not what I'm after - otherwise that would be another way of doing this, as you say, without the inconvenience of a reboot.

I wasn't aware of the lua requirement, and a quick look with Internet searches didn't give me any clue as to whether it is compiled into the Debian grub - although I did find a conversation with a grub developer who did not want it as part of standard grub, but in 'grub-extras'. SuperGrub2 disk has got me out of a couple of scrapes with poor UEFI implementations before, but I've never looked deeply at how it does its magic.

Regards,

Simplicio

[1]My boot partition is on an LVM volume in a LUKS container. The EFI System Partition simply has the grub executable, which automagically finds the LUKS container, then prompts me for the password, which, if valid, allows grub to open the LUKS container, find the LVM volume and use the boot partition, so the environment that the iso finds itself in is somewhat non-standard. The ISOs are currently located on a non-encrypted partition that is not managed by LVM. This set up was simply done to see how much of the system could be made to be protected by full disk encryption. In principle, the ESP could be put onto a removable USB memory drive, and possibly LUKS could be set up in detached-header mode leaving the internal storage device appearing to be a random(ish) assemblage of bits. I have not tried to complete this proof-of-concept (yet).

Simplicio

Member

Registered: 2017-04-21

Posts: 23  

Re: Feature Request:Include a loopback.cfg in the iso

Just checked - that is the grub2 script that works. Posting from Lubuntu 18.04.1 now.

lubuntu@lubuntu:~$ uname -a
Linux lubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
lubuntu@lubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

To my mind, that means that there probably ought to be a script that works for Devuan, I just haven't got it right yet. On the other hand, the Devuan startup might be different to (L)ubuntu in a way that is significant. It's this need to tweak scripts that made me wish for loopback.cfg.

What I'm aiming on doing is building a USB memory drive with multiple ISOs on it so that I can invoke DBAN, SuperGrub2, rEFInd, SystemResueCD, and others, including Devuan, (and possibly even a Puppy Linux setup) to use as a 'Swiss Army Knife' when installing Linux on recalcitrant laptops (like the Infamous Acer ES1-132 series), and rescuing other people's data (or deleting data before disposal of hardware). At the moment, I have a resealable freezer bag with 'a number' of USB memory drives in it.

As I said in the previous posting, installing Devuan would likely not be a problem, this was triggered by me wishing to do a quick suck-it-and-see to see if Devuan booted nicely on my hardware. It would have been faster for me to walk to the nearest store selling USB memory drives, buy one, and write the ISO out to that, but there's no challenge in that, and it costs money. :-)

Simplicio

Last edited by Simplicio (2018-08-30 10:00:06)