The fresh install trap
You just finished installing Fedora. The desktop looks clean, the terminal is open, and you are ready to work. You run a quick package check and notice dozens of updates waiting. You hesitate. Updating immediately after installation feels risky. What if a kernel update breaks your Wi-Fi? What if a library conflict locks you out of the desktop? The instinct to wait is understandable. The reality is different. A fresh install ships with packages that were current when the ISO was built, not when you downloaded it. Those packages contain known vulnerabilities and missing bug fixes. Running the update now is the single most important step to stabilize your system.
A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
What the installer actually leaves behind
The installer pulls packages from a snapshot of the Fedora repository. That snapshot freezes at a specific point in time. By the time you burn the ISO, verify the checksum, and complete the installation, the upstream repository has moved forward. Your local package cache contains metadata that points to older versions. DNF relies on that metadata to resolve dependencies. If you skip the refresh, DNF might try to install packages that depend on newer libraries, or it might refuse to update because it thinks the current versions are already the latest.
Think of the repository metadata as a table of contents. The table of contents printed on day one does not match the book on day thirty. You need to pull the current index before you can safely reorder the shelves. Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. The installer does not know which release you are targeting. It only knows what was available when the build server closed the ISO. DNF bridges that gap by downloading the current repository index, recalculating dependency trees, and building a transaction that moves every package to the latest stable version.
Trust the package manager. Manual file edits drift, snapshots stay.
Running the first update
Open a terminal and run the standard maintenance command. This forces DNF to discard the stale cache, download the current repository index, and calculate a complete upgrade transaction.
sudo dnf upgrade --refresh
# --refresh forces DNF to ignore cached metadata and fetch fresh repo indexes
# This prevents dependency resolution failures caused by stale ISO snapshots
# DNF will list every package to be upgraded, downgraded, or newly installed
# Press y and enter to proceed with the transaction
Wait for the download and installation to finish. DNF handles dependency chains automatically. It will replace older libraries, update system services, and drop new configuration files into place. If the transaction stops and asks about configuration files, you will see prompts for .rpmnew or .rpmsave files. These appear when a package update ships a modified config file and your system already has a local copy. On a fresh install, you have no local modifications. Accept the new defaults. DNF will overwrite the old files and keep the system consistent.
The dnf upgrade --refresh command is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Reboot before you debug. Half the time the symptom is gone.
Verifying the system state
After the system comes back up, confirm that the package manager sees no pending updates and that the kernel matches the repository version.
sudo dnf check-update
# This queries the repositories again without installing anything
# An empty output means your system is fully synchronized
# If packages still appear, run the upgrade command again to catch stragglers
uname -r
# This prints the currently running kernel version
# Compare it against the latest kernel listed in the dnf upgrade output
Check the service manager to ensure critical daemons started cleanly. A fresh update often touches systemd units, network managers, and display servers.
systemctl status
# This shows the overall system state and lists failed units at the bottom
# Look for green active running indicators across your core services
# If a unit shows failed, note the name and check its specific logs
systemctl status <unit> shows recent log lines AND state in one view. Always check status before restart.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and error messages
The most common hiccup involves GPG key verification. DNF refuses to install packages if the repository signature cannot be validated. You will see a transaction error that blocks the upgrade.
Error: GPG check FAILED
Public key for package-1.0-1.fc40.x86_64.rpm is not installed
This usually means the keyring cache is corrupted or the repository metadata is out of sync. Clear the cache and force a fresh key download.
sudo dnf clean all
# This removes cached metadata, headers, and package files
# It forces DNF to rebuild the repository index from scratch
sudo dnf upgrade --refresh
# Retry the upgrade with a clean slate
Another frequent issue involves SELinux denials during the first boot after an update. Fedora ships with SELinux in enforcing mode by default. If you see permission errors in your logs, do not disable SELinux. The denials usually point to a context mismatch on a newly created directory or a misconfigured service.
journalctl -t setroubleshoot
# This filters the journal for SELinux alert summaries
# Each line includes a URL to a detailed explanation and fix
# Follow the suggested restorecon or policy module steps
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
Network configuration changes sometimes follow a kernel or driver update. If you modify firewall rules or interface names, apply the changes immediately.
sudo firewall-cmd --reload
# This applies persistent firewall rules to the running system
# Without this step, the runtime config and persistent config diverge
# Services may appear offline even though the rules are saved
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Check the transaction journal before forcing anything. DNF keeps a record of every successful and failed operation.
Choosing your update path
Use dnf upgrade --refresh when you want to synchronize your system with the current Fedora release. Use dnf system-upgrade download --releasever=42 when you are crossing major release boundaries and need a staged upgrade. Use dnf update when you are on an older DNF version that does not recognize the upgrade alias. Use dnf distro-sync when you accidentally installed packages from a different release and need to force everything back to the current branch. Stay on the standard upgrade command for routine maintenance.
Verify the transaction before committing. DNF will show you exactly what will be installed, removed, or downgraded. Read that list. If a critical service is marked for removal, abort and investigate the dependency chain.