You cannot toggle the OS type from the terminal
You boot into Fedora Workstation, open the terminal, and type dnf install silverblue expecting a seamless transition. The package manager immediately refuses. You check GNOME Settings for a switch. Nothing. You are not missing a hidden flag. Fedora Workstation and Fedora Silverblue are fundamentally different installation profiles. They share the same kernel, the same GNOME desktop, and the same upstream repositories, but they manage the root filesystem in completely opposite ways. Switching between them requires a clean installation.
What is actually happening under the hood
Workstation treats your root filesystem as mutable. You install packages, modify configuration files in /etc/, and dnf tracks every change. The system evolves in place. Silverblue treats the root filesystem as immutable. The base image is a read-only transactional layer managed by rpm-ostree. You do not install packages directly onto the base. You add layers on top, or you run applications inside containers. When an update arrives, rpm-ostree downloads a completely new bootable image, adds it to the GRUB menu, and leaves the old one intact until you reboot.
Think of Workstation like a house where you can knock down walls and repaint rooms whenever you want. Silverblue is a house built from prefabricated modules. You can decorate the interior and add furniture, but the structural walls are sealed. If you want to change the foundation, you have to build a new house and move your furniture over.
The package managers enforce this split. dnf expects to write directly to /usr/ and /etc/. rpm-ostree expects a read-only base and merges user layers at boot time. Forcing one onto the other breaks the boot process. The system will not let you cross the line without a fresh start.
Convention aside: dnf upgrade --refresh is the normal weekly maintenance command on Workstation. rpm-ostree upgrade is the equivalent on Silverblue. They are different commands with different transaction models. Do not run dnf upgrade on an immutable base. It will corrupt the deployment.
The clean migration workflow
Prepare a backup before you touch the disk. A clean install wipes the target partition. Use tar or rsync to copy your home directory, configuration files, and any custom scripts to an external drive or a separate partition.
# Create a compressed archive of your home directory
# Exclude hidden cache directories to save space and time
# The --one-file-system flag prevents crossing into mounted volumes
tar -czpf ~/fedora-home-backup.tar.gz --one-file-system \
--exclude='.cache' --exclude='.local/share/Trash' \
/home/$USER
# Copy the archive to an external drive mounted at /mnt/backup
cp ~/fedora-home-backup.tar.gz /mnt/backup/
Download the Fedora Silverblue ISO from the official site. Write it to a USB drive using dd or Fedora Media Writer. The ISO contains the Anaconda installer configured for an immutable base.
Boot from the USB drive. Select "Install to Hard Drive" during the live session. The installer will detect your existing Fedora installation. Choose the target disk and let Anaconda format the root partition. Do not attempt to preserve the existing /boot or /etc directories. Mixing mutable and immutable configurations causes immediate boot failures.
Complete the installation. Reboot into the new Silverblue system. Log in and verify the network connection. Restore your data from the backup archive.
# Mount the external drive containing your backup
sudo mount /dev/sdb1 /mnt/backup
# Extract the home directory archive to your new home folder
# The --keep-old-files flag prevents overwriting existing dotfiles
# This preserves default Silverblue configurations where they differ
tar -xzpf /mnt/backup/fedora-home-backup.tar.gz --keep-old-files -C /
Reboot before you debug. Half the time the symptom is gone.
Verify the immutable base
Open a terminal and check the bootable deployments. rpm-ostree will show the current version and the pinned state.
# List all available bootable deployments
# The asterisk marks the currently running version
# Verify the commit hash matches the expected release
rpm-ostree status
The output will display a State: Idle line and a Deployments: section. Verify that the root filesystem is mounted as read-only.
# Check mount options for the root filesystem
# Look for 'ro' in the output to confirm immutability
# If you see 'rw', the base image failed to remount correctly
findmnt -n -o OPTIONS /
Run journalctl -xe to review the boot log. The system should show ostree-remount.service completing successfully. This service remounts the root partition as read-only after the initial boot. If it fails, your configuration files from the old Workstation install are conflicting with the immutable base.
Convention aside: journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Use it here to isolate ostree-remount.service if the boot hangs.
Common pitfalls and exact error messages
Users often try to force dnf to install packages on Silverblue. The transaction will abort immediately.
Error: Transaction test error:
package glibc-2.38-4.fc40.x86_64 conflicts with glibc provided by rpm-ostree
The conflict is intentional. rpm-ostree owns the base packages. dnf cannot overwrite them. Use rpm-ostree install or toolbox/distrobox instead.
Another common mistake is copying the old /etc/ directory over the new one. Silverblue expects a clean /etc/ that gets merged with the base image at boot. Overwriting it breaks the merge process. You will see ostree-remount.service fail and the system will drop into an emergency shell.
[FAILED] Failed to start Remount Root and Kernel File Systems.
See 'systemctl status ostree-remount.service' for details.
The fix is to boot the previous deployment from the GRUB menu, remove the conflicting files, and try again. Never edit files in /usr/lib/. Those files ship with the base image. Edit /etc/ only.
If you accidentally format the wrong partition during the clean install, your data is gone. The installer does not ask for a second confirmation when you select "Custom" partitioning. Always verify the disk identifier before clicking "Begin Installation".
Convention aside: SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A fresh Silverblue install enforces strict context labeling on /etc/ merges. If you copied files with wrong contexts, restorecon -Rv /etc/ fixes it.
When to use this approach versus alternatives
Use Fedora Workstation when you need direct access to the mutable root filesystem and want to install packages system-wide with dnf. Use Fedora Silverblue when you want a known-good base image you can always roll back to and prefer running applications in containers. Use Distrobox when you need a mutable environment for development without leaving the immutable host. Stay on Workstation if you only deviate from the defaults occasionally and do not need transactional updates.
Trust the package manager. Manual file edits drift, snapshots stay.