How to Upgrade Ubuntu LTS to the Next LTS

Ubuntu's LTS-to-LTS upgrade path is well-tested but not automatic. A lot can go wrong — third-party PPAs that inject incompatible packages, snaps that silently migrate, services that fail to restart, and config files that get silently replaced. This guide walks through every stage methodically: backup, pre-flight checks, the actual upgrade, and what to do when things break.

Before You Touch Anything: Backups

A failed in-place upgrade can leave the system unbootable. Back up before you start, not after.

Back up /etc and /home

The two directories most likely to contain irreplaceable data are /etc (configuration) and /home (user data). A quick snapshot with tar to an external drive or remote host is enough for most cases:

sudo tar -czvf /mnt/backup/etc-backup-$(date +%F).tar.gz /etc
sudo tar -czvf /mnt/backup/home-backup-$(date +%F).tar.gz /home

If the machine is a VM, take a snapshot at the hypervisor level now. If it's a cloud instance, snapshot the root volume through your provider's console before proceeding.

Record installed packages and PPAs

Save a list of explicitly installed packages and all configured apt sources. You'll need this if you have to rebuild or diagnose broken dependencies later.

dpkg --get-selections > ~/package-list-$(date +%F).txt
apt-mark showmanual > ~/manually-installed-$(date +%F).txt
ls /etc/apt/sources.list.d/ > ~/ppa-list-$(date +%F).txt

Pre-flight: Update the Current System Fully

The upgrade tool expects the running system to be fully up to date at its current release. Partial upgrades or held packages will cause do-release-upgrade to abort or, worse, produce a broken intermediate state.

sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove --purge -y
sudo reboot

The full-upgrade (formerly dist-upgrade) is intentional — it resolves dependency changes that upgrade skips. Reboot after to ensure you're running the latest kernel before starting the release upgrade.

Check for held packages

Held packages block the upgrade. List and release them before continuing:

apt-mark showhold

If any packages appear, decide whether to unhold them:

sudo apt-mark unhold <package-name>

Disable Third-Party PPAs

This is the single most common cause of failed upgrades. PPAs built for the current release often ship packages that conflict with the next release's versions. do-release-upgrade will attempt to disable them automatically, but doing it manually first gives you more control and clearer error messages.

sudo ls /etc/apt/sources.list.d/

For each .list file representing a PPA or third-party repo, disable it:

sudo mv /etc/apt/sources.list.d/somevendor.list /etc/apt/sources.list.d/somevendor.list.disabled

Alternatively, use add-apt-repository to remove PPAs cleanly:

sudo add-apt-repository --remove ppa:someuser/somerepo

After disabling all PPAs, update the cache to confirm nothing is broken:

sudo apt update

Install the Upgrade Tool

do-release-upgrade is part of the ubuntu-release-upgrader-core package. It's present by default on most Ubuntu installations, but confirm it's there:

sudo apt install ubuntu-release-upgrader-core

Configure the upgrade policy

Ubuntu only offers the LTS upgrade path by default, which is what you want. Verify /etc/update-manager/release-upgrades has Prompt=lts:

grep Prompt /etc/update-manager/release-upgrades

Output should read Prompt=lts. If it reads normal, you'll be offered interim releases. Change it to lts if needed:

sudo sed -i 's/Prompt=normal/Prompt=lts/' /etc/update-manager/release-upgrades

Run the Upgrade

On a desktop, run the command in a terminal. On a server accessed over SSH, use a terminal multiplexer first — if your SSH session drops mid-upgrade, the process continues in the background:

sudo tmux new -s upgrade

Then start the upgrade:

sudo do-release-upgrade

For a server without a GUI, add -d only if you're explicitly targeting a development release — leave it off for stable LTS-to-LTS upgrades. If you're upgrading a remote server over SSH, the tool automatically opens an alternative SSH port (typically 1022) as a fallback; don't close that firewall port until the upgrade completes.

What to expect during the upgrade

The tool will: fetch the new release's package lists, calculate the upgrade, download packages (this takes the longest), then prompt you several times about config files. Read each prompt carefully:

• Keep the local version — safe for files you've customized (e.g., /etc/ssh/sshd_config)
• Install the package maintainer's version — safe for files you haven't touched; required for some core system files
• Show the difference between the versions — always a good idea before deciding

When prompted to remove obsolete packages, review the list. Most are safe to remove; occasionally a package you still want appears there — note its name, remove it now, and reinstall it after the upgrade completes from the new release's repos.

Post-Upgrade Checks

Verify the new release version

lsb_release -a
cat /etc/os-release

Confirm the version string matches the expected LTS release (e.g., 24.04 Noble Numbat).

Check for broken packages

sudo dpkg --configure -a
sudo apt install -f
sudo apt full-upgrade

Audit running services

Some services don't restart cleanly after an in-place upgrade. Check for failed units:

systemctl --failed

For each failed unit, check its journal for the cause:

journalctl -xeu <service-name>

Review snap migrations

Ubuntu increasingly replaces classic apt packages with snaps during upgrades — Firefox is the most prominent example. Verify your snaps are on the expected channel and working:

snap list
snap refresh --list

If a snap was installed unexpectedly and you prefer the apt version, check whether a non-snap alternative still exists. For Firefox specifically, Mozilla maintains an official PPA for the .deb version if you prefer it:

sudo add-apt-repository ppa:mozillateam/ppa

Re-enable PPAs for the new release

Before re-enabling any PPA, check whether the PPA maintainer has published packages for the new Ubuntu codename. Open each disabled source file and update the suite from the old codename (e.g., jammy) to the new one (e.g., noble), then re-enable it. Many PPAs simply won't have new-release packages yet — in that case, leave them disabled and check back later.

sudo mv /etc/apt/sources.list.d/somevendor.list.disabled /etc/apt/sources.list.d/somevendor.list
sudo apt update

Troubleshooting Common Problems

Upgrade aborts with "Not all updates can be installed"

This nearly always means a PPA package is blocking the dependency resolver. Run apt-mark showhold, disable remaining PPAs, and run sudo apt full-upgrade again before retrying do-release-upgrade.

System won't boot after upgrade

Boot to the GRUB menu and select the previous kernel entry under "Advanced options". From there, diagnose what failed. Commonly, a third-party kernel module (GPU drivers, ZFS, VirtualBox) won't have been rebuilt for the new kernel. Run sudo dpkg-reconfigure <driver-package> or reinstall the module package for the new kernel version.

SSH locked out during remote upgrade

Reconnect using the fallback port the upgrade tool opened (check the upgrade output — it's usually port 1022). After the upgrade, this port is no longer opened automatically, so your normal SSH port returns to being the only one.

"do-release-upgrade" says "No new release found"

If you're on an LTS release that was just published and the upgrade isn't showing yet, it rolls out gradually. Force the check with:

sudo do-release-upgrade -d

Note that -d targets the development/pre-release version during the period before a new LTS is formally available via the standard upgrade channel. Only use it once the target LTS has been fully released.