fd23ca023a
The pacman cache grows without bound across updates, and nothing in the update flow ever reclaimed it. On a machine that has been updating for a while it reaches several gigabytes of superseded versions that nothing will ever install again. Prune it with paccache -rk2 as the first step of an update. Both halves of that placement are load-bearing. Keeping two versions rather than one preserves the rollback path. The cache is Arch's only offline downgrade: when an update breaks a single package, reinstalling its predecessor from here is the surgical fix, where a snapshot rollback would revert every other package too. Pruning before the packages update means the installed version is still the newest cached, so it survives along with a spare. Retention is by version order and never consults what is installed, so that holds while the installed version is among the two newest cached; a deliberate downgrade or repeated failed transactions can stack newer archives on top of it. Running before the snapshot is what actually frees the space. The cache sits on the snapshotted root subvolume, so a prune taken afterwards leaves the fresh snapshot holding those extents and reclaims nothing until it ages out of the number cleanup. A failed prune warns and continues. Cache housekeeping should not trip the update's ERR trap and tell the user their update went wrong. This runs after omarchy-update-requires-free-space, so it reclaims space during healthy updates but does not rescue a machine already under the 10 GiB gate. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
57 lines
1.8 KiB
Bash
Executable File
57 lines
1.8 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
# omarchy:summary=Update Omarchy and system packages
|
|
# omarchy:args=[-y]
|
|
# omarchy:examples=omarchy update | omarchy update -y
|
|
# omarchy:requires-sudo=true
|
|
|
|
set -e
|
|
|
|
if [[ -z ${OMARCHY_UPDATE_LOGGED:-} ]]; then
|
|
script_command=$(printf '%q ' "$0" "$@")
|
|
exec env OMARCHY_UPDATE_LOGGED=1 script -qefc "$script_command" "/tmp/omarchy-update.log"
|
|
fi
|
|
|
|
if ! omarchy-update-lock held; then
|
|
exec omarchy-update-lock run "$0" "$@"
|
|
fi
|
|
|
|
trap 'echo ""; echo -e "\033[0;31mSomething went wrong during the update!\n\nPlease review the output above carefully, correct the error, and retry the update.\n\nIf you need assistance, get help from the community at https://omarchy.org/discord\033[0m"' ERR
|
|
trap 'omarchy-update-stay-awake stop' EXIT
|
|
|
|
omarchy-update-requires-free-space
|
|
|
|
if [[ ${1:-} == "-y" ]] || omarchy-update-confirm; then
|
|
# Before the snapshot: the cache is on the snapshotted subvolume, so pruning
|
|
# after it frees nothing until that snapshot ages out.
|
|
omarchy-update-pkg-prune
|
|
|
|
# 127 means Snapper is deliberately absent. Any other failure already said
|
|
# what went wrong, and a missing snapshot is not worth blocking an update
|
|
# over, but it must not pass for one either.
|
|
omarchy-snapshot create || (($? == 127)) ||
|
|
echo -e "\e[33mContinuing the update without a snapshot.\e[0m" >&2
|
|
|
|
omarchy-update-stay-awake start
|
|
|
|
omarchy-update-dev
|
|
omarchy-update-keyring
|
|
omarchy-update-system-pkgs
|
|
omarchy-migrate
|
|
omarchy-hook post-update
|
|
omarchy-update-aur-pkgs
|
|
omarchy-update-mise
|
|
omarchy-update-orphan-pkgs
|
|
|
|
omarchy-update-analyze-logs
|
|
omarchy-update-status
|
|
|
|
# Release update-owned inhibitors before offering a reboot. A confirmed
|
|
# reboot can terminate this process before its EXIT trap gets a chance to
|
|
# remove the persistent Stay Awake marker.
|
|
omarchy-update-stay-awake stop
|
|
trap - EXIT
|
|
|
|
omarchy-update-restart
|
|
fi
|