All Articles

uncomplicated approach to immutable operating systems

Required experiences to better understand this article

  • Linux Systems
  • Containerization
  • Layered Systems

If you’re familiar with the Linux ecosystem, you’ve probably heard of Immutable OS at least once. Fedora Silverblue is one of the most popular distributions with this infrastructure. Therefore, we will run our sample scenarios on Fedora Silverblue.

Immutable OS

In Immutable OS, the root directory cannot be changed, it has a read-only structure. Every package installed on the system creates a layer that runs isolated from the root directory. Therefore, you can boot between those layers and rollback to any layer very effectively in the system. The purpose of the Immutable system is to keep the host OS clean and stable and helping to avoid the clutter that can happen after installing lots of development tools and packages.

Fedora Silverblue

Fedora Silverblue is an immutable desktop os that delivered images that are created by utilizing the rpm-ostree project. The main benefits of the system are speed, security, atomic updates, and immutability.

Fedora Silverblue provides its users with different options for managing software applications as compared with other package-based Linux distributions.

These options are:

  • rpm-ostree is a hybrid image/package system. It combines libostree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project; specifically libdnf. and thus bringing many of the benefits of both together.
  • flatpak is a utility for software deployment and package management for Linux. It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.
  • toolbox is a project to make containers easily consumable for regular users. It does that by using podman’s rootless containers. Toolbox lets you easily and quickly create a container with a regular Fedora installation that you can play with or develop on, separated from your OS.

For example, if we are going to install a GUI application, our first choice is Flatpak. Because the nature of flatpak comes with an infrastructure compatible with the logic of SilverBlue. If the application is not available on flatpak, it can be installed with rpm-ostree (this is the method to be preferred last) or the application can be run by installing the package in the toolbox container and connecting alias to the container.

rpm-ostree in action

In a system with Fedora Silverblue installed, we will install a dropdown terminal package named guake with rpm-ostree. Let’s check our current ostree status before the installation step.

As seen in the screenshot, one of the layers has htop, zsh and the other one has snapd as an extra package installed. In this case, you can boot the operating system either with or without snapd loaded.

Now let’s run rpm-ostree install guake to install the guake.

After the installation process is finished, we need to restart the system with the new ostree layer. Otherwise, we cannot access the guake package. We mentioned that rpm-ostree keeps packages layer by layer, so we need to boot the system at the last layer for each new package.

When booting the system, we will see a screen like this:

Here, when we boot with the top layer, we will be able to access the guake application on our system. The latest added layer is the top layer. If we want to boot without guake, we will need to boot the system with the second option.

toolbox in action

First of all, we need to know that the toolbox is a very different system from rpm-ostree. Toolbox is a container-isolated, manually managed infrastructure, while rpm-ostree is a system that works with a git-like infrastructure. With Toolbox you can open a single container environment for all packages, or you can open a separate container environment for each package.

In addition, the package manager will be able to work in the environments we open with the toolbox. In our example, we will create a special environment for dotnet and then install dotnet using DNF in it. And as the last step, we will access the package we have installed from outside the container, ie from the host OS.

First of all, what we need to do is create a container environment.

After creating our container environment, let’s get inside our environment to do operational processes.

As we mentioned above, we can use the package manager in toolbox environments. We can see this by running the command dnf —version

Now we can run the command sudo dnf install dotnet-sdk-5.0 to install the dotnet framework.

After the installation is complete, we will be able to access the dotnet framework via the CLI in the container environment. However, it is unfortunately not possible to do the same use directly from the Host OS.

Let’s try to use dotnet CLI from inside / outside of the container environment and see the result.

From inside of the container environment

From Host OS

To run the dotnet command without entering the environment, we need to use a toolbox command such as toolbox run —container dotnet-environment dotnet . But that wouldn’t be very useful, would it? If we want to use dotnet in our system like its installed in the system, then we need to define the command above as an alias.

Add the line below to the inside of the ~/.bashrc

dotnet='toolbox run --container dotnet-environment dotnet'

It will now be possible to use the dotnet CLI directly from the Host OS.

As I mentioned in the title of the article, I have tried to illustrate the logic of Immutable systems without confusing things. I hope it has been useful, thank you for giving a time!