The upgrade stops at a dependency conflict
You run sudo dnf system-upgrade download --releasever=41 and the transaction aborts. The terminal prints Error: Problem: package kernel-core-6.7.x conflicts with kernel-core provided by kernel-6.6.y. You installed that RPM Fusion repo last year. You added that proprietary driver repo six months ago. Now the upgrade is stuck, and you are staring at a dependency error that wasn't there yesterday.
The system is safe. The package manager stopped the process to prevent a broken state. The conflict comes from a third-party repository providing a package that clashes with the official Fedora packages. You need to isolate the upgrade to the curated repositories, complete the transition, and then restore your third-party sources.
Run the check before the upgrade. A broken transaction is harder to fix than a paused one.
What's actually happening
Fedora's package manager, dnf, builds a dependency graph before installing anything. It checks every package against every other package to ensure file ownership, version requirements, and library compatibility. Official Fedora repositories are curated together. They move in lockstep. The kernel, the glibc, and the core utilities are tested as a set.
Third-party repositories operate on their own schedule. They might hold an older version of a library that Fedora just updated. They might provide a package with the same name as a Fedora package. They might use a different GPG key that hasn't been refreshed. When you enable a third-party repo during an upgrade, dnf sees two sources for the same dependency. It tries to satisfy both. The result is a conflict. The upgrade stops to protect your system from breaking.
Think of the official repos as a synchronized orchestra. Third-party repos are soloists playing their own sheet music. If you ask the soloist to join the orchestra mid-performance without a conductor, the harmony breaks. You need to mute the soloists while the orchestra rehearses the new piece.
Convention aside: dnf upgrade --refresh is your weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases like 40 to 41. They are different tools. Do not use system-upgrade for routine updates.
Identify the conflicting repositories
Before you disable anything, check which repositories are active. You need to distinguish between official Fedora sources and third-party additions.
Here's how to list all enabled repositories and spot the external sources.
sudo dnf repolist enabled
# List all active repositories to identify third-party sources
# Look for names like 'rpmfusion-free', 'google-chrome', or custom URLs
# Official repos usually start with 'fedora', 'updates', or 'updates-testing'
# The output shows the repo ID and the number of available packages
If you see a repo ID that doesn't match the Fedora naming convention, that is a candidate for disabling. Common third-party repos include rpmfusion-free, rpmfusion-nonfree, google-chrome, brave-browser, and custom repos for drivers or proprietary software.
Here's how to check which repository provides a specific package that might be causing a conflict.
dnf repoquery --whatprovides kernel-core
# Find which repository provides a specific package
# This helps identify if a third-party repo is shadowing a Fedora package
# The output shows the repo ID in parentheses next to the package name
# If multiple repos provide the same package, you have a potential conflict
Run the query for any package mentioned in the error message. If a third-party repo appears in the results for a core system package, that repo is likely the culprit.
Disable third-party repos for the upgrade
The safest approach is to disable third-party repositories only for the upgrade transaction. This keeps your configuration files intact and avoids permanent changes to your system. You use the --disablerepo and --enablerepo flags to control sources on a per-command basis.
Here's how to run the system upgrade while restricting sources to official Fedora repositories.
sudo dnf system-upgrade download --releasever=41 --disablerepo='*' --enablerepo='fedora,updates,updates-testing'
# Disable all repos for this transaction, then re-enable only official Fedora sources
# This keeps your /etc/yum.repos.d/ files untouched
# The upgrade pulls only from the curated Fedora repositories
# Replace 41 with your target release number
# The --enablerepo flag ensures the upgrade still has access to updates
This command tells dnf to ignore every repository except the official Fedora ones for this specific run. Your third-party repo files remain in /etc/yum.repos.d/, but they are inactive during the download phase.
Convention aside: Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. If you find repo files in /usr/lib/yum.repos.d/, those are managed by packages. Do not touch them. Your custom repos should live in /etc/yum.repos.d/.
If you prefer to disable a repository permanently because you no longer need it, use config-manager. This writes the change to the repo file.
sudo dnf config-manager --set-disabled rpmfusion-free
# Permanently disable a specific repository
# This modifies the enabled flag in /etc/yum.repos.d/rpmfusion-free.repo
# Use this when a third-party repo is no longer needed or causes persistent issues
# You can re-enable it later with --set-enabled
Verify the kernel version after reboot. A successful download means nothing if the reboot fails.
Complete the upgrade and verify
Once the download finishes, trigger the reboot phase. The system will restart and apply the downloaded packages.
Here's how to start the reboot phase of the upgrade.
sudo dnf system-upgrade reboot
# Trigger the reboot phase of the upgrade
# The system will restart and apply the downloaded packages
# Watch the boot logs for any GPG errors or missing dependencies
# The process may take several minutes depending on hardware speed
After the system comes back up, verify that the new release is active.
cat /etc/fedora-release
# Check the current Fedora release version
# The output should match the target release you specified
# This confirms the upgrade completed successfully
Here's how to check the installed kernel version to ensure the new kernel is active.
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
# Verify the new kernel is installed and matches the target release
# The version string should reflect the new Fedora release cycle
# Multiple kernels may be listed; the newest one is usually the default
Run journalctl -xe first. Read the actual error before guessing. If the boot fails, the journal will show the exact unit that stopped.
Re-enable third-party repositories
After the upgrade, you can restore your third-party repositories. Most third-party repos update their metadata quickly to support the new Fedora release. You should re-enable them to get updates for those packages.
Here's how to re-enable a repository after the upgrade completes.
sudo dnf config-manager --set-enabled rpmfusion-free
# Re-enable a specific repository after the upgrade completes
# This writes the change to /etc/yum.repos.d/rpmfusion-free.repo
# Run this for each third-party repo you need to restore
# Check the repo's documentation to ensure it supports the new Fedora release
Some third-party repos require a manual refresh of their metadata or GPG keys after a major release jump. If you see Error: GPG check FAILED after re-enabling a repo, the key might be missing or expired.
Here's how to clean the cache and refresh metadata for a specific repository.
sudo dnf clean all && sudo dnf makecache --refresh
# Clear the local cache and force a refresh of all repository metadata
# Stale metadata can cause false conflicts or missing package errors
# This downloads the latest package lists from all enabled repositories
# Run this if dnf reports packages that you know exist
If a GPG key is missing, import it manually.
sudo rpm --import /path/to/key.gpg
# Import a missing GPG key for a third-party repository
# dnf will refuse to install packages without a valid signature
# Check the repository documentation for the correct key URL
# Never import keys from untrusted sources
Clean the cache when metadata lies. dnf clean all saves more time than guessing.
Common pitfalls and error patterns
Third-party repos introduce specific failure modes. Recognizing these patterns helps you diagnose issues quickly.
Duplicate package conflicts
If you see Error: package X conflicts with package Y, a third-party repo is likely providing a package that Fedora also provides. The conflict arises because dnf cannot decide which version to install.
Error: Problem: package kernel-6.7.0-100.fc41.x86_64 conflicts with kernel provided by kernel-6.6.0-50.fc40.x86_64
The fix is to disable the conflicting repo during the upgrade. The --disablerepo='*' approach handles this automatically.
GPG signature failures
Third-party repos may use keys that are not imported or have expired. Fedora enforces strict GPG checking.
Error: GPG check FAILED
This error means the package signature does not match the imported key. Import the correct key or update the repo configuration. Do not disable GPG checking with --nogpgcheck unless you fully trust the source. Disabling GPG checks exposes your system to tampered packages.
Stale metadata
Sometimes the repo is fine, but your local cache is outdated. dnf might think a package is missing when it is actually available.
Error: No match for argument: package-name
Run sudo dnf clean all and try again. The cache might be holding onto old data from the previous release.
SELinux denials
If a third-party service fails to start after the upgrade, check for SELinux denials.
journalctl -t setroubleshoot
# View SELinux denial messages with one-line summaries
# SELinux blocks unauthorized access to files and ports
# Read the summary to understand what was blocked
# Fix the context or policy before disabling SELinux
Convention aside: SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux masks the real problem and reduces security.
When to use this approach
Choose the right method based on your goal and the state of your system.
Use --disablerepo='*' --enablerepo='fedora,updates' when you want a clean upgrade without modifying your repository configuration files.
Use dnf config-manager --set-disabled <repo-id> when you want to permanently disable a third-party repository that is no longer needed.
Use dnf system-upgrade when you are crossing major Fedora releases like 40 to 41.
Use dnf upgrade --refresh when you are applying updates within the current release cycle.
Use Flatpak for applications when you need the latest version independent of the OS release cycle.
Trust the package manager. Manual file edits drift, snapshots stay.