search

grml / grml-debootstrap

wrapper around debootstrap
59 stars 27 forks source link

bootable ISO creation support #215

Open adrelanos opened 1 year ago

adrelanos commented 1 year ago

For now, grml-debootstrap only supports the creation of bootable VM images.

It would be nice if it could also create bootable ISOs.

There is also grml-live which can create ISOs but that seems quite a more complex tool with a steeper learning cure where one needs to understand FAI for customization.

Would you be open to merge a pull request with such a feature?

An alternative could be if it's simple to convert a (grml-debootstrap created) bootable raw image to a bootable ISO image but I am not aware of such tools existing.

mika commented 1 year ago

Heh interesting timing! :) Actually, I would like to get grml-debootstrap working as underlying tool for grml-live, exactly to get rid of FAI, and we only recently discussed this in #grml on IRC. :)

I am not yet convinced that adding ISO support to grml-debootstrap is the way to go, given that all the relevant bits already exist in grml-live. But once grml-debootstrap can prepare the environment for grml-live to take over, we could drop FAI usage from grml-live, and then things should become easier (vision: execute grml-debootstrap -t /path/to/grml_chroot … and then grml-live -o /path/to/grml_chroot -b to generate the ISO).

We already got rid of the fai-server part within grml-live (see https://github.com/grml/grml-live/commit/d6d5fee3336422b9abae4f8e7f32e029d8b26d5e), now what's left to be done is ripping out the fai dirinstall and fai softupdate parts from grml-live. This is mainly about:

The class based approach from FAI is a great idea + design, so I'd like to preserve the idea of it within grml-live, would actually also like to bring this towards grml-debootstrap (to make software selection and configuration more flexible but also easier to maintainer).

Does this answer your question and give you an idea about my vision?

adrelanos commented 1 year ago

Thank you for your detailed reply, and than you for grml-debootstrap!

This is certainly a great vision! Avoiding code duplication is the way to go. And grml-live without FAI also sounds nice.

Once missing piece would be grml-live in packages.debian.org. I guess I could post a feature request (RFP) to package grml-live.

Or you could consider to merge to grml-live repository into the grml-debootstrap repository if that makes sense? Then there would not be need for an additional Debian package.

mika commented 1 year ago

Once missing piece would be grml-live in packages.debian.org. I guess I could post a feature request (RFP) to package grml-live.

TBH, currently I don't want to maintain grml-live within Debian. It tends to add too much burden on me as upstream, esp. whenever Debian goes into freeze mode for an upcoming stable release. I am already a bit unhappy about the situation with grml-debootstrap during those freeze times, e.g. when I need to hold back changes / PRs in our Git that aren't necessarily stable enough for inclusion with the upcoming Debian stable release, or when Debian makes last time changes for which I need to update grml-debootstrap and go through release team exceptions etc. I neither feel like I want to maintain grml-live within Debian/stable.

I want and need to be able to release a new Grml (ISO) version whenever needed, independent of the current state of Debian stable/testing/unstable WRT freeze etc, and grml-live is the driving tool of Grml and very essential for Grml releases.

Furthermore grml-live can be used directly and straight from its Git repository (I put quite some efforts into that to provide that option), and we also provide the grml-live Debian package through our Grml repositories.

Or you could consider to merge to grml-live repository into the grml-debootstrap repository if that makes sense? Then there would not be need for an additional Debian package.

At least currently no, that would destroy lots of useful Git history, and we're back to the problem of maintaining grml-live within Debian (see above), no? :) I'm also uploading grml-debootstrap towards Debian, while the grml-live stuff isn't supposed for upload towards Debian. Also it would still be part of the Debian source package (of grml-debootstrap) then etc, not even considering the copyright situation we'd need to sort out.

We can think about one single/combined repository/project if we should ever get towards one single project that provides features of both grml-debootstrap and grml-live, but currently we are not there, and I also don't want to recreate one big thingy (esp. from scratch, hello second-system effect).

tl'dr: I think the next building blockwould be getting rid of FAI from within grml-live and see how grml-debootstrap could be used (as replacement for FAI) instead.