Automate Arch Linux upgrades with pacman hooks

The forgotten post-upgrade step

You upgrade the Linux kernel on an Arch Linux system, reboot, and the bootloader cannot find the initial ramdisk. The system drops to an emergency shell. What happened? The package manager installed the new kernel, but nobody rebuilt the initramfs—the early-userspace image that loads drivers and mounts the root filesystem before systemd takes over.

Arch does not guess which follow-up commands you need after every upgrade. You must remember to run mkinitcpio, refresh bootloader entries, or rebuild custom modules yourself. Pacman hooks solve this by letting you declare scripts that run automatically during package transactions.

What a pacman hook looks like

A hook is an INI-style file with two sections. The [Trigger] section decides when the hook fires, using Type values such as Package, File, or Path, and an Operation such as Install, Upgrade, or Remove. The [Action] section defines the command and when it runs relative to the transaction: PreTransaction or PostTransaction.

Package-maintained hooks live in /usr/share/libalpm/hooks/ and can be overwritten by updates. For your own automation, use /etc/pacman/d/hooks/, which pacman reads but does not manage. Hooks execute as root inside the pacman process, so a script that prompts for input or runs for minutes will block the terminal.

Worked example: log every upgrade

This hook writes a timestamp to a log file after any package upgrade. It is intentionally harmless so you can verify hook behavior without risking boot files.

Create the file as root on the Arch host:

sudo tee /etc/pacman/d/hooks/90-log-upgrades.hook >/dev/null <<'EOF'
[Trigger]
Operation = Upgrade
Type = Package

[Action]
Description = Recording package upgrade timestamp
When = PostTransaction
Exec = /bin/sh -c 'echo "$(date -Iseconds) upgrade completed" >> /var/log/pacman-hook.log'
EOF

Run a package installation to test it:

sudo pacman -S --needed <small-package>
tail /var/log/pacman-hook.log

Replace <small-package> with a package you do not already have installed. Expected result: the log file gains a new line after the transaction finishes. If the file is empty or the hook is missing, check /var/log/pacman.log for hook messages and non-zero exit codes.

Risk: a malformed Exec command can cause pacman to report a hook failure. Because this hook runs after packages are already installed, a failure does not undo the upgrade, but it can abort the transaction and leave the system in a partially upgraded state.

Where hooks fit in real maintenance

The mkinitcpio package already ships a hook that rebuilds the initramfs whenever the kernel or core modules change. That is the model to follow: narrow trigger, well-defined action, no user interaction. If you maintain a custom kernel package, you might add a matching hook in /etc/pacman/d/hooks/ to rebuild its initramfs automatically. For routine updates to the default kernel, the package-managed hook is usually enough.

Trade-offs and limits

• Hooks run synchronously. Long-running scripts delay every upgrade and complicate unattended updates.
• A failing PostTransaction hook does not roll back installed packages. Write scripts that are idempotent and safe to re-run.
• Avoid broad triggers such as Type = Path with Target = /usr; they can fire on nearly every transaction and slow updates.
• Never place persistent admin hooks in /usr/share/libalpm/hooks/; package upgrades will overwrite or delete them.

Verify and roll back

List the hooks installed by packages to study real examples:

ls /usr/share/libalpm/hooks/

Confirm the definitive field list on your system:

man alpm-hooks

If you decide to remove the example hook:

sudo rm /etc/pacman/d/hooks/90-log-upgrades.hook

Start with a narrow trigger, test with a disposable package, and inspect /var/log/pacman.log after the next upgrade. Hooks are useful for repeatable, non-interactive maintenance, but they couple your system to custom scripts, so treat them with the same caution as any root-owned automation.