Also check SystemImageKit

[probonopd]

You might also be interested in https://github.com/probonopd/SystemImageKit

SystemImageKit lets you run Fedora, CentOS, Ubuntu, Debian, and openSUSE (based) live systems, all directly from unchanged live ISOs all stored on the same physical medium (e.g., USB drive). Currently support for the live booting systems of the mentioned distributions is built in, but the system is modular so that detection scripts for other distributions can be added relatively easily.

SystemImageKit also has means to customize every aspect of the boot process and the booted system, so that you can customize the live systems without having to remaster their live ISOs. It does so by allowing you to overlay files in the initramfs and to overlay files in the booted system.

[aguslr]

Hi @probonopd!

Great project, by the way. Yours provides much more functionality. Keep the good work! :+1:

[probonopd]

...but yours supports more distros. :+1: Perhaps we can work together?

[aguslr]

Perhaps we can work together?

Is there a way to integrate our scripts into your project? I saw probonopd/SystemImageKit#25, which would address this in a way, although we are using just GRUB scrips and yours use shell scripts.

[probonopd]

As you have probably seen, SystemImageKit dynamically writes grub.conf based on what Live ISOs are available on the system. Right now I am doing this using bash scripts, but if there is a way to do the same with GRUB scripts I'd happily use that. If it is not possible, then we'd have to make bash scripts out of the GRUB scripts...

[probonopd]

Comparison

Feature	multibootusb	SystemImageKit	Ideal solution
Where does the ISO detection code live	In GRUB scripts	In bash scripts	In GRUB scripts and partially in C code/patches where needed
Number of supported distributions families	Few	Many	All
Can load secondary initramfs for early-boot customizations	No	Yes	Yes
Can append to kernel command line supplied by the ISO	No (when loading loopback.cfg)	Yes (using bash)	Yes (could be realized within GRUB)
User can just throw in a new ISO and it works	Yes	No (needs to run a bash script)	Yes
User can change the keyboard layout globally	Yes	No	Yes
User can change the keyboard language globally	Yes	No	Yes
User can change the timezone globally	Yes	No	Yes
User can run a custom init script that runs before the real init script	Yes	No	Yes

So I think multibootusb has the better architecture but is currently lacking mainly the two features SystemImageKit uses a lot to provide the "user can..." functionality, namely,

1. Appending strings to kernel command line supplied by the ISO, which is useful, e.g., for

• Setting the language
• Setting the keyboard
• Calling a custom init that can do late-boot customizations

2. Appending a secondary initramfs that can do early-boot customizations (changes to the initramfs), which is useful, e.g., for

• Fixing broken loopback boot
• Customizing splash screens
• Controlling other aspects of the early boot

Ideally, we would implement these two main features in multibootusb (can you do this?), and then port over the remaining functionality from SystemImageKit using those (I can do this thereafter).

Now, it is not clear to me whether 1. and 2. can be implemented purely using GRUB scripting, because in the case of loading loopback.cfg files from within the ISO, we would need a way to modify the loaded loopback.cfg on the fly.

Hence, possibly we need to write something on the GRUB level, either

• A patch to the linux and initrd keyword so that, when these are called, custom strings (set by us) are appended (e.g., hooking in here), or
• A custom GRUB module that would implement the logic

Please let me know whether you are interested in collaborating on these things.

I think multibootusb is super useful but should gain some functionality that SystemImageKit already has (at the expense of currently being a mess of bash scripts), and I think we should merge the projects to join forces.

[KurtPfeifle]

Having the combined features of MultiUSBboot and SystemImageKit (plus some more) in one project would be super-useful.

And it could create its own category as a "Meta-Linux-ISO-Distribution" on Distrowatch, leading the popularity contest from day 1 :-)

[aguslr]

@probonopd, I think the table is wrong, all the "user can..." should be No in this project and Yes in yours, right? :wink:

A custom GRUB module that would implement the logic

BTW, as I mentioned in #155, it seems that grub-iso-multiboot has done something similar to what you're looking for by modifying GRUB.

GRUB scripting is limited in the fact that, as soon as the kernel boots up, all the variables and the environment we have set is lost, except those we've passed to the kernel itself. Unfortunately, as you have noticed, different distros use different kernel boot parameters.

Those that use loopback.cfg, which simplify booting ISOs immensely, only accept the iso_path variable. We could of course cheat by adding more stuff to iso_path (e.g. iso_path="$iso_file some_other_stuff"), but I'm not sure that would even work.

Therefore, this probably should be achieved by modifying GRUB or using a GRUB module. I can't tell for sure because I'm not experienced in C programming or modifying the kernel/initramfs.

[probonopd]

@probonopd, I think the table is wrong, all the "user can..." should be No in this project and Yes in yours, right? :wink:

Oops, yes, looks like I confused the columns for some entries. But one gets the idea - we have two tools that do more or less the same thing, with some differences in implementation and feature set.

Therefore, this probably should be achieved by modifying GRUB or using a GRUB module. I can't tell for sure because I'm not experienced in C programming or modifying the kernel/initramfs.

Yes, I come to the same conclusion that doing it in C as a GRUB module would probably be best. Right now I am lacking the time to do it though...