TL;DR: Both pamac CLI and the pamac-manager GUI are unreliable for system upgrades. They are prone to crashing in the middle of an update, leaving the user with no feedback that the upgrade is continuing in the background.
Having previously tried to do a system update using the GUI, followed by the GUI crashing and the update continuing in the background, this time I tried the commandline:
$ pamac upgrade
…
Total download size: 1.4 GB
Total installed size: -1.1 GB
Apply transaction ? [y/N] y
Download of firefox (146.0.1-1) started
Download of firefox (146.0.1-1) finished
Download of rust (1:1.92.0-1) started
Download of linux612 (6.12.63-1) finished
Download of wine (10.20-2) started
Download of rust (1:1.92.0-1) finished
Download of linux612-headers (6.12.63-1) started
Download of blender (17:5.0.1-1) finished
Download of webkit2gtk-4.1 (2.50.4-1) started
809.4 MB/1.4 GB About 43 seconds remaining[1] 1202062 terminated pamac upgrade
Then I tried again:
$ pamac upgrade
pamac: error while loading shared libraries: libalpm.so.15: cannot open shared object file: No such file or directory
I’m going to assume pamac is just a broken tool for system upgrades.
Minutes later, I tried pacman:
$ sudo pacman -Syu
:: Synchronising package databases...
core is up to date
extra is up to date
multilib is up to date
:: Starting full system upgrade...
there is nothing to do
Hmm… Did the upgrade happen in the background? What has just happened? Let me try pamac again:
$ pamac upgrade
Synchronizing package databases...
Refreshing AUR...
Nothing to do.
…
(plus a few extra AUR updates)
So, yeah, yet again pamac crashed, and the updated continued in the background with NO user feedback whatsoever.
Yes, I’ve seen occasional reports of something similar – as I recall, user systems were in an unsupported state at the time, for various reasons. I’ve never experienced it myself. However, search the forum and you might find a topic or three about it that might be helpful.
The suggested command is:
pamac update --no-aur
when performing a large update.
I was recently made aware of another option (topgrade) which you might find of interest. The script handles virtually everything including repo packages, software sourced via the AUR, flatpack containerised apps, and even homebrew (for Linux) if one happens to have it installed:
sudo pacman -S topgrade
It takes one simple command topgrade – sudo is not required as the script will prompt you for your password when elevated privileges are needed.
Your post has been moved to a dedicated topic.
Please provide your system information as described (below) along with any useful detail that might help others to help you.
Regards.
System Information
While information from *-fetch type apps might be fine for someone wishing to buy your computer, for Support purposes it’s better to ask your system directly;
Output of the inxi command (with appropriate parameters, and formatted according to forum guidelines) will generate information useful for those wishing to help:
I think you are using unstable branch with pacman 7.1 which provides libalpm 16.
So I am thinking because you are running pamac to do the upgrade then pamac will upgrade itself then, the in memory version of pamac will look for libalpm 15 which has been removed and thus shut down unexpectedly.
It wasn’t intended to solve an issue; it was intended as an alternative that might have been of interest. Yes, it’s a script, or a wrapper, if that’s what you prefer to call it.
You may have a fundamental misunderstanding of the process, and in particular, the relationship between Arch and Manjaro branches.
TL/DR: Most packages comprising Manjaro are inherited from Arch Linux, who in turn receive those same packages from whosoever is the “upstream” developer/maintainer/organisation.
Manjaro cannot update any of these packages without it first being available from Arch Stable – from there, it must proceed to Manjaro Unstable, Manjaro Testing and finally Manjaro Stable.
Manjaro has to wait as often as you or I for most packages.
Looking at pacman as one example (which uses libalpm), you’ll notice the same version currently in all branches, including Arch Stable:
mbn info pacman -q
Branch : archlinux
Name : pacman
Version : 7.1.0.r7.gb9f7d4a-1
Repository : core
Build Date : Fri 12 Dec 2025 23:33:39
Packager : Antonio Rojas <arojas@archlinux.org>
Branch : unstable
Name : pacman
Version : 7.1.0.r7.gb9f7d4a-3
Repository : core
Build Date : Thu 18 Dec 2025 13:44:08
Packager : Philip Mueller <philm@manjaro.org>
Branch : testing
Name : pacman
Version : 7.1.0.r7.gb9f7d4a-3
Repository : core
Build Date : Thu 18 Dec 2025 13:44:08
Packager : Philip Mueller <philm@manjaro.org>
Branch : stable
Name : pacman
Version : 7.1.0.r7.gb9f7d4a-3
Repository : core
Build Date : Thu 18 Dec 2025 13:44:08
Packager : Philip Mueller <philm@manjaro.org>
As you can hopefully now appreciate, it’s not simply a case that “Manjaro should update a random-package”.
As far as the issue itself is concerned, I have every confidence that any problem will be identified and fixed in due course.
Until then consider using yay or another AUR helper.
An easy solution would be to not link to the *.so.xx but to the *.so file, however I didn’t saw any crashes on my end when an update was performed. Might only happen mid-update when some download error or something else happens and some parts got updated already …
If that’s the case, maybe pamac should be more conservative whenever pacman-related packages are going to be updated. MAYBE in such cases pamac should do a two-step process: first download everything, and then start the actual update.
Or maybe pamac should actually be executed as two processes:
The parent process wouldn’t depend on libalpm or anything else, and its sole purpose is to monitor the child process. Due to not depending on other libraries and due to simplified logic, this parent process shouldn’t crash at all. It should be resilient.
The child process would be the actual pamac that actually interacts with the packages.
Whenever an update starts, the parent process should observe if the child pamac crashes. If it does, for whatever reason, then the parent process should be able to recover from it, even if that means a partial recovery. After all, if pamac crashes, the upgrade already continues happening in background by some other process; thus the parent process should be able to fork a new child that would contact with that background process.
In the worst case, the new child process could be equivalent to tail -f on whatever the pacman/pamac daemon is doing. This would be a partial recovery. The user would still be able to see some feedback, even though the user wouldn’t be able to interact/stop it at all. (If this was a GUI, this partial recovery would be a minimalist dialog that outputs the results of the logs, but without the normal pamac-manager buttons and widgets.)
As a developer myself, I know this is easier said than done. It’s not unfeasible, but requires some work to get it implemented correctly. Additionally, I understand it’s difficult to fix something that cannot be easily reproduced.
As mentioned, this isn’t the first time I’ve seen similar issues mentioned in the forum, where the update would seem to freeze or stall in the GUI, but complete in the background, regardless.
For a long while the general recommendation when using pamac was to maintain separation between software sources;
Effectively, a two step process:
1. Update packages from the Manjaro repo(s):
pamac update --no-aur
2. Build/update software sourced via the AUR:
pamac update --aur
It seems pamac was changed sometime earlier this year to handle that separation internally. Whether it was believed that not having that separation contributed in some way to the issue at hand, I can’t say, but if so, those changes haven’t helped.
If I recall correct, pamac was alleged to be less reliable than another AUR helper that had a 2 stage process, and that it was possible to have an AUR package replace a repository package
Once again, pamac GUI crashed and disappeared while the update continued running in background. This happened while the updates were still being downloaded. As a workaround, I had to open htop and keep monitoring the CPU usage to have a feeling of when the update was completed.
This time, AFAIK, neither libalpm nor any pacman/pamac-related package was updated.
Could this potentially happen because I had uninstalled packagekit and packagekit-qt5 and packagekitd years ago?
If you don’t use any Snaps or FlatPaks, then, given that you are on Plasma, I recommend using octopi as a graphical package manager. It acts as a direct GUI front-end to pacman and to an AUR helper — we recommend installing yay for that.
Why? I’m curious to know why we should prefer one over another.
Also worth noting that pamac-cli crashed (on the message from 24 days ago). So it wasn’t related to GTK3 or GTK4. (But yesterday I used the GTK4 GUI and it also crashed.)
So far I’ve only faced this kind of issue after a new stable update, when updating the whole system. So I can only “reproduce” it a few times per year. If someone tells me what are the extra steps I can do so I can get some kind of stacktrace to help pinpoint the source of this bug… Please tell me!
True, but pamac-gtk3 is scheduled to be dropped in favor of pamac-gtk.
(Don’t ask me when, though. )
Anyway, my recommendation to use octopi still stands. It’s a more than viable alternative to pamac-gtk{,3}, and especially so if you’re using Plasma, because it’s qt6-based.
The only downside — as I said already — is if you want to use Snaps or FlatPaks, because octopi doesn’t cover those. Personally I have no need for Snaps or FlatPaks, but many people here do.
)