You hit a GPG wall during an update
You run sudo dnf upgrade on a Tuesday morning. The terminal spits out a wall of red text ending with Package Does Not Match Intended Download. The update stops. Your system is stuck with half-updated metadata. You need to fix this before the package manager refuses to do anything else.
This error blocks the update to protect your system. The package manager detected a signature mismatch and aborted the transaction. Your system is safe, but you cannot install or upgrade packages until the trust chain is restored.
What is actually happening
Fedora signs every package with a GPG key before it enters the repositories. The signature proves the package came from Fedora and has not been modified. When you run dnf, the package manager downloads the package and checks the signature against the GPG keys trusted by your system.
The error occurs when the key used to sign the package does not match any key in your local trust database. This usually happens during a key rotation. Fedora rotates GPG keys periodically, often at the start of a major release or after a security incident. When the key changes, new packages are signed with the new key. Your system still trusts the old key. The package manager sees a signature it does not recognize and blocks the install.
Think of it like a building security badge. The badge has a photo and a digital signature. The database at the door holds the authorized signatures. If the database is outdated and the badge uses a new signature format, the door stays locked. The badge is valid, but the database needs an update.
Anatomy of the error message
The error output contains specific details that tell you exactly what went wrong. Read the error carefully before running commands. The message usually includes the package name and the key ID that failed verification.
Error: GPG check FAILED
Package Does Not Match Intended Download
Public key for package-1.0-1.fc40.x86_64.rpm is not installed
The line Public key for ... is not installed means your system has no record of the key that signed this package. The error might also show a key ID like key ID 0xABCDEF12. That ID is the fingerprint of the missing key. You will use this ID to verify the fix.
Check the error message for the key ID. Importing the wrong key is worse than no key.
Import the correct GPG key
The fix is to import the missing GPG key into your RPM database. Fedora hosts the official keys on the download server. The key URL depends on your Fedora release. The error message often points to the key, or you can construct the URL based on your release version.
Here is how to import the primary Fedora GPG key for your release. Replace 40 with your current release number if you are not on Fedora 40.
sudo rpm --import https://download.fedoraproject.org/pub/fedora/linux/releases/40/Everything/x86_64/os/RPM-GPG-KEY-fedora-40-primary
# WHY: Downloads the public key from the official Fedora repository and adds it to the RPM database.
# WHY: This tells the package manager to trust signatures made with this specific key.
# WHY: The --import flag updates the local keyring without modifying package files.
If you are using a third-party repository like RPM Fusion or Copr, the base Fedora key will not fix the error. Those repositories use their own keys. Import the key provided by the repository maintainer. The repository documentation always includes the import command.
Import the key before you force anything. Forcing GPG checks opens the door to tampered packages.
Clean the metadata cache
After importing the key, the package manager might still hold onto old metadata that references the previous key state. Clearing the cache forces dnf to rebuild its local database using the new trust information.
Here is how to purge the cache and prepare for a fresh metadata fetch.
sudo dnf clean all
# WHY: Removes all cached metadata and package files from the local system.
# WHY: Forces dnf to fetch fresh metadata from the repositories on the next run.
# WHY: Prevents conflicts between old metadata and newly imported keys.
Fedora releases new updates frequently. Running sudo dnf upgrade --refresh is the standard weekly maintenance command. The --refresh flag forces dnf to download fresh metadata, which often resolves transient GPG issues caused by delayed mirror synchronization. Use --refresh as part of your routine to avoid stale metadata problems.
Run dnf clean all after every key import. Stale cache is the most common cause of persistent GPG errors.
Rebuild the repository cache
With the key imported and the cache cleared, rebuild the metadata cache. This step validates the repository signatures using the new key. If the import was successful, this command will complete without errors.
Here is how to rebuild the cache and verify the repository connection.
sudo dnf makecache
# WHY: Rebuilds the local metadata cache by downloading the latest repository information.
# WHY: Validates the repository signatures using the newly imported key.
# WHY: If this succeeds, the GPG error is resolved and the system is ready for updates.
If makecache fails, check your repository configuration. A misconfigured repository can cause GPG failures even if the key is correct.
Check the repo file. A typo in the gpgkey path breaks trust instantly.
Verify the fix
Run a check update to confirm the package manager can read metadata and verify signatures successfully. This command queries the repositories without installing anything.
Here is how to verify the trust chain is restored.
sudo dnf check-update
# WHY: Queries repositories for available updates without installing them.
# WHY: Confirms the package manager can read metadata and verify signatures successfully.
# WHY: A clean output with version lists means the GPG error is resolved.
If the output lists available updates without errors, the fix worked. You can now proceed with sudo dnf upgrade. If the error persists, review the next section on common pitfalls.
Run dnf check-update before dnf upgrade. If the check fails, the upgrade will fail too.
Inspect the imported key
It is good practice to verify the key you imported matches your expectations. The RPM database stores metadata about every installed key. You can query this database to check the key ID and timestamp.
Here is how to list and inspect the GPG keys in your system.
rpm -qa gpg-pubkey*
# WHY: Lists all GPG keys currently installed in the RPM database.
# WHY: Each key has a unique ID and timestamp.
# WHY: Verify the timestamp matches the release date of your Fedora version.
The output shows keys in the format gpg-pubkey-<keyid>-<timestamp>. The key ID should match the ID shown in the error message. The timestamp indicates when the key was imported. If you see multiple keys with the same ID, the newer timestamp takes precedence.
If the key ID does not match the error, you imported the wrong key. Remove the incorrect key and import the correct one.
Verify the key ID. Importing the wrong key is worse than no key.
Common pitfalls and error patterns
Forcing GPG checks
You might see advice to add --nogpgcheck to your command. Do not do this. That flag disables signature verification entirely. You are telling the package manager to trust any file the server sends, even if it has been modified in transit. Use this only if you are building packages locally and know exactly what you are doing.
Never disable GPG checks on a production system. The risk of a compromised package outweighs the inconvenience of a key mismatch.
Corrupted mirrors
If the key import works but the error persists, the mirror you are using might have corrupted metadata. Fedora uses a network of mirrors. Occasionally, a mirror falls out of sync or serves bad data.
Here is how to check your repository status and switch mirrors if needed.
dnf repolist
# WHY: Lists all enabled repositories and their metadata status.
# WHY: Look for repositories marked as "disabled" or with errors.
# WHY: A misconfigured repo can cause GPG failures even if the key is correct.
If a mirror is failing, dnf usually switches automatically via the metalink. If the metalink is broken, you can force a mirror change or wait for the mirror network to heal.
Third-party repository keys
Third-party repositories like RPM Fusion, Flatpak, or Copr use their own GPG keys. The Fedora base keys do not cover these packages. If you see a GPG error after adding a third-party repo, you need to import that repository's specific key.
The repository maintainer provides the import command. Do not guess the key URL. Importing a key from an untrusted source compromises your system.
Check the repository documentation. Third-party keys are never included in the base Fedora keyring.
Repository configuration details
Understanding the repository configuration helps you debug GPG issues. Repository files in /etc/yum.repos.d/ define how dnf connects to each repository. The gpgcheck and gpgkey directives control signature verification.
Here is an example of a standard Fedora repository configuration.
[fedora]
name=Fedora $releasever - $basearch
# WHY: Defines the human-readable name for the repository.
baseurl=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
# WHY: Points to the metalink file which redirects to the fastest mirror.
enabled=1
# WHY: Enables the repository for package resolution.
gpgcheck=1
# WHY: Enforces GPG signature verification for all packages in this repository.
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
# WHY: Specifies the path to the trusted GPG key file for this repository.
The gpgkey directive points to a key file on the local system. Fedora stores these files in /etc/pki/rpm-gpg/. Files in /etc/ are user-modified. Files in /usr/lib/ ship with packages. Edit /etc/. Never edit /usr/lib/. The fedora-gpg-keys package manages the key files in /etc/pki/rpm-gpg/. When you upgrade the system, this package updates the key files automatically.
If the gpgkey path is wrong, dnf cannot find the key. Verify the path matches the actual file location.
Trust the package manager. Manual file edits drift, snapshots stay.
Decision matrix
Use rpm --import when the error explicitly mentions a missing or mismatched GPG key ID.
Use dnf clean all when metadata is stale or you suspect a cache corruption after a key change.
Use dnf config-manager --setopt=... when a specific mirror is returning bad data and the key is correct.
Use dnf upgrade --refresh for routine maintenance to prevent stale metadata issues.
Avoid --nogpgcheck unless you are debugging a local build and accept the security risk.
Use dnf system-upgrade when crossing major releases, as key rotations often happen during release transitions.
Check the key ID. Importing the wrong key is worse than no key.