When playing with Elemental would it be possible to run it as a Docker container and a mounted volume to play around? Just wondering if someone has tried this.

How does one use

elemental

on a Mac? I am now using the iso image and created a VM with that. I am having some troubles identifying what is need to get a basic scenario going: • Create an initial system • Build a derivative • Update the system with that derivative This to get some understanding on how pieces work together

With elemental in this case

elemental-toolkit

On the website it states that part of elemental is the

elemental-toolkit

and the

elemental-cli

Is my assumption correct that the

elemental-cli

is actually part of the

elemental-toolkit

?

So when i use the toolkit the cli which is used is the

elemental-cli

?

Another question.. • I created a VM using the downloadable ISO from GitHub, would the mentioned docker image contain the same stuff? • And another one.. On the GitHub releases page i can download the 10.6 iso but the 10.7 iso which is released as a Docker image is not there. Is that intentionally?

The naming vanilla image seems to target images like ISO’s but should the Docker container with the same release also be considered as a vanilla image??

I am puzzled by the following statement..

The container image is booted as-is, encapsulating all the needed components (kernel, initrd included) and can be pulled locally for inspection, development and debugging.

• For the image to be booted my assumption is that i first need to have a barebones system with a vanilla image installed? • When a updated image is booted (my assumption using

element install

) Is then the container booted and the result is an upgraded base OS?

Would it be possible to run and elemental teal Docker image that is released and upgrade with a later teal version?

I have created an VM with the 10.6 release. Installed everything and now I want to update my system. My disk is mounted on /dev/sda so i try to execute

elemental install /dev/sda --system.uri <http://quay.io/costoolkit/releases-teal/cos-system-0.10.7|quay.io/costoolkit/releases-teal/cos-system-0.10.7>

It complains that the partitions on /dev/sda are in use.. Guess i am doing something wrong 🙂 (wait.. i missed something.. need to upgrade i guess :))

Is there any preferred way of creating a derivative?

Want to create an image with some stuff added so i can check the upgrade.

Since it’s an OCI image, you can do a docker or Podman build using the teal image as the base image

When an image has been installed using

elemental install / upgrade

is it possible to reinstall the image with for example other cloud-init configs?

I am trying to upgrade using an image that I pushed to a local registry running on a specific port. When trying the upgrade I get the error message that

first path segment in URL cannot contain colon

Is there a way to get arround this? I am executing the following command:

elemental upgrade --system.uri 192.168.68.107:5000/teal-derivate-test

Should have the documentation better 🙂

This one works:

elemental upgrade --system.uri docker:192.168.68.107:5000/teal-derivate-test

If performing an upgrade, my guess is that a reboot is always required reflecting the changes?

How would one be able to influence the disk partitioning that is created when installing a derivative?

Would be great if the repo would contain some recipes that can be consumed by people that are looking for some inspiration

When creating a partition using cloud config on install, how can these partitions be mounted / automounted on next reboot?

Is it possible to create an ISO from a container image that is derived from the official teal image?

What is the difference between General Configuration and the use of Cloud-Init files when installing the image? The feel a bit overlapping but not sure if the feeling is corrent?

Why would you choose the one over the other?

The general feels like a base setup for all derivatives so you can later on customize an install using specific cloud-init files. Is that assumption correct?

Is there any guidance why the cloud init paths differ when reading the documentation? cloud-init files are read and executed in (lexicopgrahic) sequence inside: Taken from: https://rancher.github.io/elemental-toolkit/docs/customizing/configuration_persistency/ - /system/oem - /oem - /usr/local/cloud-config Taken from: https://rancher.github.io/elemental-toolkit/docs/customizing/stages/ - /system/oem - /oem - /usr/local/oem

Bit puzzled on the

/usr/local/cloud-config

and

/usr/local/oem

paths and when i should use the one over the other or even skip them both and only use the

/system/oem

and

/oem

What does this sentence actually mean?

While /system/oem is reserved for system configurations to be included directly in the derivative container image, the /oem folder instead is reserved for persistent cloud-init files that can be extended in runtime.

Especially the meaning of

/oem folder instead is reserved for persistent cloud-init files that can be extended in runtime

?

Is there a recommended Linux distro that already contains Docker Engine that i could use to quickly install elemental derivates using Docker?

Would love to try out installing a derivative using some kind of Rescue or LiveCD.