This message was deleted.

@sticky-tailor-45974 I saw you were thinking about similar approach. The argument back then was: Not to bundle dependencies into the OS. Anyways since xorriso aso. are requirements for elemental-toolkit (elemental-cli, whatever) to function properly they should be installed anyways, or (better?!?) elemental-cli get's split in multiple tools (one for init, one for install/update/... and one for building iso's)

SLEMicro uses transactional-update which calls zypper under the hood

Hi @enough-animal-77820! Great to see such a detailed post! I have some questions:

Indeed @enough-animal-77820 thanks for such a detailed post. Few details are coming to my mind. In fact your suggestion was also adopted internally for building our ISOs 1. Xorriso is already part of current elemental-teal, hence the ISO can be built using elemental-teal itself. In fact this is what we are currently doing in

rancher/elemental/.obs/dockerfile/teal-iso/Dockerfile

. The outcome of this image can be directly be referenced in a ManagedOSVersion for ISO generation within the UI. 2. I assume the above solves the problem of keeping elemental-toolkit versions in sync 3. As @witty-table-40840 said there are some of this Dockerfiles that are about to be deprecated, we are just pending few updates on our CI to get rid of this Dockerfiles as we are not using them in our internal pipelines and this is a source of confusions.

@witty-table-40840 ad deprecation: Oh, aha, that makes me curious 🙂 ad "keep in sync": That is no hard requirement, but I assumed it prevents possible headache in the future (e.g. a possible dependency between init/build/install commands within the toolkit) Not that I am aware of such, but all versioning I don't have to keep in sync myself is better than the other way round. ad image of elemental-cli: That indeed solves the problem not to have to build our own builder-image for the ci pipeline! In that case we build and push the os-image beforehand and then use it to bootstrap

elemental build-iso <oci://our-registry>

For local development we just build the os-image, but don't push it to a registry. Thus, we cannot access it with oci://. Currently this is no problem since we bootrap

elemental build-iso dir:/

to specify the rootfs in such scenarios. This won't be possible when using a dedicated elemental-cli container. A workaround could be to mount /var/run/docker.sock and use docker:/ which I wouldn't like to do, or to save the prebuilt image as tar.gz and use file:/ (did not test this one - just an assumption) Any recommendations?

1. yes, xorriso is here to stay! 2. what image are you using as base? is it one from registry.suse.com?

Currently I am testing with: registry.opensuse.org/isv/rancher/elemental/dev/containers/rancher/elemental-teal/5.4:latest ...for prod we will stick to the stable releases of course 🙂

save the prebuilt image as tar.gz and use file:/ (did not test this one - just an assumption)

Yes, this will not work, file is for filesystem image files (e.g. an ext4 image that includes the root-tree). We probably could consider supporting something like or

docker-archive

in the spirit of what tools like skopeo already do. However we haven't found the need neither the demand so far. 2. yes basing your derivates on elemental-teal (pulled from registry.suse.com/rancher/elemental-teal/5.4) is the way to go.

Great! - If

xorriso

is here to stay in

elemental-teal

no need for

docker-archive

support is needed on our side. Then just let me know if such approach: https://github.com/rancher/elemental/commit/eda1de3365cad87cbbb6c716b57b67ff266b42b6 would be beneficial for upstream as well? (after deprecation of old Dockerfiles aso.)? Would be happy to contribute, to keep our build pipeline as close to upstram as possible.