pacman keyring errors and refused signatures
pacman checks a signature on every package it installs from a repository. When that check fails the message is about trust or corruption, but the cause is usually the set of keys on the machine or the clock it reads, not the package that was downloaded.
sudo pacman -Syu-S- --sync — install packages from the repositories and upgrade the system
-y- --refresh — refresh the package databases from the mirrors
-u- --sysupgrade — upgrade every installed package that is out of date
Needs root.
What it does. Refresh and upgrade in full, which is what carries a current keyring onto the machine along with everything else.
Watch out. The clock is worth checking before anything is reinstalled: a date in the past or the future makes valid keys look expired or not yet valid.
What is being checked
The check runs along a short chain, and a failure is always somewhere on it:
The keys live in /etc/pacman.d/gnupg. They arrive on the machine
as an ordinary package, so a keyring that is months out of date is simply a
package that has not been upgraded. That is why the repair usually looks like an
upgrade rather than like a key operation.
The messages and what each one means
| What pacman prints | What it is saying |
|---|---|
signature from <packager> is unknown trust | The packager key is present but nothing on this machine vouches for it, which usually means the master keys are missing or the keyring has not been filled in |
invalid or corrupted package (PGP signature) | The signature did not match the file, which is either a damaged download or a key the machine cannot check |
key <id> could not be looked up remotely | pacman tried to fetch a key it does not hold and could not reach a key server |
signature is marginal trust | The chain to the master keys exists but is weaker than the configured level in pacman.conf |
The order to try things in
Each step is cheaper and less disruptive than the one after it.
- Check the clock. A signature has a validity window, and a machine whose
date is wrong reads a good key as expired or not yet valid. This is the single
most common cause on a machine that has been switched off for a while.
not pacman
timedatectl - Try the full upgrade first. If the machine can still install anything,
this carries a current keyring along with everything else and needs no key
handling at all.
routine
sudo pacman -Syu - Upgrade the keyring package on its own. This is the step most often
quoted, and it is worth knowing what it costs: refreshing the databases and
installing one package leaves the machine in the state described on the
partial upgrade page, so the full upgrade has to
follow it.
risky
sudo pacman -Sy archlinux-keyringMarked at that level for the reason given on the partial upgrade page: a refresh without an upgrade. Run the full upgrade straight after it.
routinesudo pacman -Syu - Fill the keyring from what is already on disk. When nothing can be
installed at all, the keys in the keyring package already present can be loaded
into the keyring directly. This is not a pacman operation; it is a separate
program shipped with pacman.
not pacman
sudo pacman-key --populate archlinux - Refresh the key signatures. This reaches a key server and is the step
most likely to be blocked on a restricted network.
not pacman
sudo pacman-key --refresh-keysSlow, and it fails on a machine that cannot reach a key server. Leave it until the steps above have been tried.
Turning the signature check off in pacman.conf makes the message go away and takes the check with it. A refused signature is the one moment the check is doing its job, so switching it off is the one moment it should not be switched off.
When the download itself is damaged
If one package keeps failing while others install, the copy in the cache may be the problem rather than the keys. Deleting that one file makes pacman fetch it again on the next attempt; the cache page describes what lives there and what the cleaning commands take.
Common questions
What does signature is unknown trust mean in pacman?
It means the key that signed the package is present but nothing on the machine vouches for it. In practice the master keys are missing or the keyring in /etc/pacman.d/gnupg has not been filled in, so the chain has no anchor.
Why does pacman say a package is invalid or corrupted?
The signature did not match the file. Either the download is damaged, in which case removing that file from the cache and fetching it again is enough, or the machine cannot check the key that signed it.
Is pacman -Sy archlinux-keyring safe?
It refreshes the databases and installs one package, which is the shape of a partial upgrade. It is usable as a repair step, but the full sudo pacman -Syu has to follow it rather than being left for later.
Can a wrong clock cause pacman signature errors?
Yes. Signatures carry a validity window, so a machine whose date is far in the past or the future reads keys as expired or not yet valid. Checking the date is the cheapest first step.