You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 7, 2024. It is now read-only.
I am trying to create offline installers for Ublue ISOs which are based on ostree containers. I was able to use lorax to get things to work and I lightly modified lorax-configure-repo.tmpl and lorax-embed-repo.tmpl to pack up a container image in oci-archive format as /container.tar.gz and to add ostreecontainer --url /container.tar.gz --transport oci-archive to the kickstart file.
Doing these steps I was able to succeed and create an installer for Ublue using ostree containers, however there is a problem in the resulting system: rpm-ostree is set to track updates at /container.tar.gz so the system doesn't get any updates.
I tried tracking down the origin of ostreecontainer and ostreesetup in anaconda/kickstart and found this:
No, the default images would be embedded in the ISO as e.g. oci: directories, the same way we embed ostree repositories.
so it looks like the intended usage is kinda similar to what I am doing. I just want to double check if there's a better way.
Currently the booted system ends up with this:
my lorax templates:
lorax-configure-repo.tmpl
## Lorax template to configure Anaconda to:
## 1) Use the repository we embedded in the ISO
## 2) Work around https://bugzilla.redhat.com/show_bug.cgi?id=1193590
## 3) Tell anaconda to leave the firewall set up as it was in the ostree
## Args:
## - ostree_osname - the name of the os/name of remote
## - ostree_oci_ref - the REFSPEC of the OCI image to use
<%page args="ostree_osname, ostree_oci_ref"/>
# If this is in the rootfs of the installroot then ostree fails with "not enough space"
append etc/fstab "tmpfs /var/tmp tmpfs defaults 0 0"
append usr/share/anaconda/interactive-defaults.ks "ostreecontainer --no-signature-verification --transport oci-archive --stateroot=${ostree_osname} --url=/container.tar.gz"
append usr/share/anaconda/interactive-defaults.ks "firewall --use-system-defaults"
append usr/share/anaconda/interactive-defaults.ks "%post --erroronfail"
append usr/share/anaconda/interactive-defaults.ks "rpm-ostree rebase ostree-image-signed:${ostree_oci_ref}"
%if ostree_osname != "fedora":
append usr/share/anaconda/interactive-defaults.ks "rm -f /etc/ostree/remotes.d/${ostree_osname}.conf"
%endif
append usr/share/anaconda/interactive-defaults.ks "cp /etc/skel/.bash* /root"
append usr/share/anaconda/interactive-defaults.ks "%end"
and lorax-embed-repo.tmpl
## Lorax template to embed an OSTree repository into the installer.iso
## and configure an interactive installer use to look for it.
##
## Note that we pull with depth=0 to only get *one* commit into the
## ISO, because we obviously don't want the full history.
## Args:
## - root - the root directory of the iso tree
## - ostree_osname - the name of the os/name of remote
## - ostree_oci_ref - the REFSPEC for the OCI image to install
<%page args="root, ostree_osname, ostree_oci_ref"/>
runcmd mkdir ${root}/ostree
runcmd ostree --repo=${root}/ostree/repo init --mode=bare
runcmd bash -c 'skopeo copy ${ostree_oci_ref} oci-archive:${root}/container.tar.gz'
The text was updated successfully, but these errors were encountered:
and then using ostreesetup in the kickstart file and manually passing the ref that corresponds with the container image but then I got a VM with a faulty remote anyway - not sure if there's a remote value i could use?
seems to me that the way to do this would be to do ostree container image deploy with a specific --target-imgref but at the time of this writing kickstart command ostreecontainer does not allow to specify a --target-imgref. At first glance it would seem the support needs to be added to anaconda.
I tried to call ostree container image deploy --imgref /var/ublue-os/image --transport oci --target-imgref ghcr.io/ublue-os/silverblue-main:latest --sysroot /mnt/sysroot from %post --nochroot and that results in an error when modifying the grub configuration(It's not clear why this happens).
Hi yes, indeed it makes sense to streamline this more on the Anaconda side. This is a highly complex topic; one thing I've been trying to do is shift the "center of gravity" to bootc install. Though, that doesn't itself solve the problem of making Live ISOs, it boils the problem down to:
Embedding the container image in the ISO
Running bootc install from it, while using --target-imgref to point to the expected registry
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
I am trying to create offline installers for Ublue ISOs which are based on ostree containers. I was able to use lorax to get things to work and I lightly modified
lorax-configure-repo.tmpl
andlorax-embed-repo.tmpl
to pack up a container image inoci-archive
format as/container.tar.gz
and to addostreecontainer --url /container.tar.gz --transport oci-archive
to the kickstart file.Doing these steps I was able to succeed and create an installer for Ublue using ostree containers, however there is a problem in the resulting system:
rpm-ostree
is set to track updates at/container.tar.gz
so the system doesn't get any updates.I tried tracking down the origin of
ostreecontainer
andostreesetup
in anaconda/kickstart and found this:source BZ#2125655
so it looks like the intended usage is kinda similar to what I am doing. I just want to double check if there's a better way.
Currently the booted system ends up with this:
my lorax templates:
lorax-configure-repo.tmpl
and
lorax-embed-repo.tmpl
The text was updated successfully, but these errors were encountered: