You installed Fedora Workstation for six months
You liked the terminal. You got comfortable with dnf. You learned which flags matter and which ones do not. Then you tried a major desktop environment tweak or a kernel update, and the system refused to boot. You spent an evening rebuilding GRUB, chasing dependency conflicts, and wondering why a simple upgrade broke your workflow. You want a desktop that stays stable across updates, but you still want KDE Plasma's widgets, window rules, and system settings. That is exactly why Fedora Kinoite exists.
What is actually happening under the hood
Traditional Fedora Workstation modifies the root filesystem directly. Every dnf install or dnf upgrade changes files in /usr and /etc. If a package breaks, the system breaks until you fix it. Kinoite treats the root filesystem as read-only. It uses rpm-ostree to compose entire system images. When you request an update, the tool downloads a complete new system state, verifies cryptographic signatures, and writes it to a separate boot entry. Your computer boots into the new state only after you reboot. If the new state fails, you select the previous boot entry in GRUB and you are back to work.
Think of it like version control for your operating system. You commit changes, you test them, and you can always revert to the last known good commit. The base image never mutates. User configurations live in /etc, which remains writable. Desktop applications run in Flatpak containers by default. System packages are layered on top of the base image through a transactional queue. The model eliminates dependency drift and guarantees that every reboot lands on a verified state.
How to install packages and apply updates
You will not use dnf for system packages anymore. rpm-ostree replaces it. The workflow changes from install-and-run to layer-reboot-and-run. Here is how to install a package that is not already in the base image.
sudo rpm-ostree install htop # layers the package on top of the immutable base
# rpm-ostree queues the change. It does not apply it immediately.
# The system requires a reboot to commit the new boot entry.
After the command finishes, you will see a message telling you to reboot. Do not skip the reboot. The package exists in the staging area until the system restarts. Run sudo reboot to apply the change.
System updates work the same way. You do not run dnf upgrade. You run the transactional equivalent.
sudo rpm-ostree upgrade # downloads the latest stable image for your release
# rpm-ostree verifies checksums and prepares the new boot entry.
# No files are modified on disk until you reboot.
Reboot to complete the update. The GRUB menu will show two entries. The top entry is the new system state. The second entry is your previous state. Boot into the top entry. If something breaks, reboot and select the second entry. The system rolls back instantly.
Configuration files behave differently on immutable variants. Files in /usr/lib ship with the package and are read-only. Files in /etc are user-modified and persist across updates. When a package provides a default configuration, rpm-ostree copies it to /etc on first install. Edit /etc. Never edit /usr/lib. If you need to reset a configuration to the upstream default, remove the file from /etc and reboot. The next boot will repopulate it from the base image.
Verify the system state
Check the current boot state and the pending transaction.
rpm-ostree status # shows the current commit hash and deployed versions
# The output lists Deployments. The top entry is your active system.
# Any pending changes appear under Pending.
If you see your package listed under the active deployment and the commit hash matches the latest stable release, the system is synchronized. Run journalctl -xeu rpm-ostree to confirm the last transaction completed without warnings. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type this muscle-memory style. Read the actual error before guessing.
You can also inspect which packages are layered versus which are part of the base image.
rpm-ostree pkg list # prints every package currently layered on top of the base
# Layered packages survive rollbacks. Base packages do not.
# Keep this list short. Every layer increases boot time and update size.
If you need to remove a layered package, use the standard removal command and reboot.
sudo rpm-ostree uninstall htop # removes the package from the staging tree
# The change is queued. Reboot to apply the removal.
# rpm-ostree does not delete files until the new boot entry activates.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and error messages
Users coming from Workstation expect dnf to work. It will not. If you run sudo dnf install vim, the transaction fails with a read-only filesystem error. The package manager refuses to write to /usr/lib or /usr/bin. Those directories belong to the immutable base image. You must use rpm-ostree install instead.
Another common issue is mixing container tools with system tools. Kinoite is designed for Flatpak and Podman. If you try to compile software from source and it fails with Permission denied: '/usr/local/bin', you are hitting the read-only root again. Install build tools via rpm-ostree, then compile into ~/.local/bin or use a container. Do not force sudo make install into system directories. It breaks the transactional model and leaves you with untracked files that survive rollbacks.
You might also see this during an update:
error: Transaction test error: package kernel-core-6.8.5 conflicts with kernel-core-6.8.4
The conflict is intentional. rpm-ostree keeps multiple kernel versions in the boot tree. It does not remove old kernels automatically. Run sudo rpm-ostree cleanup -m to prune unused kernels and free disk space. Fedora's release cadence is six months. The N-2 release goes end-of-life when N+1 ships. Plan upgrades on that cycle. Do not let old kernels fill your EFI partition.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Immutable variants rely on strict security contexts. Disabling the policy breaks the container isolation model and exposes your user directories to unnecessary risk. Trust the package manager. Manual file edits drift, snapshots stay.
When to choose Kinoite over other variants
Use Kinoite when you want a known-good KDE Plasma desktop that survives major updates without dependency hell. Use Silverblue when you prefer GNOME and want the same transactional safety. Use Workstation when you need to install kernel modules, low-level driver patches, or packages that require direct filesystem modification. Stay on the upstream Workstation if you only deviate from the defaults occasionally and prefer dnf muscle memory.