Ubuntu end of life

Once an Ubuntu release leaves standard support, apt upgrade keeps running without errors, but most security fixes stop arriving. Nothing on the server tells you loudly. Here is how to check where you stand and how to move to the next LTS without losing the server.

Published . Ubuntu Server LTS releases (20.04, 22.04, 24.04) upgraded in place with do-release-upgrade.

Why it matters

Each Ubuntu LTS release gets five years of standard security maintenance. After that, security updates stop unless the machine is attached to Ubuntu Pro. The release keeps working and apt shows no error. You simply stop getting fixes for new vulnerabilities in OpenSSL, the kernel, OpenSSH and everything else.

Check which release you run

lsb_release -a
cat /etc/os-release

Look at VERSION_ID (for example 22.04) and VERSION_CODENAME (for example jammy). Versions ending in .04 in even years are LTS releases. Others are interim releases, which are supported for only about nine months.

Then ask the server what it is covered for:

pro security-status
pro status

pro security-status counts your installed packages by repository, says whether the machine is still receiving security patches, and lists pending security updates. On an expired release without Pro you see a line saying the machine is not receiving security patches because the LTS period has ended. pro status shows which Ubuntu Pro services, such as esm-infra and esm-apps, are available and enabled. On recent releases ubuntu-security-status hands over to pro security-status.

Standard support vs ESM

Ubuntu Pro is free for personal use on up to five machines. Attach with sudo pro attach. Other use needs a subscription.

Dates from the Ubuntu release cycle page:

ESM buys time. It doesn't move you to newer software, so the upgrade still has to happen at some point.

Prepare before you upgrade

You can only upgrade from one LTS to the next: 20.04 to 22.04, then 22.04 to 24.04. Skipping is not supported, so an old server takes more than one round. Before each round:

  1. Read the release notes for the target version for known problems.
  2. Take a provider snapshot or a full backup stored somewhere else. See snapshot before changes.
  3. Bring the current release fully up to date, including phased updates, as the Ubuntu docs recommend: 
    sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
  4. Reboot if /run/reboot-required exists, so you start from a clean state.
  5. Check free disk space with df -h. The upgrade downloads hundreds of packages, often several gigabytes.
  6. Note your PPAs and third-party repositories. They are disabled during the upgrade and you need to re-enable or replace them afterwards.
  7. Make sure you can reach the provider's web console, in case SSH doesn't come back.

Run do-release-upgrade over SSH

Start a tmux or screen session first. If your connection drops, the upgrade keeps running and you can reattach to it.

tmux new -s upgrade
sudo do-release-upgrade

If your laptop disconnects, log in again and run tmux attach -t upgrade.

When it detects that it runs over SSH, the upgrader warns you that, if you continue, it will start an additional SSH daemon on port 1022, as a backup in case the main one restarts. It also says you may need to open that port in your firewall. With UFW:

sudo ufw allow 1022/tcp
# after the upgrade is done:
sudo ufw delete allow 1022/tcp

If your provider has a cloud firewall in front of the server, open it there too, and close it again afterwards. A spare SSH daemon on an open port is not something to leave around.

Don't start a release upgrade without a way back. The upgrade replaces most packages on the system, and a failure halfway can leave a server that doesn't boot or doesn't answer on SSH. Take a snapshot first and confirm you can reach the provider's console before you begin. Restoring a snapshot takes minutes. Rebuilding a broken server by hand takes days.

Answer the prompts with care

The upgrade is interactive. It shows a summary of what will change and asks you to confirm. When a config file you edited has a new version from the package, it asks what to do. The default is to keep your version, which is usually right for sshd_config and your web server config. Look at the difference before deciding, and write down what you kept so you can review new options later.

Near the end it offers to remove obsolete packages. Read the list first if you installed software by hand. Then it asks to reboot. The system is not upgraded until that reboot happens.

The -d flag upgrades to a development release, or to a new LTS before its first point release. Don't use it on a production server. Wait for the normal upgrade to be offered.

After the reboot

lsb_release -a
pro security-status
systemctl --failed

Confirm the new version, check that nothing failed to start, and test your sites and services from outside. Re-add third-party repositories for the new codename, then run sudo apt update and look for errors. Remove the port 1022 rule you added. Finally, check that automatic security updates are still on.

Stenvakt's Review shows you where every server stands. It is a read-only security and health check, so running it changes nothing. When you do change something, every fix shows a preview first and runs in safe mode: snapshot, rollback timer and a fresh-connection test, so a change that cuts off SSH rolls back by itself. It's a Mac app and isn't out yet: get early access.

Sources

  1. Ubuntu release cycle
  2. Ubuntu Server docs: Upgrade your release
  3. do-release-upgrade(8) manual page (Ubuntu 24.04)
  4. Ubuntu Pro client docs: Exploring your system's security with Pro
  5. ubuntu-release-upgrader source: DistUpgradeController.py (the extra sshd on port 1022)
Next guideAutomatic security updates