You cannot install packages on the host
You installed a development library with sudo dnf install gcc and the terminal spat back Error: Transaction test error: package glibc conflicts with ostree deployment. Or you rebooted after an update and the system is stuck on a black screen with a blinking cursor. You are used to Fedora Workstation where dnf fixes everything. Here, the root filesystem refuses to change. This is not a bug. This is Fedora Silverblue doing exactly what it was designed to do.
What is actually happening
Fedora Workstation treats your system like a living organism. You add packages, remove packages, and the system grows and changes in place. Fedora Silverblue treats your system like a series of snapshots. The root filesystem is read-only. You cannot install packages directly onto the host. Every update replaces the entire system image atomically. If the new image fails to boot, the previous image is still there, untouched, ready to take over.
Under the hood, Silverblue uses rpm-ostree. This tool manages an ostree repository. An ostree repo stores commits, much like Git stores commits. Each commit represents a complete system state. When you run an update, rpm-ostree downloads a new commit and switches the boot entry to point at it. The old commit remains on disk until you explicitly remove it. Trust the snapshot. The previous state is your safety net.
How to install software
Since you cannot modify the host, you install software in containers. Fedora provides two main tools for this. Flatpak handles desktop applications. Toolbox handles development environments.
Here's how to set up a mutable development environment inside a container using Toolbox.
# Install toolbox if it is not already present.
# On Silverblue, this command usually works because toolbox is pre-installed,
# but running it ensures the binary exists in your PATH.
sudo dnf install toolbox
# Create a new container named 'dev' using the latest Fedora image.
# The container gets a mutable root filesystem where you can run dnf freely.
toolbox create --name dev --image fedora:latest
# Enter the container. Your shell prompt changes to indicate you are inside the container.
# You can now install packages, compile code, and modify files without affecting the host.
toolbox enter dev
Toolbox containers share the user's home directory by default. Files you create in the container are accessible on the host. This makes it seamless for editors and IDEs. Run toolbox list first. Verify the container is running before you install packages.
Here's how to verify the container is running and check the system deployment status.
# List all toolbox containers. Look for the 'dev' container with a 'Running' state.
# If the state is 'Stopped', you need to enter it again to start it.
toolbox list
# Show the current system deployment. The 'Booted' marker indicates which image is active.
# The 'Deployed' list shows all available images you can roll back to.
rpm-ostree status
Updates and maintenance
Updates work differently on Silverblue. You do not use dnf upgrade. You use rpm-ostree upgrade. The command downloads the new image, verifies the signature, and prepares the boot entry. The update applies on reboot.
Here's how to check for updates and apply them safely.
# Check for available updates. This command contacts the repository and compares
# the current commit ID with the latest commit ID available.
rpm-ostree upgrade --check
# Download and apply the update. The system will prepare the new deployment.
# You must reboot for the changes to take effect.
rpm-ostree upgrade
# Reboot the system to switch to the new deployment.
# If the new deployment fails, the bootloader will automatically fall back to the previous one.
systemctl reboot
rpm-ostree upgrade is the weekly maintenance command. It replaces dnf upgrade --refresh. You can also use rpm-ostree upgrade --uninstall <package> to remove layered packages. Reboot before you debug. The update only applies after the system restarts.
Layering versus containers
Layering allows you to add packages to the host image. This is useful for proprietary drivers or kernel modules. When you layer a package, rpm-ostree creates a new commit that includes your package. The next time you update, the system merges your layers into the new base image. This can cause conflicts if the base image changes dependencies.
Here's how to layer a package onto the host when you have no other choice.
# Install a package onto the host image. This modifies the deployment tree.
# The change applies on the next boot. Do not expect immediate effect like dnf.
rpm-ostree install kernel-devel
# Reboot to apply the layered package.
# The system will boot into a new deployment that includes kernel-devel.
systemctl reboot
Layering changes the boot image. The next update will require a full re-download and reboot. Use layering sparingly. Reserve it for kernel modules or drivers that cannot run inside a container. If you layer a package and the base image updates a dependency, rpm-ostree upgrade might fail with a dependency conflict. You will need to update your layers or remove the conflicting package. This is why containers are preferred. Containers isolate dependencies and avoid conflicts with the base image.
Common pitfalls
The most common mistake is trying to install packages directly on the host. The command sudo dnf install nginx will fail. The error message looks like this:
Error: Transaction test error:
package glibc-2.38-1.fc40.x86_64 conflicts with ostree-deployment provided by rpm-ostree-2024.1-1.fc40.x86_64
The conflict is intentional. The host filesystem is locked by the ostree deployment. You must use rpm-ostree install for host-level packages or use a container. Read the conflict message. The error tells you exactly which package is fighting the ostree deployment.
Another pitfall is editing configuration files in /usr/lib/. Files in /usr/lib/ ship with the package. Editing them will cause the next update to overwrite your changes. Always edit files in /etc/. Config files in /etc/ are user-modified and persist across updates. If you need to modify a file that only exists in /usr/lib/, copy it to /etc/ first and edit the copy.
When to use Silverblue versus Workstation
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 without rebuilding the image. Use Server when you are running services and not a desktop. Stay on the upstream Workstation if you only deviate from the defaults occasionally. Use Silverblue when your workflow relies heavily on containers and you value system stability over direct host modification. Use Workstation when you prefer a traditional package management experience and do not mind manual recovery after a broken update. Choose the variant that matches your workflow. Switching later is possible, but planning ahead saves time.