The reality of running Rawhide
You run a routine system update after work and the terminal halts on a dependency conflict. The graphical target fails to start. The boot logs show a kernel panic or a missing shared library. You are not on a stable release. You are on Rawhide. This is not a bug. This is the intended state of the branch. Rawhide exists to catch exactly these kinds of breakages before they reach numbered releases. You are standing in the middle of the construction site while the engineers are still pouring concrete.
What Rawhide actually is
Fedora follows a six-month release cadence. Every six months, the current development tree branches off, freezes, and becomes the next stable release. Rawhide is the name of that development tree. It is a rolling snapshot of everything currently being packaged for Fedora. There is no quality gate. There is no feature freeze. Packages land the moment they compile and pass basic automated checks. Think of Rawhide as a live workshop where the blueprints are still being drawn. The foundation is poured, but the wiring is exposed and the doors might not fit the frames yet.
The branch serves a single purpose. It is the proving ground for the next Fedora release. When Fedora 42 ships, Rawhide immediately becomes the development branch for Fedora 43. The version number in the repository metadata updates automatically. You do not need to change your configuration files to follow the next release. The branch name stays Rawhide. The packages inside it just get newer.
Package maintainers push updates to Rawhide continuously. The Fedora release engineering team runs automated build checks and basic test suites. If a package breaks the build, it gets flagged. If it passes, it lands. There is no manual review queue for every commit. This speed is intentional. It allows the community to spot regressions in compilers, desktop environments, and core libraries weeks before the stable freeze.
Convention aside: dnf upgrade --refresh is the normal weekly maintenance command on stable Fedora. On Rawhide, you will run it daily. The metadata changes so frequently that stale cache files cause false dependency errors. Always refresh the cache before attempting a transaction on the development branch.
How to rebase to Rawhide
Switching to Rawhide requires replacing your current repository metadata with the development branch metadata. The package manager will then pull every available update, often replacing core system libraries. This is a full system rebase, not a simple upgrade. You must stage the transaction properly to avoid leaving the system in an inconsistent state.
Here is how to rebase a standard Fedora Workstation or Server installation using DNF.
sudo dnf install fedora-repos-rawhide
# WHY: pulls the repository definition files that point to the Rawhide mirrors
sudo dnf system-upgrade download --releasever=rawhide
# WHY: fetches all required packages and stages them for a transactional reboot
sudo dnf system-upgrade reboot
# WHY: triggers the staged transaction during early boot before the root filesystem is mounted read-only
The dnf system-upgrade command is designed for crossing major release boundaries. It downloads everything first, then reboots into a special early-boot environment where it applies the changes. This prevents partial transactions from corrupting your system. If you only run dnf distro-sync without the staging step, you risk leaving the system in an inconsistent state when the reboot happens. The package manager will abort mid-transaction and leave orphaned dependencies on disk.
For Fedora Silverblue or Kinoite, the immutable OS model changes the workflow. You cannot replace packages individually. You must switch the entire bootable image.
sudo rpm-ostree rebase fedora:fedora/rawhide/x86_64/silverblue
# WHY: tells the container-based OS to fetch the Rawhide OSTree commit
sudo systemctl reboot
# WHY: applies the new tree and drops you into the updated environment
The immutable branch uses a transactional rollback model. If the new image fails to boot, the previous commit remains intact. You will automatically fall back to the last known good state. This makes Rawhide significantly safer on Silverblue than on a traditional mutable installation. Trust the package manager. Manual file edits drift, snapshots stay.
Verify the rebase worked
After the system boots, check the release version and repository status. The output should confirm you are tracking the development branch. You need to ensure the stable repositories are completely disabled. Running two incompatible repository trees simultaneously will cause immediate dependency conflicts.
cat /etc/os-release | grep PRETTY_NAME
# WHY: confirms the OS metadata reflects the Rawhide development label
sudo dnf repolist enabled
# WHY: verifies that rawhide repositories are active and stable repositories are disabled
You will see fedora-rawhide and updates-rawhide in the enabled list. The stable fedora and updates repositories should be absent or disabled. If you see both stable and rawhide repositories enabled simultaneously, your package manager will attempt to merge two incompatible dependency trees. Disable the stable repos immediately. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
When things break and how to respond
Rawhide updates frequently. Some updates land with broken dependencies. Some introduce regressions in the display server or network stack. You will encounter errors that look like this:
Error: Transaction test error:
package glibc-2.39.9000-1.fc43.x86_64 requires glibc-common = 2.39.9000-1.fc43, but none of the providers can be installed
This is a dependency resolution failure. The package manager refuses to proceed because it cannot satisfy the requirements. Do not force the transaction with --best --allowerasing. Forcing breaks the system further. Instead, check the Rawhide change logs and the Fedora devel mailing list. The maintainers usually post a fix within hours. Wait for the next batch of updates.
If the system fails to boot after an update, drop to a root shell. Press Ctrl+Alt+F2 during the boot sequence. If the graphical target fails, the multi-user target usually still works. Check the journal for the actual failure point.
journalctl -b -1 -xe
# WHY: shows the boot log from the previous failed attempt with explanatory context
systemctl status <failed-unit>
# WHY: displays the current state and recent log lines for the specific service
Most boot failures on Rawhide stem from a broken kernel module, a mismatched glibc, or a systemd unit that references a moved binary. You can roll back by booting the previous kernel from the GRUB menu. Select the older kernel version, let the system boot, then run sudo dnf downgrade to revert the problematic packages. If downgrade fails, reinstall the working packages from the stable branch temporarily until Rawhide catches up.
Convention aside: always check journalctl -t setroubleshoot if a service refuses to start. SELinux denials on Rawhide are common when package paths change. The audit log will show exactly which binary was blocked and what context it expected. Fix the policy or restorecon the file instead of disabling SELinux entirely. Run journalctl first. Read the actual error before guessing.
Rawhide versus stable versus containers
You need to match the branch to your actual workflow. The wrong choice wastes time and breaks trust in the system. Evaluate your tolerance for breakage and your actual testing requirements.
Use Rawhide when you are packaging software for Fedora and need to verify builds against upcoming dependencies. Use Rawhide when you are a QA tester filing bugs before the freeze period begins. Use Rawhide when you are developing against the absolute latest compiler or runtime and accept that your desktop may become unusable for a few hours. Use stable Fedora when you need a reliable daily driver for work or personal projects. Use stable Fedora when you are running servers or production workloads that require predictable update cycles. Use containers when you want to test against Rawhide without risking your host system.
Running Rawhide inside a container isolates the breakage. You can pull the official image and spin up an ephemeral environment for build testing. This approach gives you the exact same package tree as a native Rawhide installation. Your CI pipelines can run against this image to catch regressions early. The host system remains on a stable release. You get early access without the operational risk.
podman pull registry.fedoraproject.org/fedora:rawhide
# WHY: fetches the latest Rawhide container image from the official registry
podman run --rm -it registry.fedoraproject.org/fedora:rawhide bash
# WHY: starts an isolated shell that destroys itself on exit, leaving the host untouched
The container shares the host kernel but runs a completely independent userspace. Package conflicts inside the container never touch your host filesystem. You can mount your source code directory and run your build scripts exactly as they would run on a native Rawhide machine. Snapshot the system before the upgrade. Future-you will thank you.