The six-month clock
You boot into your desktop and open a terminal to run your weekly maintenance. The dnf upgrade command hangs for a moment, then spits out a wall of red text about expired metadata and missing repository signatures. Your system is still running, but the package manager has quietly stopped trusting the servers. You are looking at a Fedora release that has crossed the End of Life threshold. The six-month clock ran out, the mirrors turned off the taps, and your machine is now operating on a frozen snapshot of the software ecosystem.
What actually happens when a version goes EOL
Fedora follows a strict release cadence. A new version ships every six months. When version N+1 lands, version N-2 immediately reaches End of Life. The infrastructure team removes the old release from the primary mirrors, rotates the GPG signing keys, and stops patching security vulnerabilities. Your local system does not know this happened until you ask dnf to fetch new package lists. The package manager tries to contact the repository, gets a 404 or an expired signature, and refuses to proceed. This is a safety feature. Fedora will not let you install packages from a repository it cannot verify.
Think of it like a software subscription that auto-renews on a strict schedule. When the renewal window closes, the service does not degrade gracefully. It locks the door. You can still use what is already installed, but you cannot add anything new, update anything existing, or apply security patches. Running an EOL release means you are responsible for every vulnerability discovered after the cutoff date. The repository metadata files contain cryptographic hashes and version constraints. Once those files expire, dnf treats the entire repository as untrusted. This prevents accidental installation of tampered or incompatible packages.
Check your version number first. Guessing leads to broken transactions.
How to check your current status
Before you panic or force anything, verify exactly which release you are running and whether the repositories are actually unreachable. Run the following command to see your current major version and the target release version your system expects.
rpm -E %fedora # Expands the RPM macro to show your current major release number
dnf repolist --enabled # Lists active repositories and their current metadata status
dnf check-update # Attempts to fetch package lists without installing anything
If dnf check-update returns Error: Failed to download metadata for repo 'fedora', your release has likely gone EOL. The error will also mention Cannot prepare internal mirrorlist or GPG key expired. Do not ignore these warnings. They mean the package manager cannot verify package integrity. The --enabled flag filters out disabled repositories so you can focus on the ones that should be active. The check-update command simulates an upgrade without touching your disk. This lets you confirm the repository state before committing to a full transaction.
Run journalctl first. Read the actual error before guessing.
The upgrade path
Fedora provides a built-in tool for crossing major release boundaries. The dnf system-upgrade plugin handles the complex dependency resolution, downloads all required packages, and reboots into a special upgrade transaction. This is different from your daily dnf upgrade --refresh command. The refresh flag only updates packages within the same release. The system-upgrade plugin actually changes the releasever variable and pulls in the new kernel, system libraries, and desktop environment.
Here is how to prepare the system and trigger the upgrade. Run these commands from a terminal with a stable internet connection. Close your browser and heavy applications before starting.
sudo dnf clean all # Clears cached metadata and package headers to force a fresh fetch
sudo dnf system-upgrade download --releasever=$(rpm -E %fedora) # Calculates the next version and downloads all packages
sudo dnf system-upgrade reboot # Commits the downloaded packages and restarts into the upgrade transaction
The download phase can take anywhere from ten minutes to an hour depending on your connection speed and how many third-party repositories you have enabled. The reboot phase runs the actual upgrade in the background. You will see a text-mode progress bar. Do not interrupt the process. Pulling the power or forcing a shutdown during the transaction will leave the package database in an inconsistent state. The plugin stages all new packages in a temporary directory, verifies their signatures, and then applies them atomically during the reboot. This design prevents partial upgrades from corrupting your system.
Snapshot the system before the upgrade. Future-you will thank you.
Verify it worked
Once the system reboots and drops you back at the login screen or terminal, confirm the new release is active and the repositories are responding. Run these commands to validate the transition.
rpm -E %fedora # Should now show the new major version number
dnf repolist # Confirms all repositories are reachable and metadata is fresh
systemctl status dnf-makecache.timer # Verifies the background metadata refresh timer is active
If the version number matches your expectation and dnf repolist shows valid package counts, the upgrade succeeded. Your desktop environment, kernel, and core utilities are now aligned with the current release cycle. The dnf-makecache.timer unit runs periodically to keep your local package database synchronized with the mirrors. If it shows inactive or failed, run sudo systemctl enable --now dnf-makecache.timer to restore automatic updates.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Upgrades rarely fail because of Fedora itself. They fail because of third-party repositories, custom configuration files, or incompatible kernel modules. The most common blocker is RPM Fusion or a custom vendor repository that has not yet built packages for the new release. When this happens, dnf will abort with a dependency conflict.
You will see output similar to Error: Transaction test error: package kernel-modules-extra conflicts with kernel-core. This usually means a third-party kernel module expects the old kernel ABI. The system will refuse to boot the new kernel until you remove or update the conflicting module. Another frequent issue is stale configuration files in /etc/. During an upgrade, dnf will detect modified configuration files and ask whether to keep your version or install the package maintainer's version. Always choose to keep your version unless you know the new default fixes a bug you are experiencing. You can review the differences later with rpm -V or dnf config-manager.
SELinux policy updates can also trigger denials if you have custom contexts or booleans set. Check journalctl -t setroubleshoot immediately after the first login. The logs will show a one-line summary of any blocked operations. Fix the policy before assuming the upgrade broke your services. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. This convention protects your customizations from being overwritten during package updates.
Reboot before you debug. Half the time the symptom is gone.
When to upgrade vs when to wait
You do not need to upgrade the moment a new release ships. Fedora supports three active releases at any given time. The current release, the previous release, and the release before that all receive security updates. Plan your maintenance around your workload, not the calendar.
Use dnf system-upgrade when you want to stay on the supported release track and keep your hardware drivers and desktop environment current. Use a clean installation when you have accumulated years of configuration drift, broken third-party repositories, or custom kernel patches that no longer apply. Use the current release when you need immediate access to the latest security patches and software versions. Stay on the N-1 release when you are running production services and cannot afford the downtime of a major upgrade. Revert to a backup snapshot when the upgrade transaction fails and leaves the system in a broken state.
Plan upgrades on the six-month cycle. The N-2 release goes EOL when N+1 ships.