That's not pacman, that's a hook, and the update itself IS successful. I don't see a pacman problem here.

The package installed correctly and there are no traces of the old package left anywhere on your system, but its PostTransaction hook failed with "error: command failed to execute correctly".

> At this point, I'd expect any packages that had been extracted correctly to have been installed (none, in my case)

You updated 16 packages, of which 4 raised install scriptlet errors, and 1 post transaction hook likewise raised errors.


That's 11 packages which installed flawlessly without a hitch, and 3 packages (git, systemd, and openssh) which failed to run an install scriptlet which currently checks for versions you don't have and performs migrations you don't need

> and those that had failed be able to be installed again.

... and 1 package (archlinux-keyring) which was supposed to run:

pacman-key --populate archlinux

Plus the mkinitcpio hook, which you can solve by running mkinitcpio --allpresets.

What do you expect pacman to do about this? Why do you think you cannot install them again?

sudo pacman -S archlinux-keyring linux

It will reinstall the packages and run the commands which previously failed. Assuming it can, since /tmp is broken for a reason.

Also assuming the scripts actually do anything now, because they are called with positional parameters for the old and new versions of the package, and many install scriptlets only do something when the old version was a certain version. You may need to inspect them manually using pacscripts $pkgname.

Install script errors should be recoverable ones, but it does require user intervention. If errors are logged, investigate them.

You can also wrap pacman in a btrfs snapshot (see the 'snap-pac' package) to roll back your entire filesystem on errors, and try to repeat the upgrade. pacman will not incorporate this feature into itself automatically, and it will only work for filesystems which you set up with snapshotting capabilities.

My system is fine, it's a VM that's sitting on zfs with snapshots so recovery wasn't an issue, and in my case was a simple rollback, make sure /tmp was sized approprately, then re-ran.

What I'd expect pacman to do is re-run whatever failed again, until success. If that isn't reasonable, then maybe I'd expect pacman to stop on the first error encountered, since debugging a single broken thing is probably easier than attempting to debug lots of broken things. Assuming they're broken, which I'd need to figure out somewhere.

Assuming that isn't pacman's job, where in the docs should I be looking? e.g. https://wiki.archlinux.org/index.php/Pacman#Troubleshooting section doesn't cover this case particularly well.

Where does pacscripts come from?

It comes from the pacman-contrib package.

And aborting mid transaction would be a lot more dangerous because then you cannot even rely on programs having the shared libraries they need, so the only way to recover is using the installation media.

Failing install scriptlets or hooks should never cause the command prompt to stop working. Aborted transactions can and do.

BTW one thing which might help is to teach mkinitcpio to fail earlier if it cannot write to /tmp. This would result in far fewer error logs to read through in order to figure out everything that failed and needs to be repeated.

pacman does use /tmp for extracting install scripts. So I think this bug is still valid, just not for the reason submitted...