Errors occurred, no packages were upgraded.

This is pacman’s summary line, not the error. It means the transaction was rolled back before anything was written, so your system is in the same state it was in before you ran the update. The cause is on the lines above it.

The fix

1. Find the real error. The whole update run is recorded to a log, so open that rather than scrolling the terminal:

   grep -nE "^error:|exists in filesystem|is corrupted|404|signature" /tmp/omarchy-update.log | tail -40

   The log lives at /tmp/omarchy-update.log and is wiped on reboot. Read it first.

2. Run the update once more. Several of the reported failures are transient: a mirror that was mid-sync, a download that stalled, a Wi-Fi drop during the transfer. In issue #3357 the reporter got through after repeated attempts with no other change.

   omarchy update

   On 3.x the command is omarchy-update, and omarchy update also works from 3.7 on.

3. If the error mentions failed to retrieve some files, a 404, or a TLS failure, your pacman config or database has drifted from the mirrors Omarchy uses. Reset both:

   omarchy-refresh-pacman

   That backs up /etc/pacman.conf and /etc/pacman.d/mirrorlist to .bak, rewrites them from the channel defaults, and runs a full pacman -Syyuu. Pass rc or edge as an argument only if you are deliberately on that channel. This is what DHH recommended first in issue #4197.

4. If the error mentions a signature, marginal or unknown trust, or invalid or corrupted package, clear the cached download and rebuild the keyrings:

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

   Clearing the cache was DHH’s next suggestion in issue #4197, and the keyring reinit is what finally cleared it for the reporter. In issue #4594 a plain sudo pacman -Sy archlinux-keyring was enough. If the missing key is the Omarchy one (F0134EE680CAC571), import it by hand:

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

   Since 3.1.4 the update’s keyring step installs omarchy-keyring and fetches that key itself when it is absent, so needing the commands by hand usually means the keyserver fetch failed. When --recv-keys fails with “Server indicated a failure”, download the key as a file from keys.openpgp.org and import it with sudo pacman-key -a <file>.asc, then run the --lsign-key line. That is the workaround from issue #2916.

5. If the error is conflicting files with lines like pkg: /some/path exists in filesystem, check who owns each path before touching it:

   pacman -Qo /some/path

   If pacman reports no owner, move it aside and retry. Keep a copy somewhere outside the directory it came from, because some directories are scanned wholesale.

   sudo mkdir -p /var/lib/omarchy/replaced/some
   sudo mv -T /some/path /var/lib/omarchy/replaced/some/path
   omarchy update

6. If the error is unresolvable package conflicts detected or failed to prepare transaction (conflicting dependencies), pacman needed a yes or no answer and answered it with No. Run omarchy update from a real terminal without -y. On 4.x the update reruns the upgrade interactively so you can answer the replacement prompt yourself.

Verify it worked

The update ends without the red “Something went wrong during the update!” banner. After it finishes:

pacman -Qu
omarchy-version

pacman -Qu should print nothing, and omarchy-version should show the release you expected. If you moved files aside in step 5, check whether /var/lib/omarchy/replaced now holds anything you still need before deleting it.

Why it happens

Pacman is all or nothing. It resolves the transaction, downloads every package, verifies every signature, and checks every file it is about to write. Any failure in that sequence aborts the whole thing and prints Errors occurred, no packages were upgraded. So the summary is always the same regardless of cause, and there are four common causes.

Mirror and network problems. Omarchy serves packages from its own mirrors, and the stable channel runs about a month behind Arch, so a package that exists upstream can be missing from the Omarchy mirror. Issue #3650 is a plain 404 from the stable mirror, hit during a yay install rather than an update, but the same mirror serves both. Issue #3357 is the other shape: repeated download stalls during the update. One commenter suggested setting ParallelDownloads = 1 in /etc/pacman.conf so pacman fetches sequentially, and two got through by temporarily disabling IPv6.

Signature and keyring drift. SigLevel = Required DatabaseOptional is the shipped default, and 4.0.2 tightened this further by requiring signed packages from the Omarchy repository. A stale archlinux-keyring, a cached package that was truncated mid-download, or a maintainer key you have never trusted all produce a corruption or trust error. Issue #4594 is a clean example, where a marginal-trust signature on libvpl ended the transaction.

File conflicts. Pacman refuses to write over a file no package owns. Omarchy 4 handles the common case itself: omarchy-update-system-pkgs runs pacman -Syu --noconfirm --overwrite '/usr/share/omarchy/*', captures stderr, and on failure hands off to a retry helper that moves unowned files reported against Omarchy’s own packages (omarchy, omarchy-settings and their -dev variants) into /var/lib/omarchy/replaced and tries again, putting anything the upgrade did not take back afterwards. That helper only acts when every reported conflict belongs to those packages, which is why issue #9142 stays wedged: thousands of unowned files under /usr/lib/modules/ left behind by kernel-modules-hook are outside its remit. That issue is still open, with a proposed fix in PR #9285.

Package conflicts. Two packages that cannot coexist need a human decision. Issue #7059 is the textbook case, from a menu install rather than an update but through the same --noconfirm path: bitwarden-cli wants nodejs-lts-jod while an earlier Zed install pulled in nodejs, and --noconfirm answers the replacement prompt with No.

3.x behaved differently here. omarchy-update-system-pkgs on v3.8.4 is two lines, a plain pacman -Syyu --noconfirm, with no conflict handler and no retry. On 3.x every one of these failures lands in your lap.

If that did not work

Check whether the failure is actually in a later stage. omarchy update runs the keyring step, then system packages, then migrations, then AUR packages. A failure after the pacman stage is a different problem: issue #3877 is the well-known one, where yay stopped loading after a libalpm soname bump and several people fixed it by rebuilding yay from the AUR.

If the update is failing at migrations rather than at pacman, see migration failed mid-update. If it hangs rather than errors, see omarchy update fails or hangs.

When you are out of ideas, roll back. Omarchy takes a Snapper snapshot before each update, so you can return to the pre-update state with rollback with snapper and limine, then try again once the mirror has caught up.

Related

• failed to retrieve some files
• signature is unknown trust
• pacnew and pacsave files after update
• before you update checklist
• release channels
• Omarchy Manual: Updates