Linux - Configuration - Ubuntu Distribution Upgrade

What the Ubuntu LTS upgrade Worklet does

This Automox Worklet™ upgrades Ubuntu LTS endpoints to the next major LTS release using the distribution's own do-release-upgrade tool. The Worklet reads /etc/os-release to identify the current version, confirms Prompt=lts in /etc/update-manager/release-upgrades, and drives an unattended in-place upgrade. The most common transitions are 18.04 to 20.04, 20.04 to 22.04, and 22.04 to 24.04.

Ubuntu only supports sequential LTS jumps. An endpoint on 18.04 cannot land on 24.04 in a single pass; it must move through 20.04 and 22.04 first. The Worklet handles that by evaluating the next available release on each run and exiting cleanly after each step. Schedule the policy repeatedly until every host reaches the target LTS.

Pre-flight checks gate the actual upgrade. The Worklet verifies that update-manager-core is installed, applies any pending apt updates with apt full-upgrade -y, and confirms /var/run/reboot-required is absent before invoking do-release-upgrade -m server -f DistUpgradeViewNonInteractive. If any precondition fails, the Worklet exits and surfaces the reason in Automox activity logs rather than leaving the endpoint mid-upgrade.

Why upgrade Ubuntu past its support window

Ubuntu LTS releases get five years of standard security support and an additional five years under Ubuntu Pro Expanded Security Maintenance. Once a release exits standard support, Canonical stops shipping free security updates for the main archive, and any CVE published after that date will not be patched on an unsubscribed host. Ubuntu 18.04 reached end of standard support in May 2023; 20.04 reaches it in April 2025. Endpoints stuck on those releases accumulate unpatched kernel, OpenSSL, and OpenSSH vulnerabilities every month they linger.

Sequential LTS upgrades also close gaps that point patches cannot. A jump from 20.04 to 22.04 brings a new kernel series, OpenSSL 3, and a newer systemd, all of which carry their own backported fixes that the older release will never receive. Compliance regimes such as CIS Ubuntu Linux Benchmarks, PCI-DSS 6.3.3, and HIPAA Security Rule 164.308(a)(5) treat an unsupported operating system as a finding on its own, separate from any individual CVE.

An out-of-support Ubuntu LTS release is the kind of finding that hides at the bottom of an inventory report: the build server that has been running 18.04 since the day it was provisioned, the staging host that nobody patched after the 20.04 jump, the Jenkins runner an offboarded engineer cloned years ago. Scheduling this Worklet on a recurring policy walks each Ubuntu endpoint through one supported LTS jump per evaluation, runs do-release-upgrade non-interactively, and reports the resulting VERSION_ID back to Automox so a SOC 2 or PCI-DSS reviewer can see which hosts are still trailing the standard support window.

How the Ubuntu LTS upgrade runs

1. Evaluation phase: The Worklet sources /etc/os-release to confirm the endpoint is Ubuntu and capture the current VERSION_ID. It reads /etc/update-manager/release-upgrades and exits non-compliant unless Prompt=lts is set. The Worklet then runs do-release-upgrade -c to ask Canonical's release-upgrader whether a newer LTS is available. If one is offered, the endpoint is flagged for remediation; if none is available, the evaluation exits 0 and the policy is satisfied.

2. Remediation phase: The remediation script re-validates prerequisites in order. It checks for Prompt=lts, clears any outstanding apt queue with apt update && apt full-upgrade -y, and aborts if /var/run/reboot-required is present so the kernel patch settles first. It installs update-manager-core if missing, then executes do-release-upgrade -m server -f DistUpgradeViewNonInteractive to perform the in-place dist-upgrade without a TTY. After the run, the Worklet re-reads /etc/os-release to confirm the new VERSION_ID and exits 0 on success, non-zero with a reason logged to stderr on failure.

Ubuntu LTS upgrade requirements

• Ubuntu LTS endpoint on 16.04, 18.04, 20.04, or 22.04 LTS, with a newer LTS available as the upgrade target

• Release-upgrader configured for LTS in /etc/update-manager/release-upgrades (the Worklet requires Prompt=lts)

• update-manager-core package installed (the Worklet installs it if absent)

• No pending reboot – the absence of /var/run/reboot-required is checked before remediation starts

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• Outbound HTTPS to archive.ubuntu.com, security.ubuntu.com, and changelogs.ubuntu.com (or your internal mirror) to fetch release metadata and packages

• Sufficient free disk space on / and /var for the new packages – plan for at least 5 GB of headroom

• Maintenance window for the host, since the upgrade replaces the kernel and requires a reboot to take effect

Expected state after the Ubuntu LTS upgrade

After a successful remediation, the endpoint reports the next supported LTS release. Confirm the new version with lsb_release -a or cat /etc/os-release, and capture the upgrade log at /var/log/dist-upgrade/main.log for audit evidence. The kernel typically rolls forward to the new release's HWE series, so uname -r will change after the post-upgrade reboot.

If a further LTS jump is still available, do-release-upgrade -c reports it on the next evaluation and the policy re-triggers. The Worklet does not reboot the endpoint automatically; pair it with a reboot Worklet or a scheduled maintenance window so the new kernel and updated services activate. Run systemctl --failed and journalctl -p err -b after the first reboot to catch any unit that did not survive the dist-upgrade. Exit code 0 from the Worklet means the upgrade finished; service health after reboot is the operator's call.