You booted the ISO and the installer looks different
You downloaded the Fedora Silverblue ISO, flashed it to a USB stick, and booted the machine. The installer loads, but the options look slightly different from Workstation. You see "Immutable OS" mentioned, and a warning about the root filesystem. You want to install the system without accidentally turning it into a broken hybrid that updates fail on. You need the clean, atomic base, not a manual configuration that drifts.
Read the immutable model before you install. The commands you know from Workstation will behave differently here.
What's actually happening
Fedora Silverblue is not a standard Fedora installation. The root filesystem is immutable. You do not install packages directly onto the system. The OS is a composite image built from RPMs, managed by rpm-ostree. Think of the system as a read-only container image that runs your desktop and services. When you update, the system downloads a new image, verifies it, and reboots into the new version. The old version stays on disk as a rollback target.
This means the installer sets up a bootable image layer, not a mutable directory tree. The installer handles the partitioning and bootloader configuration to support this atomic model. It creates a Btrfs subvolume structure to store multiple deployments efficiently. The bootloader is configured to switch between these deployments on reboot. You are installing a version-controlled operating system, not a collection of files.
Flashing and booting the installer
Here's how to write the ISO to the USB drive using the command line to ensure a bit-perfect copy.
# Identify the USB device. Replace /dev/sdX with your actual device.
lsblk
# Write the ISO to the device. bs=4M speeds up the transfer.
sudo dd if=Fedora-Silverblue-40-1.5.x86_64.iso of=/dev/sdX bs=4M status=progress oflag=sync
# WHY: oflag=sync ensures data is flushed to disk before the command returns.
# WHY: dd writes raw bytes, preserving the EFI boot partition structure in the ISO.
Flash the ISO with dd. Verify the write with sha256sum before you boot.
Boot the machine from the USB drive. The installer is the same Anaconda interface used by Workstation, but the default partitioning scheme is optimized for atomic updates. Select "Install to Hard Drive". The installer will detect the immutable requirement and configure the filesystem accordingly. You can customize the partitioning if needed, but the automatic layout is recommended for first-time installations. The installer creates a Btrfs root with subvolumes for the ostree deployments.
Running the installation
Follow the on-screen prompts to configure your user account and network. The installer will ask for a root password or a user with sudo privileges. Set this up now. You will need it to run rpm-ostree commands later.
The installation process downloads the base image and writes it to the disk. This takes longer than a standard installation because the system is building a composite tree. Wait for the progress bar to complete. Do not interrupt the process. The installer will reboot the machine when finished.
If the installer hangs, check the USB drive speed. Slow drives can cause timeouts during the image write phase. Use a USB 3.0 port and a high-quality drive.
Post-install verification
After the reboot, verify the system recognizes the immutable root and the current deployment.
# Check the current deployment and the read-only status of the root filesystem.
rpm-ostree status
# WHY: This command shows the bootable deployments and the pinned commit hash.
# WHY: Look for "State: Idle" to confirm no background transactions are running.
Run rpm-ostree status before you reboot. If the deployment isn't listed, the install didn't finish.
Inspect the Btrfs subvolume structure to understand how snapshots are stored.
# List the Btrfs subvolumes on the root filesystem.
sudo btrfs subvolume list /
# WHY: This shows the hierarchy of subvolumes, including the ostree deployment layers.
# WHY: Each deployment lives in a separate subvolume, enabling instant rollbacks.
Verify the system is pointing to the correct update repository.
# List the configured remotes for atomic updates.
rpm-ostree remote list
# WHY: This shows the base URLs where the system fetches new image layers.
# WHY: Ensure the default remote points to the official Fedora Silverblue repository.
Check the journal for any boot issues related to the immutable filesystem.
# Review the boot log for errors, focusing on systemd and rpm-ostree units.
journalctl -b -xeu rpm-ostree
# WHY: The -b flag scopes output to the current boot.
# WHY: -xe adds explanatory text and jumps to the end of the log.
# WHY: Filtering by rpm-ostree isolates atomic update messages from general noise.
Check the journal before you guess. The error message usually points to the missing dependency.
Setting up a mutable development environment
Silverblue does not support dnf install for system packages. You need a mutable environment for development tools. Here's how to create a toolbox container with the default Fedora image.
# Create a toolbox container with the default Fedora image.
toolbox create
# WHY: This pulls the container image and sets up the persistent home directory mount.
# WHY: The container shares the host user ID, so files created inside are accessible outside.
# Enter the container to start installing packages.
toolbox enter
# WHY: You are now in a mutable environment where dnf install works normally.
Install tools in the toolbox. Keep the host clean.
The toolbox container shares your home directory. Files created inside the container are visible on the host. You can install any package you need inside the toolbox without affecting the host image. The toolbox persists across reboots and updates. If you update the host, the toolbox remains intact. You can update the toolbox image independently using toolbox update.
Common pitfalls and errors
The installer might fail if Secure Boot is enabled and the machine lacks the necessary keys. If the installer fails with Shim locked or Signature verification failed, Secure Boot is rejecting the boot loader. You may need to enroll the Fedora keys or disable Secure Boot temporarily.
If you try to install a package post-install and see Error: Cannot install on an immutable filesystem, you are using the wrong tool. Silverblue does not support dnf install for system packages. Use toolbox or podman for mutable environments.
SELinux runs in enforcing mode on Silverblue. The immutable filesystem works with SELinux policies. Do not disable SELinux to fix permission errors. The error is likely a missing context or a container issue. If you see Permission denied when running podman commands, check the SELinux context. The container runtime requires specific labels.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Changes to /usr/lib/ will be overwritten on the next update.
Trust the immutable root. If you try to edit /usr/lib, you are fighting the design.
Choosing the right Fedora variant
Use Silverblue when you want a read-only root filesystem that prevents configuration drift and allows atomic rollbacks. Use Workstation when you require mutable system packages or need to compile kernel modules without layering overhead. Use Kinoite when you prefer the KDE Plasma desktop environment with the same immutable guarantees. Use Server when you are deploying headless services and do not need a graphical session.
Pick the variant that matches your workflow. Switching later requires a rebase or reinstall.