You want a different desktop without wiping your disk
You installed Fedora Silverblue six months ago. You liked the stability of the immutable base. You got used to Flatpaks for apps and Toolbox for development. Then you tried a friend's laptop running Fedora Sway Atomic. You liked the keyboard-centric workflow. You want that workflow on your machine. You do not want to back up your home directory, reinstall, and restore. You want to switch the base image while keeping your config and apps.
You can rebase your system to a different variant. Fedora Atomic desktops share the same OSTree foundation. Rebasing swaps the root filesystem tree. Your /home directory remains untouched. Layered packages carry over. The process takes two reboots and a few commands.
What's actually happening
OSTree treats the operating system as a single versioned tree. Every file in the root filesystem belongs to the tree. The tree is read-only. You cannot modify files in /usr or /bin. You can only add files via overlays or modify files in /etc and /home.
Variants like Silverblue, Kinoite, Sway Atomic, and Budgie Atomic are distinct trees hosted in the same OCI registry. They share the same kernel, libraries, and core utilities. They differ in the desktop environment and default applications. Rebasing tells the system to download a different tree and boot from it on the next restart.
Think of the base image as a blueprint. Your system builds the house from the blueprint. Rebasing swaps the blueprint for a different one. The foundation stays. The furniture in the rooms stays. The walls change shape.
The rebase process involves two transactions. The first transaction fetches the new tree using the unsigned transport. This step downloads the content and registers the new reference locally. The second transaction rebases to the signed transport. This step pins the deployment to the signed registry path. Future updates will be fetched and verified cryptographically. Skipping the signed rebase leaves the system on an unsigned deployment. Updates may fail or lack verification.
Check layered packages before rebasing. Conflicts stop the transaction.
Rebase to a different variant
Run the commands below to switch variants. Replace kinoite with your target variant and 41 with the Fedora release number. The available variants are silverblue, kinoite, sway-atomic, and budgie-atomic.
Check the current deployment state before making changes.
# Shows active deployment, pending deployments, and layered packages.
# Verify the current ref and ensure no pending transactions block the rebase.
rpm-ostree status
Switch to the target variant using the unsigned transport first. This fetches the new tree without requiring the ref to be pre-registered in the local signed store.
# Rebase to the unsigned image to fetch the new tree and ref.
# The unsigned transport allows fetching without GPG verification during the pull phase.
# Replace kinoite with your target variant and 41 with the release number.
sudo rpm-ostree rebase ostree-unverified-registry:registry.fedoraproject.org/fedora/kinoite:41
Reboot to apply the new deployment and verify the switch. The system boots the unsigned deployment. This lets you test the new variant before pinning it for updates.
# Reboot to apply the new deployment and verify the switch.
# The bootloader switches to the new deployment automatically.
systemctl reboot
After the reboot, pin the system to the signed image for production use. This ensures all future updates are cryptographically verified.
# Rebase to the signed image to enable verified updates for the new variant.
# The signed transport ensures all future updates are cryptographically verified.
# docker:// transport is the standard for signed OCI images in rpm-ostree.
sudo rpm-ostree rebase ostree-image-signed:docker://registry.fedoraproject.org/fedora/kinoite:41
Reboot to finalize the switch to the signed deployment. The system now tracks updates from the signed registry.
# Reboot to complete the transition to the signed deployment.
# Future updates will use the signed transport automatically.
systemctl reboot
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Confirm the system booted the new variant and the deployment list is correct.
# Verify the active deployment points to the new variant and signed image.
# Check the BaseCommit hash and the image name in the output.
rpm-ostree status
The output lists deployments. The top deployment is the active one. Check the BaseCommit and the image name. Ensure it matches the target variant and the signed transport. If the output shows ostree-unverified-registry, the signed rebase did not apply. Run the signed rebase command again.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
Common pitfalls and what the error looks like
Layered packages persist across the rebase. If you installed packages with rpm-ostree install, they remain installed. However, the new base image might include a package that conflicts with a layered package.
For example, Silverblue includes gnome-terminal. Sway Atomic includes foot. If you layered gnome-terminal on Sway, the rebase might fail due to a conflict. The rpm-ostree command will refuse to proceed and print Error: Transaction test error: package gnome-terminal-3.48.0-1.fc41.x86_64 conflicts with gnome-terminal provided by gnome-terminal-3.48.0-2.fc41.x86_64. The conflict is intentional. Read the error before forcing.
Run rpm-ostree status to list layered packages. The output shows a Packages section. Review the list. Remove any package that belongs to the desktop environment you are leaving. Use sudo rpm-ostree uninstall <package> to remove it. Then retry the rebase.
If the new variant breaks your workflow, roll back. rpm-ostree keeps the previous deployment on disk. The system can always return to the exact state before the rebase.
# Roll back to the previous deployment if the new variant fails.
# This restores the old tree and reboots into it.
sudo rpm-ostree rollback
systemctl reboot
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Check /etc/NetworkManager/ for stale configs. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Run journalctl -xe to read the actual error before guessing. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
When to use this vs alternatives
Use Silverblue when you want the standard GNOME desktop with a stable, immutable base. Use Kinoite when you prefer KDE Plasma and need the same immutable guarantees. Use Sway Atomic when you want a tiling window manager and keyboard-driven workflow without manual configuration. Use Budgie Atomic when you want a traditional desktop layout with modern GNOME components. Use Fedora Workstation when you need to install kernel modules or modify system files directly. Stay on your current variant if you only want to change the desktop environment and not the base image.
Trust the package manager. Manual file edits drift, snapshots stay.