# pacman -Syu: Sync and Upgrade Arch Safely

> pacman -Syu refreshes the database and upgrades all packages on Arch. Reference for why partial upgrades break, --noconfirm, and the keyring errors in CI.

Source: https://latchkey.dev/learn/command-reference/pacman-syu  
Updated: 2026-06-30

pacman -Syu refreshes the package database and upgrades every installed package in one step, the supported way to update Arch.

Arch is rolling-release, so mixing an old system with new packages (a partial upgrade) is unsupported. -Syu keeps the system consistent.

## What it does

pacman -Syu syncs the package database (-y) and then upgrades all packages to the newest version (-u). Doing both together avoids partial upgrades, where a freshly synced database is used to install a package against an un-upgraded system.

## Common usage

```Terminal
pacman -Syu --noconfirm
# refresh keyring before a big upgrade in a stale image
pacman -Sy --noconfirm archlinux-keyring && pacman -Su --noconfirm
```

## Options

| Flag | What it does |
| --- | --- |
| -Syu | Refresh database and upgrade all packages |
| --noconfirm | Do not prompt for confirmation |
| -Syyu | Force-refresh the database, then upgrade |
| -u | Upgrade installed packages (without a fresh sync) |
| -y | Refresh the package database only |

## In CI

Never run pacman -Sy <pkg> to install a single package on a stale image; that is a partial upgrade and can pull in a library newer than the rest of the system. Use pacman -Syu to update fully, or pacman -S with a recently synced but not upgraded system only for short-lived containers.

## Common errors in CI

"error: failed to commit transaction (invalid or corrupted package)" during upgrade usually means an outdated keyring; update archlinux-keyring first. "warning: <pkg>: local (X) is newer than core (Y)" indicates the mirror is behind. "unable to lock database" means a stale /var/lib/pacman/db.lck; delete it. A partial upgrade often surfaces later as a missing shared library.

## Using this in CI

A runner shell is not a login shell. It does not read your dotfiles, it usually has no TTY, and by default it does not stop on the first error, so a failing command in the middle of a multi-line `run` block can leave the job green.

```.github/workflows/ci.yml
# make the shell behave the way you assume it does
- name: Build
  shell: bash
  run: |
    set -euo pipefail    # exit on error, undefined vars, and pipeline failures
    ./do-the-thing | tee out.log
```

> Without `pipefail`, a pipeline exits with the status of the LAST command, so `failing-cmd | tee log` reports success. Piping to `tee` for logging is the single most common way a broken build reports green.

## FAQ

### pacman -Syu: Sync and Upgrade Arch Safely?

Arch is rolling-release, so mixing an old system with new packages (a partial upgrade) is unsupported. -Syu keeps the system consistent.

### What it does?

pacman -Syu syncs the package database (-y) and then upgrades all packages to the newest version (-u). Doing both together avoids partial upgrades, where a freshly synced database is used to install a package against an un-upgraded system.

### In CI?

Never run pacman -Sy <pkg> to install a single package on a stale image; that is a partial upgrade and can pull in a library newer than the rest of the system. Use pacman -Syu to update fully, or pacman -S with a recently synced but not upgraded system only for short-lived containers.

### Common errors in CI?

"error: failed to commit transaction (invalid or corrupted package)" during upgrade usually means an outdated keyring; update archlinux-keyring first. "warning: <pkg>: local (X) is newer than core (Y)" indicates the mirror is behind. "unable to lock database" means a stale /var/lib/pacman/db.lck; delete it.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt