Upgrade Ubuntu 22.04 to 24.04 with do-release-upgrade, and fix "Please install all available updates"

Short answer: do-release-upgrade prints “Please install all available updates for your release before upgrading.” when at least one package on the current release still has an update waiting. Run sudo apt update && sudo apt full-upgrade, reboot if a new kernel came in, release any held packages (apt-mark showhold), then run sudo do-release-upgrade again.

sudo apt update
sudo apt full-upgrade          # not "apt upgrade": full-upgrade also installs new dependencies
apt list --upgradable          # should list nothing (or only phasing updates)
sudo reboot

sudo do-release-upgrade        # 22.04 -> 24.04, or 24.04 -> 26.04
cat /etc/os-release            # after the final reboot: the new VERSION

This guide is written from Ubuntu’s server documentation (“Upgrade your release”), Ubuntu’s release-cycle page and the source code of the upgrader itself (the ubuntu-release-upgrader package, read on 21 October 2026); the messages quoted below come from that code. Back up first: the steps are safe in the normal case, and the backup is for the other one.

What does “Please install all available updates” mean?

Before it starts, do-release-upgrade opens the APT cache and looks for any installed package that has a newer version available on the current release. One is enough: it prints the message and exits with status 1. Current versions of the upgrader skip packages that Ubuntu is still rolling out gradually (phased updates). The usual reasons something is still waiting:

apt upgrade never installs a new package or removes one, so an update that needs a new dependency stays “kept back” forever; apt full-upgrade (the same as apt-get dist-upgrade) resolves those. Ubuntu’s own upgrade guide uses dist-upgrade with the phased-updates option shown in the table, so everything is current before the release changes. A hold is deliberate: someone ran apt-mark hold to keep a version, for a kernel module or a pinned database, for example. Find out why before you release it.

A related check: if the last updates included a new kernel, libc6 or linux-base and the server has not rebooted since, the upgrader stops with You have not rebooted after updating a package which requires a reboot. Please reboot before upgrading. A reboot is the fix.

What should I do before I start?

• Take a backup you can restore. On a VPS, a snapshot right before the upgrade is the fastest way back. Also copy /etc and your data somewhere off the server.
• Know what you are upgrading from. lsb_release -a or cat /etc/os-release; see checking the Linux version.
• Check free space. df -h / /boot. The upgrade downloads hundreds of packages, often more than a gigabyte, and aborts with Not enough free disk space when the room runs out. sudo apt autoremove --purge removes old kernels from /boot.
• List third-party sources. ls /etc/apt/sources.list.d/. Ubuntu’s documentation says third-party repositories and PPAs are disabled during the upgrade. Check, for each one, whether it already publishes packages for the new release.
• Note the major version jumps of your stack. From 22.04 to 24.04, PHP goes from 8.1 to 8.3, PostgreSQL from 14 to 16 and Python from 3.10 to 3.12. For 24.04 to 26.04, read the 26.04 release notes for the versions that change.
• Have a way in that does not depend on SSH, such as the provider’s console, and plan an hour of attention including reboots. The upgrade stops for questions.

How do I upgrade Ubuntu 22.04 to 24.04, step by step?

1. 1Bring the current release fully up to date

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

2. 2Check that LTS upgrades are allowed

   grep Prompt /etc/update-manager/release-upgrades    # Prompt=lts

   Prompt=lts, the server default, offers the next LTS only. Prompt=normal offers the next release of any kind, including six-monthly interim releases with about nine months of support. With Prompt=never the upgrader refuses outright.

3. 3Start the upgrade

   sudo do-release-upgrade

   Over SSH it first warns that the session “appears to be running under ssh” and offers a second SSH daemon on port 1022 (see below). Answer y. It then rewrites the APT sources, calculates the changes and shows a summary of how many packages will be installed, upgraded and removed. Read the removals before you confirm.

4. 4Answer the questions on the way
   • Restart services automatically? Yes is fine on most servers; it avoids a question for every daemon.
   • A configuration file you changed has a new version: keep your local version (the default) for files such as sshd_config, then compare with the new one afterwards. The package’s version is saved next to yours, as .dpkg-dist or, for files that ucf manages such as sshd_config, as .ucf-dist.
   • If grub-pc asks for the boot device (the 24.04 release notes mention this prompt), choose the whole disk the server boots from, such as /dev/vda or /dev/sda, not a partition. lsblk shows which disk holds /.
   • Remove obsolete packages? Look at the list; yes is normally right.
5. 5Reboot into the new release

   When the packages are in, the upgrader asks to restart the system. Say yes, wait a minute or two, and log in again.

Is it safe to upgrade over SSH?

Mostly, and the upgrader takes two precautions of its own. It runs itself inside GNU screen when screen is installed, in a session named ubuntu-release-upgrade-screen-window. If your connection drops, log in again and run sudo do-release-upgrade once more: it finds the running session and re-attaches instead of starting a second upgrade. How screen works, if you want to drive it by hand, is in the screen command.

It also starts an extra sshd on port 1022, so that a broken main SSH daemon does not lock you out mid-upgrade. In the upgrader’s own words: “If you run a firewall, you may need to temporarily open this port. As this is potentially dangerous it’s not done automatically.” Open it only when you actually need that second door, only for your own address, and close it again afterwards:

sudo ufw allow from 203.0.113.5 to any port 1022 proto tcp    # your own public IP
ssh -p 1022 user@your-server
sudo ufw delete allow from 203.0.113.5 to any port 1022 proto tcp

A console that does not depend on the server’s network is the better fallback than either: it still works when the network configuration itself is what broke.

Can I skip a release, like 20.04 straight to 24.04?

No. do-release-upgrade moves one step at a time: 20.04 to 22.04, reboot, then 22.04 to 24.04, then 24.04 to 26.04. Between LTS releases the interim releases are skipped automatically, but never a whole LTS. Ubuntu also opens the LTS-to-LTS path only with the first point release: “Upgrades from one LTS release to the next one are only available after the first point release”, in the words of the server documentation.

Dates are from Ubuntu’s release-cycle page and the ubuntu-announce list, checked 21 October 2026. With an Ubuntu Pro subscription (Expanded Security Maintenance), each LTS gets security updates for five more years: 20.04 until May 2030, 22.04 until May 2032, 24.04 until May 2034. So a 22.04 server has until May 2027 before it needs Pro or an upgrade.

What does do-release-upgrade -d do?

-d upgrades to the development release. On an LTS it is what people use to reach a new LTS before its first point release, which Ubuntu’s documentation calls not recommended for production. As of October 2026 every LTS path above is already open, so a server never needs -d. When the upgrader instead answers No new release found., check the Prompt line, check that the server can reach changelogs.ubuntu.com, where the list of releases comes from, and check that you are not already on the newest LTS.

What should I check after the upgrade?

cat /etc/os-release                # VERSION="24.04.x LTS (Noble Numbat)"
uname -r                           # the new kernel
systemctl --failed                 # services that did not come back
journalctl -p err -b               # errors since this boot
sudo ss -tlnp                      # is everything listening where it should?
sudo apt update && apt list --upgradable
sudo apt autoremove --purge

• APT sources moved. The 24.04 release notes say Ubuntu’s sources configuration moves from /etc/apt/sources.list to /etc/apt/sources.list.d/ubuntu.sources, in the deb822 format. Look there, not in the old file.
• Third-party repositories are off. Re-enable each one in /etc/apt/sources.list.d/ once its vendor supports the new release. Per the 24.04 release notes, APT now rejects repositories signed with RSA keys shorter than 2048 bits, so a vendor with an old key has to publish a new one. A repository whose key is missing altogether fails with GPG error: NO_PUBKEY.
• SSH on a custom port. On 24.04, sshd is started through ssh.socket, configured from sshd_config by a systemd generator. Check with ss -tlnp that it still listens on your port; changing it later is described in changing the SSH port.
• Version-bound paths. nginx configs that point at /run/php/php8.1-fpm.sock need the 8.3 socket; Python virtual environments built on 3.10 need to be recreated; a PostgreSQL 14 cluster stays on 14 until you migrate it to 16.
• Logs of the upgrade itself are in /var/log/dist-upgrade/ (main.log, apt.log, term.log) if anything looks wrong.

If APT complains that another process holds its lock right after the reboot, that is usually unattended-upgrades catching up; wait a few minutes or see could not get lock. If an interrupted upgrade left dpkg half done, dpkg was interrupted covers the repair.

Upgrade in place or reinstall?

Reinstall when the server can be rebuilt from code or a tested backup: a fresh 24.04 carries no leftovers from three releases of history. Upgrade in place when it holds years of hand-made configuration. Debian has no do-release-upgrade: you switch the APT sources by hand, and upgrading Debian 12 to 13 is the counterpart of this guide.

Frequently asked