You need to remove a package, but the base image won't let you
You switched to Fedora Silverblue for the stability. You love that the system stays clean and updates are atomic. Then you realize the base image includes a package you never use, or you need a specific version of a library that conflicts with what Fedora ships. You try sudo dnf remove and the terminal throws an error about the immutable base. You are stuck. The package manager refuses to touch the layer you just added, and the base image won't let you delete what isn't there.
This is where rpm-ostree override commands come in. They let you punch holes in the base image or swap components without breaking the immutable model. You can remove packages you don't want and replace others with custom builds. The system stays bootable, and you retain the ability to roll back if something goes wrong.
How rpm-ostree handles overrides
rpm-ostree builds the system like a stack of transparent sheets. The bottom sheet is the base image from Fedora. It contains the kernel, the desktop environment, and core libraries. You cannot draw on that sheet. When you install packages, rpm-ostree creates a new sheet on top. This overlay contains your additions.
Overrides modify how the stack is read. override remove tells the system to ignore a package from the bottom sheet. override replace tells the system to use a file from the top sheet instead of the bottom. The base image remains untouched on disk. The changes live in the overlay layer. This keeps the base verifiable and ensures you can always return to a known-good state.
The transaction model is atomic. rpm-ostree calculates the new tree, writes it to disk, and updates the boot entry only if everything succeeds. If a dependency check fails, the system stays exactly as it was. You never end up with a half-applied change. A botched override can leave you unable to boot if you ignore dependency errors. Run these commands carefully and check the output before rebooting.
Remove a package from the base image
Use override remove when you want to hide a package from the base image. This is useful for bloat removal or when a package causes conflicts with your workflow. The package remains in the base image metadata but is excluded from the running system.
Here's how to remove a package and apply the change.
sudo rpm-ostree override remove <package-name>
# WHY: This creates a blacklist entry for the package in the current deployment.
# The package is excluded from the merged tree.
# Dependencies that require this package will fail to resolve unless overridden too.
sudo reboot
# WHY: rpm-ostree changes are applied at boot time.
# The new deployment becomes active only after a restart.
# Your current session continues running the old deployment until you log back in.
Reboot before you verify. The override lives in the next boot, not the current shell.
Replace a package with a custom version
Use override replace when you need to swap a specific package with a custom RPM. This is common for custom kernels, patched libraries, or packages from third-party repositories that provide a newer version than the base image.
Here's how to replace a package with a local RPM file.
sudo rpm-ostree override replace /path/to/custom-package.rpm
# WHY: This installs the RPM into the overlay layer and marks it as an override.
# Files in this package take precedence over files with the same path in the base image.
# The base package is hidden but remains available for rollback.
sudo reboot
# WHY: The replacement takes effect in the new boot entry.
# The system merges the overlay with the base at startup.
# Applications will load the replaced package after reboot.
You can also replace a package directly from a repository. This is cleaner than downloading the RPM manually.
sudo rpm-ostree override replace --from-repo=repo-name package-name
# WHY: This pulls the package from a configured repository instead of a local file.
# Useful for replacing a package with a version from a COPR or custom repo.
# The repo must be enabled and contain the exact package name.
sudo reboot
# WHY: The boot process fetches the new tree state.
# The override is persisted in the deployment metadata.
Trust the layering. Overrides are temporary patches, not permanent modifications to the base.
Verify the override
After rebooting, check that the override is active. rpm-ostree status shows the current deployment and lists all modifications.
rpm-ostree status
# WHY: Displays the current deployment ID and commit hash.
# Look for the "Overrides" section to confirm your remove or replace is active.
# The output shows which packages are removed and which are replaced.
Check the output. If you see the package under "Removed" or "Replaced", the override is in place. If the section is empty, the override did not apply. Check the journal for errors.
Common pitfalls and dependency errors
Overrides are surgical. If you remove a package that another package depends on, the system might refuse to boot or applications will crash. rpm-ostree checks dependencies before applying the change. You will see an error if the transaction is unsafe.
Error: Transaction test error: package libfoo requires libbar >= 1.0
This error means something else needs the package you are trying to remove. You must override remove the dependent package as well, or accept that the removal is not safe. Read the dependency error. It tells you exactly what else needs to move. Guessing breaks the boot.
If you run override replace on a package that isn't in the base image, you get a different error.
Error: Package custom-tool is not installed in the base
This means the base image does not contain custom-tool. Use rpm-ostree install for new packages. override replace only works when you are swapping an existing component.
Another common issue is disk space. rpm-ostree keeps old deployments for rollback. Over time, this uses disk space. Run sudo rpm-ostree cleanup --rollback periodically to free space. This removes old deployments but keeps the current one safe. If you have applied too many overrides and want to return to the factory state, use sudo rpm-ostree reset. This clears the overlay layer and returns the system to the pristine base image. This is the nuclear option. Use it when you want to start fresh without reinstalling.
Run journalctl first. Read the actual error before guessing.
When to use overrides vs other tools
Use rpm-ostree override remove when you want to hide a package from the base image without breaking the layering model.
Use rpm-ostree override replace when you need to swap a specific file or package with a custom version from an RPM.
Use rpm-ostree install when you are adding a new package that does not conflict with the base image.
Use rpm-ostree reset when you have applied too many overrides and want to return to the factory state.
Use rpm-ostree cleanup when disk space is low and you want to remove old deployment history.
Stay on the base image defaults if you only need standard tools available in the Fedora repositories.