You upgraded and broke the boot
You ran a system update on Fedora Workstation and the reboot stopped at a black screen. A kernel update dropped support for your proprietary GPU driver, or a library conflict left systemd unable to mount your home directory. You're staring at a login prompt that won't accept your password, or a GRUB menu that offers no way back. You want a system where you can test a change, see it fail, and instantly revert to the exact state you had five minutes ago. That's the promise of Fedora Silverblue.
The immutable model explained
Silverblue isn't a different desktop theme or a collection of pre-installed apps. It changes how the operating system manages its own files. Standard Fedora Workstation is mutable. When you run dnf upgrade, the package manager downloads files, deletes old ones, and writes new ones to disk. If the power cuts out or a dependency conflicts, the filesystem ends up with a mix of old and new files. The system breaks.
Silverblue uses rpm-ostree. The base OS is an immutable tree. You never modify the root filesystem in place. Instead, every update creates a new, complete snapshot of the system. When you reboot, the bootloader switches to the new snapshot. If the new snapshot fails, you boot back into the old one. The old system remains untouched and perfectly functional.
The underlying technology is ostree. Ostree stores files by their content hash. If two deployments share the same version of glibc, the file exists only once on disk. This saves space and makes updates fast. rpm-ostree sits on top of ostree. It translates RPM transactions into ostree commits. When you request an update, rpm-ostree calculates the new tree, downloads only the changed content, and creates a new commit. The bootloader configuration is updated to point to the new commit. This architecture ensures that the system state is always consistent. There is no partial update.
Think of it like version control for your entire OS. You commit a change, reboot to test, and if the commit is bad, you reset to the previous version. The rollback is atomic. You don't need to restore from a backup. The backup is already there, ready to boot.
Check rpm-ostree status before you reboot. If the deployment list is empty, you have no rollback safety.
Download and verify the image
Here's how to fetch the ISO from the official mirror and verify its integrity.
# Fetch the ISO from the official mirror. The URL redirects to the nearest mirror.
curl -O https://download.fedoraproject.org/pub/fedora/linux/releases/41/Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-41.iso
# Verify the checksum. Never trust a download without checking the hash.
# Compare the output against the CHECKSUM file on the download page.
sha256sum Fedora-Silverblue-ostree-x86_64-41.iso
Write the ISO to USB
Here's how to write the image to a USB drive using dd.
# List block devices to identify your USB drive. Look for the size that matches your stick.
lsblk
# Write the ISO to the USB device. Replace /dev/sdX with your actual device node.
# oflag=sync ensures data is written before the command returns, preventing corruption.
sudo dd if=Fedora-Silverblue-ostree-x86_64-41.iso of=/dev/sdX bs=4M status=progress oflag=sync
Boot and install
Insert the USB drive and boot your machine from it. Adjust the boot order in UEFI or press the boot menu key during startup. Select Start Fedora Silverblue from the GRUB menu. The Anaconda installer opens. Choose your language, keyboard layout, and time zone.
Under Installation Destination, select your disk. Silverblue supports automatic partitioning with LUKS full-disk encryption. Enable LUKS if you store sensitive data. The installer creates a partition layout optimized for ostree. You'll see a large ostree partition and a separate home partition. This separation ensures your personal files survive a system rollback.
Set a root password and create a user account. Click Begin Installation and wait for the process to finish. The installer downloads the base tree and writes the initial deployment. Reboot when prompted. Remove the USB drive before the system restarts.
Config files in /etc/ are preserved across updates. Files in /usr/lib/ are part of the immutable tree and cannot be edited. If you need to modify a configuration that ships in /usr/lib/, copy it to /etc/ and edit the copy. The system checks /etc/ first. This convention applies to all Fedora systems, but it is critical on Silverblue because editing /usr/lib/ is impossible without breaking the deployment.
Trust the package manager. Manual file edits drift, snapshots stay.
The three-layer workflow
Silverblue divides software into three categories. Desktop applications go in Flatpak. Development environments go in Toolbox. System-level tools that must run on the host go in layering.
Here's how to add the Flathub remote and install a desktop app.
# Add the Flathub remote. This is the primary source for desktop applications on Silverblue.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# Install Firefox from Flathub. Flatpak apps run in sandboxes and do not touch the host OS.
flatpak install flathub org.mozilla.firefox
Here's how to create a mutable container for development work.
# Create a mutable container based on the host's Fedora release.
# This gives you a standard dnf environment for development without breaking the immutable base.
toolbox create
# Enter the container. Your home directory is shared, so your code and configs are accessible.
toolbox enter
From inside Toolbox you can install any package with dnf as usual. The container shares the host kernel but has its own root filesystem. You can install compilers, debuggers, and libraries without affecting the host.
Here's how to layer RPM packages onto the base image.
# Layer RPM packages onto the base image. Use this only for system-level tools that cannot run in Flatpak or Toolbox.
# Layering adds packages to the immutable tree, which increases the size of the deployment.
rpm-ostree install vim htop
# Reboot to activate the new deployment. rpm-ostree applies changes on boot, not immediately.
systemctl reboot
Layering is the exception, not the rule. Layering too many RPMs defeats the purpose of immutability. Every layered package increases the size of the deployment and slows down updates. If you find yourself layering more than five packages, move that workload into a Toolbox container or a custom Flatpak build.
Toolbox is your mutable friend. Keep the host clean.
Upgrading and rolling back
Upgrades are atomic and handled by rpm-ostree. The command downloads the new tree and prepares it for the next boot.
Here's how to upgrade the system.
# Check for updates. rpm-ostree downloads the new tree and prepares it for the next boot.
rpm-ostree upgrade
# Reboot to switch to the new deployment. The old deployment remains available for rollback.
systemctl reboot
If an upgrade causes problems, you can roll back to the previous deployment. The rollback is instant. You just reboot into the old tree.
Here's how to revert to the previous deployment.
# Revert to the previous deployment if the current one is broken.
# This is atomic and instant. You just reboot into the old tree.
rpm-ostree rollback
dnf upgrade --refresh is the normal weekly maintenance command on Workstation. rpm-ostree upgrade is the equivalent on Silverblue. They are different commands. Don't conflate them. Running dnf upgrade on Silverblue will fail because the system blocks in-place modifications.
Reboot before you debug. Half the time the symptom is gone.
Verify the deployment
Here's how to check the current deployment and available rollbacks.
# Show the current deployment and available rollbacks.
# Look for "Deployments" to see the list of bootable snapshots.
rpm-ostree status
The output looks like this:
State: idle
AutomaticUpdates: disabled
Deployments:
● fedora:fedora/41/x86_64/silverblue
Version: 41.18.1 (2024-06-15T00:00:00Z)
...
fedora:fedora/41/x86_64/silverblue
Version: 41.18.0 (2024-06-01T00:00:00Z)
...
The bullet point indicates the currently booted deployment. The list below shows older deployments available for rollback. If you see only one deployment, you have no rollback safety. Run rpm-ostree upgrade to create a new deployment, then verify the list grows.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls
You will try to run sudo dnf install something out of habit. The command will fail with a conflict error. This is not a bug. dnf is disabled for system packages on Silverblue because it modifies files in place. The system protects itself from corruption.
Error: Transaction test error:
package kernel-5.14.0-1.x86_64 conflicts with kernel provided by rpm-ostree
If you see this error, stop. Read the error. Switch to the right tool. Use rpm-ostree install for system tools, flatpak for apps, or toolbox for development. Forcing dnf will break the boot tree.
Another common issue is SELinux denials. Silverblue enforces SELinux strictly. If a service fails to start, check the logs for AVC denials.
# Check for SELinux denials. The -t flag filters by the setroubleshoot tag.
# Read the one-line summary before disabling SELinux.
journalctl -t setroubleshoot
Disabling SELinux is rarely the solution. The denial usually points to a missing context or a misconfigured path. Fix the configuration. Re-enable SELinux.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
Choose the right variant
Use Silverblue when you want a known-good base image you can always roll back to. Use Workstation when you need to install kernel modules or low-level driver patches that require mutable access to /lib/modules. Use Kinoite when you prefer the KDE Plasma desktop but want the same immutable safety as Silverblue. Use Server when you are running headless services and do not need a graphical environment. Stay on the upstream Workstation if you only deviate from the defaults occasionally and you are comfortable fixing broken dnf transactions.