Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootable ISO creation support #215

Open
adrelanos opened this issue Oct 13, 2023 · 3 comments
Open

bootable ISO creation support #215

adrelanos opened this issue Oct 13, 2023 · 3 comments

Comments

@adrelanos
Copy link
Contributor

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
Copy link
Member

mika commented Oct 13, 2023

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 grml/grml-live@d6d5fee), now what's left to be done is ripping out the fai dirinstall and fai softupdate parts from grml-live. This is mainly about:

  • software selection via classes (from /etc/grml/fai/config/package_config)
  • taking over configuration files (from /etc/grml/fai/config/files)
  • executing the scripts (from /etc/grml/fai/config/scripts/)

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
Copy link
Contributor Author

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
Copy link
Member

mika commented Oct 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants