You upgraded, rebooted, and now the boot menu has two entries
You just finished a long session, ran your weekly update, and rebooted. The system comes back, but the boot menu shows two identical Fedora entries and you are not sure which one is safe. Or perhaps you tried to install a new driver, ran a command that worked for years on Workstation, and now the terminal screams about a read-only filesystem. You hear about "immutable" desktops and assume they mean you can never change anything. That is not true. It means the system protects itself so you do not have to babysit it.
Kinoite gives you the KDE Plasma desktop with an atomic update model. The operating system is stored as a versioned image. Updates are all-or-nothing. If an update breaks your system, you boot into the previous version in seconds. You get the stability of a container with the flexibility of a desktop, provided you use the right tools for the job.
How the immutable model protects your system
On standard Fedora Workstation, the root filesystem is a mutable collection of files. When you run dnf upgrade, the package manager downloads RPMs, extracts them, overwrites existing files, and updates configuration. If the power cuts out halfway through, or a package conflicts, you can end up with a half-upgraded system that refuses to boot. Recovery requires a live USB and manual intervention.
Kinoite works differently. The root filesystem is mounted read-only. The entire operating system is stored as a single versioned image, similar to how a Docker image contains everything needed to run a container. When you update, the system downloads the new image, verifies its signature, and places it alongside the current one. On reboot, the bootloader switches to the new image. If the new image fails to load, the bootloader falls back to the previous one automatically. You never get a half-upgraded state. The OS is either fully on version N or fully on version N+1. There is no middle ground.
This model eliminates configuration drift. Every Kinoite installation at the same version has an identical base OS. You can reproduce the environment on another machine without worrying about which package was installed last Tuesday. The system also prevents accidental deletion of critical files. You cannot rm /usr/lib/systemd/systemd because the filesystem rejects the write.
Reboot to activate. The update sits idle until you restart.
Managing updates with rpm-ostree
You will notice dnf behaves differently here. Running dnf upgrade on Kinoite will not update the system. The command exists for compatibility, but it does nothing useful. The system update tool is rpm-ostree. This is the convention across all Fedora Atomic desktops. rpm-ostree manages the immutable base. dnf manages the mutable layers you add on top, though you should rarely use dnf for host packages.
Here is how to check the current state of your deployments and apply an update.
rpm-ostree status
# Shows current deployment, pending updates, and rollback targets.
# Look for "Deployments" to see which version is booted and which are available.
# The asterisk (*) marks the currently running version.
rpm-ostree upgrade
# Downloads the new OS image and stages it for the next boot.
# This does not change the running system. Reboot is required to activate the update.
# The command verifies GPG signatures before writing the image to disk.
If an update causes issues, you can roll back immediately. The previous deployment is preserved automatically.
rpm-ostree rollback
# Marks the previous deployment as the default for the next boot.
# This does not delete the current deployment. It simply changes the boot order.
# Run this before rebooting if you suspect the current version is unstable.
Check the version number. Do not assume the reboot succeeded just because the desktop loaded.
Installing applications without breaking the host
You cannot install RPMs directly onto the root filesystem in the traditional way. Attempting to run sudo dnf install package-name will fail with a transaction error because the root is read-only. Instead, you use Flatpak for desktop applications. Flatpak apps run in their own sandbox and do not touch the host system. This keeps the base OS clean and prevents dependency conflicts.
Here is how to set up Flathub and install a desktop application.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# Adds the Flathub repository if it is not already present.
# Flathub contains the vast majority of desktop applications available for Fedora.
# The --if-not-exists flag prevents errors if you run this command multiple times.
flatpak install flathub org.kde.kdenlive
# Downloads and installs Kdenlive from Flathub.
# The application runs in a sandbox with access to your home directory and display server.
# Permissions are managed by the Flatpak portal system, not by host file permissions.
Flatpak handles updates independently of the OS. You can update apps without rebooting. The sandbox ensures that an app cannot accidentally overwrite a system library or break another application.
Trust the sandbox. If an app needs root access, it probably should not be installed.
Using Toolbox for development and CLI tools
For development tools and command-line utilities that do not have Flatpak versions, use Toolbox. Toolbox creates a mutable container environment based on the current Fedora release. The container shares your user ID and home directory with the host. You can install any RPM inside the container using standard dnf commands.
Here is how to create and enter a toolbox container.
toolbox create
# Creates a mutable container based on the current Fedora release.
# This container shares your user ID and home directory with the host.
# You can install any RPM inside this container using standard dnf commands.
toolbox enter
# Drops you into a shell inside the toolbox container.
# Use this environment for development, compiling code, or installing CLI tools that lack Flatpak versions.
# Changes here do not affect the host system.
Toolbox containers are ephemeral. If you delete the container, you lose the installed packages, but your home directory files remain safe. This makes Toolbox ideal for experimenting with tools or setting up isolated development environments without polluting the host.
Edit in /etc. Changes in /usr/lib vanish on update.
Layering RPMs: the last resort
There is a third path: layering. You can run rpm-ostree install package-name to add an RPM to the host image. This is useful for kernel modules, proprietary drivers, or system-level tools that must run on the host and cannot be containerized. However, layering introduces complexity. Layered packages are included in every future update. If a layered package conflicts with a new version of the base OS, the update will fail until you remove the layer.
Here is how to layer a package, and why you should hesitate before doing so.
rpm-ostree install vim-enhanced
# Layers the vim-enhanced package onto the host image.
# The package becomes part of the OS and persists across updates.
# This breaks the guarantee that your system is identical to the official image.
rpm-ostree uninstall vim-enhanced
# Removes the layered package from the host image.
# You must reboot for the removal to take effect.
# Use this to clean up layers that are no longer needed or causing conflicts.
Layering makes rollbacks harder. When you roll back, the layered packages are applied to the old base image. If the old base conflicts with the layer, the rollback may fail. Use layering only when Flatpak and Toolbox cannot solve the problem.
Free space before upgrading. A full disk breaks the atomic update chain.
Common pitfalls and error messages
You will encounter specific errors if you try to treat Kinoite like Workstation.
The sudo dnf install command will refuse to proceed and print Error: Transaction test error: package ... conflicts with ... or Read-only file system. The conflict is intentional. The root filesystem is immutable. Switch to Flatpak or Toolbox.
If you see No space left on device during an upgrade, your disk is too full to stage the new image. Atomic updates require extra space to write the new image alongside the current one. Clean up old deployments to free space.
rpm-ostree cleanup --deployments
# Removes old deployments to free disk space.
# Keep at least two deployments for safe rollback capability.
# Run this if you see "No space left on device" during an upgrade.
If rpm-ostree upgrade fails with a GPG signature error, your package metadata may be corrupted. Refresh the metadata cache.
rpm-ostree upgrade --refresh
# Forces a refresh of the repository metadata before upgrading.
# This resolves issues where the local cache is stale or corrupted.
# Use this if the upgrade fails with signature verification errors.
Run journalctl -xe first. Read the actual error before guessing.
Choosing the right Fedora variant
Use Kinoite when you want the KDE Plasma desktop with an immutable base that protects against configuration drift. Use Silverblue when you prefer GNOME and want the same atomic update model and rollback safety. Use Workstation when you need to install kernel modules, low-level drivers, or system packages directly onto the host without layering. Use Server when you are running headless services and do not need a desktop environment. Stay on Workstation if you frequently modify system libraries or rely on software that does not have a Flatpak or container alternative.