// Module included in the following assemblies:
//
// * architecture/architecture-rhcos.adoc

:_mod-docs-content-type: CONCEPT
[id="rhcos-key-features_{context}"]
= Key {op-system} features

[role="_abstract"]
Before you use {op-system-first}, understand key features so that you can use {op-system} to meet your needs.

The following list describes key features of the {op-system} operating system:

* **Based on {op-system-base}**: The underlying operating system consists primarily of {op-system-base} components. The same quality, security, and control measures that support {op-system-base} also support {op-system}. For example, {op-system} software is in RPM packages, and each {op-system} system starts up with a {op-system-base} kernel and a set of services that are managed by the systemd init system.

* **Controlled immutability**: Although it contains {op-system-base} components, {op-system} is designed to be managed more tightly than a default {op-system-base} installation. Management is performed remotely from the {product-title} cluster. When you set up your {op-system} machines, you can modify only a few system settings. This controlled immutability allows {product-title} to store the latest state of {op-system} systems in the cluster so it is always able to create additional machines and perform updates based on the latest {op-system} configurations.

* **CRI-O container runtime**: Although {op-system} contains features for running the OCI- and libcontainer-formatted containers that Docker requires, it incorporates the CRI-O container engine instead of the Docker container engine. By focusing on features needed by Kubernetes platforms, such as {product-title}, CRI-O can offer specific compatibility with different Kubernetes versions. CRI-O also offers a smaller footprint and reduced attack surface than is possible with container engines that offer a larger feature set. Currently, CRI-O is the only engine available within {product-title} clusters.
+
CRI-O can use either the `crun` or `runC` container runtime to start and manage containers. `crun` is the default. For information about how to enable `runC`, see the documentation for creating a `ContainerRuntimeConfig` CR.

* **Set of container tools**: For tasks such as building, copying, and otherwise managing containers, {op-system} replaces the Docker CLI tool with a compatible set of container tools. The podman CLI tool supports many container runtime features, such as running, starting, stopping, listing, and removing containers and container images. The `skopeo` CLI tool can copy, authenticate, and sign images. You can use the `crictl` CLI tool to work with containers and pods from the CRI-O container engine. While direct use of these tools in {op-system} is discouraged, you can use them for debugging purposes.

* **rpm-ostree upgrades**: {op-system} features transactional upgrades using the `rpm-ostree` system. Updates are delivered by means of container images and are part of the {product-title} update process. When deployed, the container image is pulled, extracted, and written to disk, then the boot loader is modified to boot into the new version. The machine reboots into the update in a rolling manner to ensure cluster capacity is minimally impacted.

* **bootupd firmware and boot loader updater**: Package managers and hybrid systems such as `rpm-ostree` do not update the firmware or the boot loader. With `bootupd`, {op-system} users have access to a cross-distribution, system-agnostic update tool that manages firmware and boot updates in UEFI and legacy BIOS boot modes that run on modern architectures, such as x86_64, ppc64le, and aarch64.
+
For information about how to install `bootupd`, see the documentation for _Updating the bootloader using bootupd_.

* **Updated through the Machine Config Operator**: In {product-title}, the Machine Config Operator handles operating system upgrades. Instead of upgrading individual packages, as is done with `yum` upgrades, `rpm-ostree` delivers upgrades of the OS as an atomic unit. The new OS deployment is staged during upgrades and goes into effect on the next reboot. If something goes wrong with the upgrade, a single rollback and reboot returns the system to the previous state. {op-system} upgrades in {product-title} are performed during cluster updates.

For {op-system} systems, the layout of the `rpm-ostree` file system has the following characteristics:

* `/usr` is where the operating system binaries and libraries are stored and is read-only. Red Hat does not support altering this.
* `/etc`, `/boot`, `/var` are writable on the system but only intended to be altered by the Machine Config Operator.
* `/var/lib/containers` is the graph storage location for storing container images.
