A partial Arch upgrade leaves incompatible libraries · Linux Fix Lab

Symptoms & scope

Applications ask for a removed library soname after selective updates.
pacman itself exits with a shared-library loader error.

Relevant environment

Arch Linux rolling package sets; readelf diagnostics work even when pacman cannot load its own shared libraries.

Recognizable messages (synthetic examples)

pacman: error while loading shared libraries: libalpm.so.99: cannot open shared object file: No such file or directory

A partial upgrade is one cause; missing files or altered search paths can also produce this loader failure.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

A refreshed repository database followed by selective installation may create an unsupported mixed package set.
A locally built/AUR consumer may still target an older library ABI even after a full system upgrade.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Reads the executable’s ELF dependency metadata without launching pacman. Replace the path for a different affected native program.

readelf -d /usr/bin/pacman

Interpret the result: NEEDED sonames show the expected ABI names. A differently numbered installed library is not automatically binary-compatible.

Check 2

Reads package transaction history and recorded pacman invocations; inspect the period immediately preceding the loader failure.

rg -n "\[ALPM\] (installed|upgraded|removed)|\[PACMAN\] Running" /var/log/pacman.log

Interpret the result: Selective upgrades or -Sy followed by -S support a mixed-set hypothesis. A complete transaction can still leave external locally built packages needing a rebuild.

Evidence-guided next steps

Complete a supported full system upgrade

If pacman still runs and history shows a partial upgrade, review Arch news, preserve a recovery snapshot and complete the supported pacman -Syu transaction rather than updating only the missing library. Rebuild local/AUR consumers against the resulting current library set when they alone remain broken.

Precautions: Do not symlink an old soname to an unrelated ABI or use -Sy followed by individual package installs. Review any manual interventions first.

Recovery / rollback: Restore the complete prior package snapshot if rollback is needed; isolated library downgrades can break the consumers just upgraded.

Did this solution help you?

Share this solution #

Recover an unstartable pacman with trusted installation media

If pacman cannot start, boot verified current Arch recovery media and mount the actual installation and required boot filesystems. Follow Arch’s recovery procedure with the live environment’s pacman and its documented --sysroot support to repair a coherent target package set. Confirm the target before any write.

Precautions: A plain chroot using the broken target pacman may fail identically. A wrong root or missing boot mount can update the wrong system.

Recovery / rollback: Use the saved coherent snapshot or package/configuration backup through the same trusted recovery environment; keep recovery media available until the system boots.