Can I Upgrade My Linux Distribution with Automox?

Issue

An administrator wants to move Linux devices to a newer distribution release (for example Ubuntu 20.04 to 22.04, or RHEL 8 to RHEL 9) and looks to Automox to perform the upgrade. Running apt-get -y dist-upgrade through an Automox Worklet completes without error, but the device's OS release version is unchanged afterward.

Environment

• Automox agent on Linux: apt-based (Ubuntu, Debian), yum/dnf-based (RHEL, CentOS, Fedora, Amazon Linux), or zypper-based (SLES) distributions
• Automox Worklets used to run custom remediation code outside of standard patch policies

Overview

Automox's built-in Linux patching only manages package-level updates: the agent queries and drives the OS's native package manager (apt, yum, dnf, or zypper) the same way an administrator would from the command line, and reports back whatever that package manager considers available or installed, see Why an update or patch does not appear in Automox and Linux: Recommendations, Requirements, and FAQs. Automox has no built-in policy type for a full distribution release upgrade (moving a device from one major OS version to the next) — that is a distinct operation from ordinary patching.

A common point of confusion is the dist-upgrade package-manager option itself: on Debian/Ubuntu, apt-get dist-upgrade "in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages," per the apt-get manpage — it installs new packages and kernels the plain upgrade command would hold back, and may remove packages to satisfy dependencies, but it does so within the currently-installed release. It does not change /etc/os-release, does not switch the system to a new release's package repositories, and does not bump the OS version number.

The vendor-supported path for an actual release upgrade is different, and varies by distribution:

• Ubuntu/Debian: do-release-upgrade is Ubuntu's documented command for upgrading "the operating system to the latest release from the command-line," and is the tool Ubuntu recommends for headless or remote systems. It repoints the system to the next release's repositories and walks through the package transition; a bare apt-get dist-upgrade does neither.
• RHEL and RHEL-derived distributions: Red Hat's Leapp utility is the supported in-place upgrade path between major RHEL versions (for example RHEL 7 to 8, or 8 to 9), preserving subscriptions, configuration, and installed applications through the transition.

Automox can run either tool as the remediation code in a Worklet, the same way it can run any other script — but Automox does not natively track, validate, or roll back a release upgrade in progress. The Worklet executes the command; the release-upgrade tool itself owns the actual transition.

Resolution

1. Confirm which operation is needed: a package-level update within the current release (handled by standard Automox patch policies) or a full release upgrade to a new OS version (not a built-in Automox function).
2. For an apt-based distro, build a Worklet whose remediation code calls do-release-upgrade (with the appropriate non-interactive flags for your environment) rather than apt-get dist-upgrade, which will not change the release. See Creating a Worklet for Worklet structure and evaluation/remediation code blocks.
3. For a RHEL-based distro, build a Worklet whose remediation code installs and runs Red Hat's leapp utility for the specific version transition (for example RHEL 7→8 or 8→9), following Red Hat's Leapp documentation for pre-upgrade checks and any manual remediation steps it reports.
4. Test the Worklet against a single pilot device (or a small server group) before assigning it broadly. Release upgrades can break third-party repositories, custom configuration, or applications tied to the old release — take a snapshot or backup of the device beforehand.
5. After the Worklet runs, confirm the upgrade succeeded on the device itself, for example by checking /etc/os-release, before assigning the Worklet to additional devices. Reboot if the tool reports one is required.

Notes

• Automox's visibility into "what needs patching" always comes from the OS's own package manager, never an independent Automox determination — a device won't show as needing a release upgrade the way it shows pending package updates.
• There is currently no Automox Worklet Catalog entry that performs a distribution release upgrade; this has to be authored as a custom Worklet using the OS vendor's own upgrade tooling.
• Because a release upgrade is a disruptive, mostly one-way operation, treat it as a change-managed maintenance activity — not a routine patch policy — regardless of which tool triggers it.