Fix Omarchy update keyring errors

Why an Omarchy update fails with a keyring error

An Omarchy update that stops with invalid or corrupted package (PGP signature) is a keyring error, not a bad download. Your copy of archlinux-keyring is older than the signing keys Arch is using today, so pacman refuses a package it cannot trace back to a key it trusts. Refresh that keyring, then run the update again.

Nothing about this is special to Omarchy. It is an ordinary Arch failure mode, and Omarchy puts it in front of a lot of people whose first Arch machine is this one.

One scope note before the commands. Omarchy is an Arch-based Hyprland desktop, so everything below is about the machine on your desk. This is not a guide to installing Omarchy on a VPS. Your server runs something else, and the last section points at the pages for it.

The minimal fix

Two commands, then the update:

sudo pacman -Sy
sudo pacman -S archlinux-keyring
omarchy update

sudo pacman -S archlinux-keyring prints ==> Appending keys from archlinux.gpg... and then a slower ==> Locally signing trusted keys in keyring... pass. Those lines mean new developer keys landed in your keyring. The update that failed a minute ago now runs to the end.

That sequence is the one users reported in Omarchy issue 4608, which is also the report that put a keyring refresh into the updater itself.

pacman -Sy on its own deserves a warning. It downloads a fresh package database without upgrading the packages you already have. Installing arbitrary software from that state is a partial upgrade, and partial upgrades break Arch machines, because a freshly built package expects the library versions listed in the new database while yours are still the old ones. archlinux-keyring is the accepted exception: it ships key material rather than linked binaries, and you follow it immediately with the full upgrade.

omarchy update is the Omarchy 4 command. Omarchy 4, called Quattro, shipped in August 2026 and is the current series as of September 2026. The script behind that command is omarchy-update, which you can also run directly. Prefer either over a bare pacman -Syu, because the Omarchy updater takes a filesystem snapshot first and runs the migrations that keep your configuration in step with the new release. A manual pacman -Syu skips both.

What omarchy update keyring does

Omarchy 4 exposes the keyring step on its own:

omarchy update keyring

It handles two separate keyrings. It always runs sudo pacman -Sy --noconfirm archlinux-keyring, and the reason it reinstalls instead of comparing versions first is stated in the script: the contents of that keyring can change without the package version changing. It also fetches and locally signs the Omarchy signing key when that key is missing:

sudo pacman-key --recv-keys 40DFB630FF42BCFFB047046CF0134EE680CAC571 --keyserver keys.openpgp.org
sudo pacman-key --lsign-key 40DFB630FF42BCFFB047046CF0134EE680CAC571

Two keyrings, because your machine installs from two places. archlinux-keyring is Arch's own package from the core repository, and it carries the keys of Arch developers and trusted users. omarchy-keyring is third party. It comes from the [omarchy] repository that Omarchy adds to /etc/pacman.conf, which on the stable channel is Server = https://pkgs.omarchy.org/stable/$arch, and it carries the key that signs every omarchy-* package. Omarchy 4 ships SigLevel = Required DatabaseOptional, so a package whose signature does not resolve to a trusted key is rejected whichever repository it came from.

Why unknown trust is a key problem and not a download problem

The failure looks like this. The package name and the signer change from machine to machine. The last two lines do not.

error: archlinux-keyring: signature from "Christian Hesse <eworm@archlinux.org>" is unknown trust
:: File /var/cache/pacman/pkg/archlinux-keyring-20230704-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
error: failed to commit transaction (invalid or corrupted package (PGP signature))

Read unknown trust literally. gpg parsed the signature and found it well formed. What it could not do is connect the key behind that signature to a key your machine trusts. pacman then calls the package corrupt, because from where pacman stands an unverifiable package and a damaged one get the same answer.

The trusted keys live in /etc/pacman.d/gnupg. That directory is a local copy, and it is never fetched live during an update. It is seeded from the key files the archlinux-keyring package installs into /usr/share/pacman/keyrings. Arch adds developer keys and revokes them on its own schedule, so a machine that sat unused for a few months holds a list of keys that predates the developer who signed this morning's package. The related message signature from ... is marginal trust has the same root: the keys are present, but the local signatures that root them in your own keyring are missing.

Full repair when the keyring itself is broken

Sometimes sudo pacman -S archlinux-keyring fails with the very error you are trying to fix, or sudo pacman-key --list-keys returns nothing useful. The keyring is then damaged rather than stale, and it has to be rebuilt.

sudo mv /etc/pacman.d/gnupg /etc/pacman.d/gnupg.broken
sudo pacman-key --init
sudo pacman-key --populate archlinux
sudo pacman -Sy archlinux-keyring
sudo pacman-key --populate archlinux

Move the old directory instead of deleting it. If the rebuild goes wrong you can put it back, and a keyring you can restore is worth the few kilobytes it costs.

The order matters. --init creates an empty keyring with a fresh local signing key, and an empty keyring trusts nothing, so any download would fail verification at that moment. --populate archlinux fills it from /usr/share/pacman/keyrings/archlinux.gpg, the file already on your disk from the package you installed months ago. Those keys may be old, but they are enough to verify a download of the current keyring package, which is what the fourth line does. The last line loads the refreshed key files that download just delivered.

Now restore the Omarchy key. Wiping /etc/pacman.d/gnupg threw away the local signature that made it trusted, so every omarchy-* package fails with unknown trust until it is back:

sudo pacman-key --recv-keys 40DFB630FF42BCFFB047046CF0134EE680CAC571 --keyserver keys.openpgp.org
sudo pacman-key --lsign-key 40DFB630FF42BCFFB047046CF0134EE680CAC571
sudo pacman-key --list-keys 40DFB630FF42BCFFB047046CF0134EE680CAC571

The last command should print a pub line for that fingerprint. A keyserver receive failed line instead means your network is not reaching keys.openpgp.org over port 443, so fix that before retrying. On Omarchy 4 you can run omarchy update keyring in place of the first two commands, since it does exactly this pair. Finish with omarchy update.

When the keyring is current and the update still fails

The clock is wrong. Keys and signatures carry timestamps, and gpg compares them against your system clock. A clock set well in the past makes a good signature look like it was made before its key existed, so the package is rejected. Run timedatectl and look for System clock synchronized: yes. This bites laptops with a dead CMOS battery, and it bites servers for different reasons, covered in why a VPS clock drifts and how to keep it in sync.

One cached file is damaged. A download truncated by a flaky mirror produces the same invalid or corrupted package line, and no amount of keyring work will fix it. Tell the two apart by which package gets named. If it is the same package every time, delete that file from /var/cache/pacman/pkg/ and run the update again. sudo pacman -Sc clears the cached versions you no longer have installed.

The failure is in yay, not pacman. An AUR build verifies the upstream source archive with makepkg, which reads your own user keyring at ~/.gnupg. It never reads pacman's. The message is ==> ERROR: One or more PGP signatures could not be verified!, usually beside gpg: Can't check signature: No public key. Import the key as your normal user with gpg --recv-keys <key-id> and no sudo. sudo pacman-key --recv-keys cannot help, because it writes into /etc/pacman.d/gnupg, a directory makepkg does not look at.

Skip pacman-key --refresh-keys. It asks a keyserver about every key you already hold, so it is slow and it fails outright when the keyserver is busy. It also cannot add a key your keyring never had, which is the actual problem here. Updating archlinux-keyring is the supported path.

If the update already stopped halfway

Read /tmp/omarchy-update.log. That is where omarchy-update writes its output, and the first real error is usually scrolled away behind progress bars by the time you look at the terminal.

If the machine is in a worse state than when you started, use the snapshot. Omarchy takes one before an update on systems where snapper is available, so you can reboot and choose the pre-update snapshot in the boot menu. Repair the keyring from that known good state, then update again.

Your server is not your desktop

Omarchy is a desktop, and the box you SSH into is a different problem with different answers. A server wants a distribution with a long support window and no desktop stack on top, which is the subject of picking the right OS for your VPS. The first job on that box is locking down SSH with keys and a hardened sshd config, and the second is a standing maintenance routine so its packages never go as stale as this keyring did. If what you like about Omarchy is the built-in coding agent shortcuts, those agents run on a server too: running a coding agent on a VPS covers the setup, and keeping Claude Code alive in a tmux session covers the part where you shut the laptop and walk away.

FAQ

Is sudo pacman -Sy safe to run before installing archlinux-keyring?

It is safe for this one case, and only if you follow it right away with the keyring install and then a full upgrade. -Sy refreshes the package database while your installed packages stay old, and installing normal software from that state is a partial upgrade that can leave a binary linked against a library version you do not have. archlinux-keyring is data rather than linked code, so it is the standard exception. Do not stop after pacman -Sy and walk away.

Why do I still get keyring errors if Omarchy refreshes the keyring for me?

The updater refreshes archlinux-keyring before it upgrades packages, so the error usually means you did not go through the updater. Running pacman -Syu or yay by hand skips that step. The other cases are a local keyring that is damaged rather than merely stale, where the keyring package itself will not verify, and an older Omarchy release from before that step existed. The full rebuild with pacman-key --init and pacman-key --populate archlinux covers the damaged case.

What is omarchy-keyring, and is it the same thing as archlinux-keyring?

They are different packages from different places. archlinux-keyring is Arch's, from the core repository, and it holds the keys of Arch developers and trusted users. omarchy-keyring is third party. It comes from the [omarchy] repository at pkgs.omarchy.org that Omarchy adds to your pacman configuration, and it holds the key with fingerprint 40DFB630FF42BCFFB047046CF0134EE680CAC571, which signs the omarchy-* packages. Omarchy requires a valid signature from both sets, so losing either one blocks the update.

Should I run pacman-key --refresh-keys to fix a signature error?

No. It queries a keyserver about every key in your keyring, which is slow and fails when the keyserver is unreachable, and it cannot import a key that was never in your keyring. The key you are missing arrives with the archlinux-keyring package, so sudo pacman -Sy followed by sudo pacman -S archlinux-keyring is both faster and the supported route.

Can I install Omarchy on my VPS so both machines match?

Omarchy is a Hyprland desktop built for a machine with a screen, a GPU and a keyboard in front of it. On a VPS it gives you nothing to look at and a large set of desktop packages to keep updated. Run a server distribution on the VPS, keep Omarchy on the laptop, and accept that the two machines will have different package sets and different update commands.