Command Palette
Search for a command to run...

UPDATE

Runs the device's package manager in upgrade mode. Equivalent to apt dist-upgrade, dnf upgrade, pacman -Syu, or zypper dist-upgrade depending on the distro (the index refresh runs first as a separate step).

UPDATE is the maintenance-window action: it can be slow, can pull large downloads, and may require a reboot. Run it on a schedule with a maintenance window rather than every reconciliation tick.

Parameters

FieldTypeRequiredDefaultDescription
security_onlyboolnofalseInstall only security updates. Supported on apt (unattended-upgrade), dnf (--security), and zypper (patch --category security). On pacman it fails closed — the action errors rather than silently widening to a full upgrade.
autoremoveboolnofalseRemove orphaned dependencies after the upgrade.
reboot_if_requiredboolnofalseSchedule a reboot if this run newly flagged one as needed.

Idempotency

Before upgrading, the agent asks the package manager whether anything is pending: dnf check-update (exit 100), pacman -Qu, zypper list-updates, and a simulated apt-get -s upgrade (counting Inst lines rather than parsing localised text, so non-English locales work). The index refresh and upgrade still run either way — the probe drives the changed flag, so a device with nothing pending reports changed=false instead of a state change.

Example

Nightly security upgrades plus autoremove, reboot if the kernel changed:

type: UPDATE
security_only: true
autoremove: true
reboot_if_required: true

Gotchas

  • security_only on Debian / Ubuntu runs unattended-upgrade, which must be installed — if it's absent the action fails closed with an actionable error rather than doing a full upgrade. Arch (pacman) has no security/non-security distinction and rejects the request outright.
  • reboot_if_required schedules the reboot 1 minute out, not immediate, and notifies signed-in users ("A system update requires a reboot. This system will reboot in 1 minute."). It only fires when this run created the reboot requirement — a device that already needed a reboot before the upgrade won't be rebooted by it. A reboot that fails to schedule fails the action.
  • A failing upgrade does not roll back. The package manager's transaction semantics apply; on Fedora that's atomic per transaction, on Debian it's not.
  • Run inside a maintenance window. A daily upgrade dispatched outside one will queue until the window opens.