Ubuntu 26.04 Tutorial / Prepare and Perform an Ubuntu LTS Release Upgrade

An Ubuntu LTS release upgrade changes the operating-system release and differs from routine package updates. Readers who installed 26.04 do not need another release just to complete this lesson. Use the process when migrating an existing system, such as 24.04 LTS, through an officially offered path with a recovery plan.

Check the current release and offered path

cat /etc/os-release
uname -r
df -h / /boot
apt-mark showhold
dpkg --audit

Move sequentially between adjacent LTS releases rather than skipping generations. Availability can be controlled or paused because of known issues, so check the target’s release notes and upgrader output. Do not rewrite repository suite names or force an unavailable path with -d.

Check supported paths and prerequisites in Ubuntu Server’s official release-upgrade guide.

Prepare a recoverable baseline

1. Create an independent backup and test restoration in another VM or directory, including database/volume consistency.
2. Rehearse on an isolated clone; do not activate duplicate addresses or host identities alongside production.
3. Confirm console access, power, capacity, maintenance time, application compatibility, and responsibility. Ensure recovery access beyond the SSH session.
4. Inventory third-party repositories and local changes. Restore disabled sources selectively only after checking support for the destination release.

Rolling back a snapshot can leave external databases or other servers at a conflicting state. Document the rollback boundary and external changes. Do not assume ordinary package downgrades can reverse an entire release upgrade.

Bring the current system to a healthy updated state

sudo apt update
apt-get -s dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

Review simulated removals, holds, and dependencies. The phased-update option here checks readiness for a release upgrade; it is not a general recommendation to force phased updates during routine operation. Proceed only after reviewing the result and arranging backup and maintenance time.

sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
test ! -e /run/reboot-required || cat /run/reboot-required

After any required reboot, verify that the current release boots and that SSH, networking, and applications work. Investigate held packages or a broken dpkg state rather than deleting lock files or blindly releasing holds.

Check availability and run interactively

sudo apt install update-manager-core
grep -E "^Prompt=" /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

For an LTS-only policy, verify Prompt=lts. If necessary, back up the file and adjust it with sudoedit to match the intended policy. The -c option checks availability. If no release is offered, wait for an offered upgrade or plan a separately built replacement and data migration.

sudo do-release-upgrade

Run this on the prepared clone or during the approved maintenance operation. Review changes, removals, and configuration diffs individually. If an additional remote-recovery port is suggested, restrict it appropriately. Avoid forced termination or power loss, and preserve the displayed error and /var/log/dist-upgrade records if the process fails.

Verify operation after reboot

After completion, verify the new release, running kernel, failed services, and networking from the console. Test a new SSH connection, application reads/writes, HTTPS, shares, and containers as applicable. Review obsolete packages only after operational checks and recovery-kernel planning. Finish by resuming updates/backups and updating restoration tests and change records.