bootc-base-images/docs/install.md

nav_order
2

Trying out development builds

No default user accounts

The default images produced do not include any default passwords or SSH keys. There is a root user present, but its password is locked.

Using fedora-bootc-cloud via KVM

Many people who just want to "try things out" will find it easiest to start with the cloud image.

Installation using Anaconda

Tools like Anaconda support injecting configuration at image installation time, such as SSH keys and passwords. This means that in contrast to what was said just before, it's possible to directly install (and update from) an "unconfigured base image" provided by this project.

This hinges on the ostreecontainer kickstart verb, which is new in Fedora 38; for example, there is a netinst.iso which can be scripted with kickstart. Because a current development target for this project is Fedora ELN, it's also supported to use the ISO generated by that project.

See example.ks for an example Kickstart file. The virt-install --initrd-inject helps inject kickstart for installation to virtual machines.

Using bootc install-to-filesystem --replace=alongside with a cloud image

A toplevel goal of this project is that the "source of truth" for Linux operating system management is a container image registry - as opposed to e.g. a set of qcow2 OpenStack images or AMIs, etc. You should not need to maintain infrastructure to e.g. manage garbage collection or versioning of cloud (IaaS) VM images.

The latest releases of bootc have support for bootc install-to-filesystem --replace=alongside. More about this core mechanic in the bootc install docs.

Here's an example set of steps to execute; this could be done via e.g. cloud-init configuration.

dnf -y install podman skopeo
podman run --rm --privileged --pid=host -v /:/target --security-opt label=type:unconfined_t <yourimage> bootc install-to-filesystem --target-no-signature-verification --karg=console=ttyS0,115200n8 --replace=alongside /target
reboot

Rebasing from Fedora CoreOS

Fedora CoreOS supports many different platforms, and can be used as a starting point to "rebase" to a custom derived image from CentOS boot.

systemctl mask --now zincati && rm -vf /run/ostree/staged-deployment-locked
echo "# dummy change" >> "/etc/sudoers.d/coreos-sudo-group"
rpm-ostree rebase ostree-unverified-registry:quay.io/centos-bootc/fedora-bootc:eln
systemctl reboot

TODO: Use osbuild

Document the ongoing work to materialize a disk image from a container.