osbuild
LiveOS support
@hanthor Can you provide some more information about this, what needs to be done?
We have a hack that works here https://github.com/ublue-os/titanoboa
Basically we dump the image to disk and then install the live-OS components, pull the image again, and put it in a squashfs->ISO. It supports Flaptak installation by copying over the flatpaks from the live to the installed in a post ks.
It is a hack but it works. ISOs are about 5GB this way
I think @travier had some thoughts, maybe waiting until composefs-rs and unified storage so we can deduplicate between the live image and the image to be deployed.
As a separate question are these to be live images in the sense that the image (potentially with runtime modifications done by the user) is installed to disk or are they only to run the system and they'll still install the 'clean' container?
Judging by the remark that you're doing things in %post I assume this will be the former?
They install a clean container with a oscontainer --deploy in the interactive-defaults.ks . So the live version has been modified and isn't even an ostree deployment just a normal live-OS with the roots copied over from the bootc image. So we pull the clean image again to be able to deploy it.
Ideally we could layer on the live stuff to the image so we don't need 2 copies but that doesn't seem like it is possible right now, hence the hack
We had a similar problem with Playtron GameOS. We wanted to create an installer but
- we wanted our own branding and our own custom installer, Anaconda is not a good fit for us
- we didn't want to create a whole separate system and build just for an installer -- we wanted to leverage our existing OS container build which already includes all the required drivers etc
- we didn't want to create an ISO from our container and then have to also include a second copy of it to install with bootc tools
I solved this by building a raw disk image with bootc-image-builder with a config that puts our system into "install" mode, and also disables a service to resize the filesystem.
The system boots, detects the install mode flag, and starts the installer. The user selects the target disk, then the installer copies its own disk to the target and then disables install mode and re-enables the filesystem resize service.
This is still experimental. I need to figure out how to boot the installer with some kind of read-only overlay so that the installed system is clean.
This is not really a general solution that could be integrated into bootc-image-builder that I can think of, but is a strategy others could make use of.
Ideally, bootc-image-builder could generate an ISO which boots into a container which can also be deployed without having a second copy of it. I don't think that is possible though.
Ideally, bootc-image-builder could generate an ISO which boots into a container which can also be deployed without having a second copy of it. I don't think that is possible though.
This (or something similar to this) is on our long-term roadmap. We haven't figured out the details yet, but we would like to support this kind of use case eventually.
