You installed Fedora Silverblue and dnf refuses to work
You installed Fedora Silverblue because atomic updates sounded safe. Now you are trying to install a driver or a development tool and sudo dnf install refuses to work. The terminal prints a read-only filesystem error. You wonder if you broke the system. You did not. The system is working exactly as designed. The base image is immutable. You need to change how you approach package management.
This article explains the difference between Fedora Workstation and Fedora Silverblue, how to manage software on each, and how to choose the right edition for your workflow.
What is actually happening
Fedora Workstation and Fedora Silverblue share the same GNOME desktop, the same kernel, and the same package repositories. The difference is how the operating system stores and updates its files.
Workstation is mutable. You install a package, files appear in /usr/bin and /usr/lib. You remove a package, files disappear. The system state changes incrementally. You can modify system directories, install kernel modules, and tweak configuration files anywhere.
Silverblue is immutable. The root filesystem is a read-only image. You cannot add or remove files from the base OS directly. Updates replace the entire image atomically. If an update breaks something, you roll back to the previous image with one command.
Think of Workstation like a house where you can renovate rooms, add extensions, and paint walls whenever you want. Silverblue is like a house built from prefabricated modules. You cannot drill holes in the walls. If you want a new kitchen, you swap the entire kitchen module with a new one. If the new module has a leak, you swap back to the old one instantly.
Both editions are production-ready. The choice depends on how you want to manage system state and risk.
Managing Fedora Workstation
Workstation uses the traditional dnf package manager. You install, update, and remove packages directly on the host filesystem. This is the standard Linux workflow.
Run this command to update the system and refresh metadata.
sudo dnf upgrade --refresh
# --refresh forces dnf to download fresh metadata from repositories.
# This prevents stale cache issues that cause dependency resolution failures.
# This is the recommended weekly maintenance command for Workstation.
Workstation allows you to install packages from any enabled repository. You can add third-party repos, install kernel modules, and modify system libraries. This flexibility comes with responsibility. A bad package or a manual file edit can break the system.
Run dnf history to review past transactions. You can undo changes if needed, but rollback is manual and not guaranteed to restore a clean state.
Reboot before you debug. Half the time the symptom is gone.
Managing Fedora Silverblue
Silverblue uses rpm-ostree to manage the OS image. You cannot use dnf to install packages on the host. Instead, you compose a new image with the desired packages and reboot into it.
Run this command to fetch and stage the latest OS update.
rpm-ostree upgrade
# Fetches the new OS image from the configured repositories.
# Stages the update for the next boot. Does not modify the running system.
# You must reboot to apply the update.
Check the current state and pending deployments.
rpm-ostree status
# Shows the current deployment and any pending updates.
# Lists all available deployments in the boot menu.
# Essential for verifying that an update was staged correctly.
Silverblue keeps the host clean. GUI applications run as Flatpaks. Development tools run in containers. The base OS remains stable and predictable.
Reboot to apply the update. The new image is staged, not active.
Installing software on Silverblue
You install software on Silverblue using two methods: Flatpak for graphical applications and containers for command-line tools.
Flatpak handles GUI apps. Install Firefox from Flathub.
flatpak install flathub org.mozilla.firefox
# Installs the app in the user's Flatpak directory.
# The app runs in a sandbox isolated from the host OS.
# Flatpak apps update independently of the OS image.
Containers handle development tools. Create a mutable Fedora environment with toolbox.
toolbox create
# Creates a container based on the host's Fedora version.
# The container has a writable filesystem and full dnf access.
# Your home directory is synced between the host and the container.
Enter the container to install packages.
toolbox enter
# Drops you into the container shell.
# You can now run dnf install freely without affecting the host.
# Tools installed here are available only inside the container.
Install development tools inside the container.
dnf install gcc python3-devel nodejs
# Installs packages into the container's filesystem.
# The host OS remains unchanged.
# You can create multiple containers for different projects.
Keep the host clean. Put your chaos in the container.
When to layer RPMs
Silverblue allows you to layer RPM packages onto the base image using rpm-ostree install. Use this sparingly. Layering adds packages to the OS image, which can cause conflicts or bloat over time.
Layer an RPM only when the package must run on the host directly. Examples include kernel modules, drivers that need access to host hardware, or system services that cannot run in a container.
rpm-ostree install vim
# Layers the vim package onto the base image.
# The package is included in the next OS deployment.
# Use this only for packages that must be on the host.
Check layered packages.
rpm-ostree status
# Look for the "Layered Packages" section in the output.
# This lists all RPMs added to the base image.
# Remove unused layers to keep the image clean.
Remove a layered package.
rpm-ostree uninstall vim
# Removes the package from the next OS deployment.
# Stages a new image without the package.
# Reboot to apply the change.
Prefer Flatpak and containers over layering. Layering drifts from the upstream image and makes upgrades harder.
Trust the package manager. Manual file edits drift, snapshots stay.
Verify the state
Always verify the system state after making changes. On Silverblue, rpm-ostree status is your primary tool.
Run this command to confirm the deployment.
rpm-ostree status
# Shows the current deployment and pending updates.
# Verify that the new deployment is listed and marked as pending.
# Check the checksum to ensure the image matches the expected version.
Verify toolbox containers.
toolbox list
# Lists all created toolbox containers.
# Shows the container name and the base image version.
# Use this to manage multiple development environments.
Verify Flatpak apps.
flatpak list
# Lists all installed Flatpak applications.
# Shows the app ID and the installation directory.
# Use this to audit user-installed software.
Run journalctl -xe if something fails. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Common pitfalls
New users often run into these issues when switching to Silverblue.
Trying sudo dnf install on the host.
The command fails with Error: Transaction test error: ... read-only filesystem. The host filesystem is read-only. Use rpm-ostree install for host packages, or toolbox for development tools. Do not force dnf on the host.
Forgetting to reboot after rpm-ostree upgrade.
The update is staged, not applied. The system continues running the old image until you reboot. Run rpm-ostree status to check for pending deployments. Reboot to activate the update.
Layering too many RPMs. Every layered package adds complexity to the OS image. Conflicts can arise when layered packages depend on different library versions. Prefer Flatpak and containers. Layer only what is strictly necessary.
Editing files in /usr/lib.
Files in /usr/lib ship with the package and are read-only on Silverblue. Edit configuration files in /etc. This is a Linux convention, not just Silverblue. Changes in /etc persist across updates. Changes in /usr/lib are overwritten.
Ignoring SELinux denials.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Most denials are caused by incorrect file contexts or missing policies. Fix the root cause.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
Which should you choose
Use Fedora Workstation when you need full control over the filesystem and want to install packages directly with dnf.
Use Fedora Workstation when you are developing kernel modules or low-level drivers that require mutable system directories.
Use Fedora Workstation when you prefer a traditional Linux workflow and do not need atomic rollback capabilities.
Use Fedora Silverblue when you want atomic updates that either succeed completely or leave the system unchanged.
Use Fedora Silverblue when you value the ability to roll back to a previous OS version with a single command.
Use Fedora Silverblue when you run most applications as Flatpaks and keep development tools in containers.
Stay on Workstation if you frequently modify system configuration files in /usr/lib or rely on third-party repositories that break on immutable bases.
Snapshot the system before the upgrade. Future-you will thank you.