signature from "..." is unknown trust

Pacman stops partway through an update and prints a line like error: tzdata: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust, the exact line apurbapokharel hit in issue #4197, usually followed by a prompt asking whether to delete the cached file and then error: failed to commit transaction. Nothing is broken on your machine. Your local pacman keyring does not yet trust the key that signed the new package.

Checked against v4.0.4, v4.0.3 and v4.0.2 source, and against the last 3.x release, v3.8.4.

The fix

Work down this list and stop as soon as an update completes.

1. Run the normal update first, from the Omarchy menu or the terminal:

   omarchy update

   In both 3.x and 4.x this calls omarchy-update-keyring before the package transaction. That script reinstalls archlinux-keyring every run, on purpose, because the keyring contents can change without the package version changing. For many people this alone is the whole fix.

2. If the update still stops, refresh the Arch keyring on its own and retry:

   sudo pacman -Sy archlinux-keyring
   omarchy update

   This is what cleared it for Gundrak and ajoabraham in issue #4594. In issue #4268 hbouttev likewise told kqualters-elastic to update archlinux-keyring on its own before retrying, and to run sudo pacman-key --refresh-keys if that was not enough.

3. If the failing line names Omarchy <pkgs@omarchy.org> rather than an Arch developer, or pacman asks Import PGP key F0134EE680CAC571, "Unknown Packager"? and then reports key "F0134EE680CAC571" could not be looked up remotely, the missing key is the Omarchy packaging key. That second form is what yapus saw in issue #2916. Trust the key directly, using the sequence dhh posted in that thread:

   sudo pacman-key --recv-keys 40DFB630FF42BCFFB047046CF0134EE680CAC571 --keyserver keys.openpgp.org
   sudo pacman-key --lsign-key 40DFB630FF42BCFFB047046CF0134EE680CAC571
   sudo pacman -Sy
   omarchy-pkg-add omarchy-keyring

   If the first command fails with Remote key not fetched correctly from keyserver, yapus worked around it by downloading the key from the keys.openpgp.org search page and importing the file:

   sudo pacman-key -a ~/Downloads/40DFB630FF42BCFFB047046CF0134EE680CAC571.asc

4. If the error now says corrupted (invalid or corrupted package (checksum)) and repeats forever no matter how often the file is downloaded, your local copy of the package database still holds the old checksum for a package the server has rebuilt, so deleting the cached file changes nothing. Force the databases to download again:

   sudo pacman -Syy
   omarchy update

   The double y is the part that matters. A plain -Sy keeps a database it believes is current. jfbourdeau traced exactly this loop in issue #6576 while re-running the 3.x to 4.x upgrade, where omarchy-keyring itself was the package that kept failing, and pacman -Syy was the workaround. If you would rather reset the mirrors and repo config at the same time, sudo omarchy-refresh-pacman rewrites /etc/pacman.conf and the mirrorlist from the Omarchy defaults for your channel and then runs pacman -Syyuu. It overwrites local edits to /etc/pacman.conf, though it does back the old file up to /etc/pacman.conf.bak first.

5. Only if all of the above fail, clear the cache and rebuild the keyring from scratch. dhh suggested the cache clear in issue #4197, and apurbapokharel plus moritzuehling landed on the rebuild:

   sudo rm -rf /var/cache/pacman/pkg/*
   sudo pacman-key --init
   sudo pacman-key --populate archlinux
   sudo pacman -Sy archlinux-keyring
   omarchy update

What not to do

Do not add SigLevel = Never or SigLevel = Optional TrustAll to /etc/pacman.conf to push the transaction through. It disables the check for good and nothing puts it back. Do not delete /etc/pacman.d/gnupg as a first move, since pacman-key --init recreates it anyway and a half deleted keyring is harder to reason about. Do not run a bare sudo pacman -Syu to work around it either. Omarchy 4.x installs omarchy-update-pacman-guard, which blocks direct system upgrades and tells you to use omarchy update instead.

Verify it worked

Check that the Omarchy key is present and locally signed:

sudo pacman-key --list-keys 40DFB630FF42BCFFB047046CF0134EE680CAC571
pacman -Q archlinux-keyring omarchy-keyring

On 4.0.2 and later, the [omarchy] block in /etc/pacman.conf should have no SigLevel line of its own, so it inherits the global SigLevel = Required DatabaseOptional:

grep -A2 '^\[omarchy\]' /etc/pacman.conf

Then run omarchy update once more and let it finish through migrations without an error.

Why it happens

Two separate keyrings are in play.

Arch packages from core, extra and multilib are signed by Arch developers and trusted users. Their keys live in the archlinux-keyring package. Those keys rotate, expire and get added as people join and leave. If your machine has been off for a while, or an install media snapshot is old, a package can arrive signed by a key your local keyring has never seen. Pacman reports that as unknown trust rather than as a bad signature, because it can read the signature fine and just has no reason to believe the signer.

Omarchy packages from the [omarchy] repo are signed by a different key, Omarchy <pkgs@omarchy.org>, fingerprint 40DFB630FF42BCFFB047046CF0134EE680CAC571. That key is not in archlinux-keyring, a point phush0 made in issue #2916. It ships in the omarchy-keyring package, and the manual lists the same fingerprint under Signing Keys.

This is why omarchy-update-keyring exists, and it works the same way in v3.8.4 and v4.0.4. It checks whether omarchy-keyring is missing or the fingerprint is absent from pacman-key --list-keys, receives and locally signs the key if so, and then reinstalls archlinux-keyring on every single run.

What changed in 4.0.2

Until then the [omarchy] repo carried SigLevel = Optional TrustAll in the shipped pacman.conf, which you can see in the v3.8.4, v4.0.0 and v4.0.1 source. Signatures were effectively not enforced for that repo. Issue #2712, filed by MrJack91 and argued out at length by alerque and ryanrhughes, pushed for real enforcement. ryanrhughes announced there on 2025-10-26 that every package going into the repo would be signed from then on, and posted the same receive and lsign pair two days before dhh repeated it in issue #2916. v4.0.2 shipped enforcement as “Require signed packages from the Omarchy repository”, and a migration removes the override from existing installs, after first making sure the key is trusted so it cannot lock you out of the transaction that would repair it. drneb99 filed issue #9199 the day before, showing a 4.0.1 machine that still had the old line.

The practical effect is that a machine upgraded past 4.0.2 with a keyring that never picked up the Omarchy key will now stop instead of silently accepting the package. That is the intended behaviour, and the fix is step 3 above.

If that did not work

Read the error line carefully, because is invalid is not the same as is unknown trust. Invalid means the signature does not match the file, which is usually a repository or mirror problem rather than yours. In issue #3466 a run of packages including wayfreeze failed that way and dhh fixed it server side within a day. If you see invalid, wait an hour and retry before touching your keyring.

If the failure is on retrieving the .sig file rather than verifying it, that is a mirror issue too. osharko reported in issue #5083 that stable-mirror.omarchy.org rejected signature downloads over a size cap, which shows up as a retrieval failure, not a trust failure. See failed to retrieve some files.

A badly wrong system clock will also make signature checks fail, since GPG compares timestamps. Check timedatectl before anything more invasive. That is general Arch behaviour rather than something reported against Omarchy, so treat it as a cheap thing to rule out.

The issue count above is for keyring problems as a whole. Only a minority of those threads are signature trust failures, and no single one is the canonical report, which is why the steps are assembled from several.

Related

• Errors occurred, no packages were upgraded
• failed to retrieve some files
• omarchy update fails or hangs
• Signing key and ISO verification
• Release channels
• omarchy-refresh-pacman