Upgrade Ubuntu 22.04 to Ubuntu 24.04 LTS

Ubuntu 22.04 LTS (Jammy Jellyfish) still has standard security support until April 2027, but there are good reasons to move to Ubuntu 24.04 LTS (Noble Numbat) ahead of that. Noble ships GCC 14, Python 3.12, systemd 255, a 6.8 kernel, netplan.io 1.0, and overhauled AppArmor profiles. Server-side you also pick up newer OpenSSL and the fully reworked sources.list.d/ubuntu.sources deb822 format. For anyone running workloads that care about modern toolchains, there’s no reason to wait out the full LTS window.

Original content from computingforgeeks.com - post 91

This guide walks through a full in-place upgrade from 22.04 to 24.04 using the official do-release-upgrade tool, in unattended mode so it works on a headless server without stopping to ask questions. Every command was run on a real Ubuntu 22.04.5 LTS cloud image and verified to come up clean on the other side as 24.04.4 LTS.

Verified: April 2026 — upgraded Ubuntu 22.04.5 LTS (kernel 5.15.0-173-generic) to Ubuntu 24.04.4 LTS (kernel 6.8.0-107-generic) on a 2 vCPU / 4 GB RAM cloud server

Before you start

A release upgrade touches nearly every package on the system. Three things to do first so you can recover if it goes wrong:

• Snapshot or back up the VM (Proxmox, VMware, EC2, or whatever hypervisor you’re on). If you don’t have a hypervisor, at least rsync /etc, /home, and any custom data directories to another host.
• Free up disk space. The upgrade downloads around 1 GB of new packages and needs another gigabyte of free space during dpkg operations. Check with df -hT / and clean up first if you’re under 3-4 GB free.
• Make sure you’re connecting via screen or tmux if you’re remote. An SSH disconnect in the middle of a release upgrade leaves the system in a half-upgraded state that’s painful to recover from. The noninteractive method below is safer because it detaches from your session, but a multiplexer is still a good habit.

Step 1: Check your current release

Confirm you’re actually on 22.04 and record the kernel you’re running before the upgrade, so you have something to compare against later:

lsb_release -a
uname -r

You should see jammy reported as the current release and the 5.15 kernel running:

Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy
5.15.0-173-generic

Make sure you’re on a recent point release (22.04.5 or later). The upgrade path from an older point release still works, but Canonical only tests the latest one.

Step 2: Bring the current system fully up to date

Upgrade every package on the running 22.04 install before trying to change releases. This sounds redundant but it’s the one step that catches most upgrade failures:

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

If any of these steps install a new kernel, reboot before going further. The release upgrader refuses to start with the message “You have not rebooted after updating a package which requires a reboot” in that case.

sudo reboot

Wait about 30 seconds, reconnect, and keep going.

Step 3: Ensure the release upgrader is installed and configured

The tool we need lives in update-manager-core. Make sure it’s present and that the LTS upgrade prompt is active. On a cloud image it usually already is:

sudo apt install -y update-manager-core
grep ^Prompt /etc/update-manager/release-upgrades

You want the line to read:

Prompt=lts

If it’s set to never or normal instead, fix it:

sudo sed -i 's/^Prompt=.*/Prompt=lts/' /etc/update-manager/release-upgrades

With Prompt=lts, do-release-upgrade will offer the next LTS (24.04) rather than an interim release.

Step 4: Disable unattended-upgrades during the release upgrade

If unattended-upgrades fires while do-release-upgrade is running, it holds the dpkg lock and the release upgrader will fail. Stop and disable it for the duration:

sudo systemctl stop unattended-upgrades
sudo systemctl disable unattended-upgrades

You’ll re-enable it after the upgrade completes in the final step.

Step 5: Run the release upgrade (unattended)

The -f DistUpgradeViewNonInteractive flag and DEBIAN_FRONTEND=noninteractive make the tool accept every default without prompting, which is what you want on a headless server. Redirect output to a log file and launch it via nohup so the process survives even if your SSH session drops:

sudo bash -c 'nohup do-release-upgrade -f DistUpgradeViewNonInteractive \
  > /var/log/release-upgrade.log 2>&1 &'

The upgrader splits its work into phases: downloading around 750 MB of new packages, removing obsolete ones, and installing the new release. On a fresh 22.04.5 cloud image with 2 vCPUs, the whole run takes roughly 15 to 25 minutes depending on mirror speed.

Watch progress by tailing the dedicated dist-upgrade log, which is far more useful than the wrapper log:

sudo tail -f /var/log/dist-upgrade/main.log

You’ll see lines scrolling through the toinstall, toupgrade, and toremove package lists as apt works through them. On the test run, the upgrader queued around 155 packages for install, 550 for upgrade, and 13 for removal.

Step 6: Reboot into the new kernel

When do-release-upgrade finishes it changes /etc/os-release, rewrites sources.list.d/ubuntu.sources to use the noble suites, and installs the new 6.8 kernel. But the running kernel is still the old 5.15 one from jammy. Reboot so the new kernel takes over:

sudo reboot

Reconnect and verify both the release and the running kernel:

lsb_release -a
uname -a

Both commands confirm the new release and the updated kernel lineage:

Distributor ID: Ubuntu
Description:    Ubuntu 24.04.4 LTS
Release:        24.04
Codename:       noble
Linux cfg-ubuntu2204-lab 6.8.0-107-generic #107-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 13 19:51:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Release line shows Ubuntu 24.04.4 LTS Noble Numbat and the running kernel is 6.8.0-107-generic. The hostname is preserved from the old install because Ubuntu never touches it during an upgrade.

Step 7: Sanity check the new system

Run through a short checklist. Any failed systemd units are the first thing to investigate because the upgrade may have left stale unit files behind:

systemctl --failed --no-pager

A clean run returns zero failed units:

  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Next check that the apt sources file has been switched over to the new deb822 format with noble suites:

sudo cat /etc/apt/sources.list.d/ubuntu.sources

The file now uses the deb822 format with the noble suites:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Old /etc/apt/sources.list and any files under /etc/apt/sources.list.d/ that predated the upgrade should be empty or commented out. Ubuntu moved to the deb822 format in 24.04, so the single ubuntu.sources file is now the source of truth.

Finally, clean up packages that are no longer needed (leftover kernels, obsolete libraries) and confirm everything is current:

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

Everything should already be at the latest noble version:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Re-enable unattended-upgrades so security patches start flowing again:

sudo systemctl enable --now unattended-upgrades

Common issues and fixes

Error: “You have not rebooted after updating a package which requires a reboot”

The upgrader refuses to start when the running kernel doesn’t match the latest installed one. Reboot the server (sudo reboot) and rerun the command. This is the most common reason a first attempt fails silently.

Error: dpkg lock held by another process

Unattended-upgrades got the lock first. Stop it with sudo systemctl stop unattended-upgrades, wait for its current run to finish (sudo lsof /var/lib/dpkg/lock-frontend should return nothing), and retry.

Third-party PPA packages are held back

The release upgrader disables PPAs during the upgrade because most of them don’t have noble builds yet. After you reboot into 24.04, re-enable any PPA you still need (sudo add-apt-repository --enable ppa:foo/bar) and re-run sudo apt update && sudo apt upgrade. For abandoned PPAs, look for a noble replacement or remove the packages.

Wrap up

Once you’re on 24.04 the standard 5-year LTS support clock restarts, pushing your next mandatory move out to April 2029 (or April 2034 with Ubuntu Pro’s ten-year Expanded Security Maintenance). From here you can move on to the things 24.04 actually enables: newer Node.js 24 LTS, PostgreSQL 17 via the upstream apt repo, Java 25, and modern Docker. Lock down the firewall with our UFW command reference before you start exposing services.