Upgrade Ubuntu 24.04 to Ubuntu 26.04 LTS (Step by Step)

An LTS-to-LTS upgrade swaps out more than packages. Going from Ubuntu 24.04 to 26.04 replaces your sudo binary with the Rust rewrite sudo-rs, replaces most of GNU coreutils (ls, chmod, sort and the rest) with the Rust uutils port, moves the kernel from 6.8 to 7.0 and Python from 3.12 to 3.14. It also quietly disables every third-party repository on the box and doesn’t turn them back on. Know that before you start, not after a Docker update silently stops arriving.

Original content from computingforgeeks.com - post 165874

We ran the upgrade on a 24.04 server carrying Docker CE from Docker’s own repo, a Launchpad PPA, Nginx, a Python virtual environment and a custom sudoers drop-in. The whole run took 13 minutes 44 seconds and changed 757 packages. It was run again in October 2026, from Ubuntu 24.04.5 LTS to 26.04.1 LTS with AppArmor enforcing, so no step turns it off, and a third time in November 2026 on a machine carrying the in-archive NVIDIA 580 driver to test how proprietary drivers cross the upgrade. The troubleshooting output under Step 1 comes from the October run, the NVIDIA sections come from the November one, and every other command and output comes from the first machine.

Before You Start

• Ubuntu 24.04 LTS (Noble Numbat), fully updated
• A backup you have actually restored from once (VM snapshot, rsync, or whatever you trust)
• At least 5 GB free on /. Our root filesystem grew by about 1.2 GB
• Out-of-band console access (VNC, IPMI, or your cloud provider’s serial console) in case SSH drops mid-upgrade
• About 30 minutes, including the reboot and the post-upgrade checks

On a production server, run the upgrade on a clone first. Do not skip this. If you’re still on 22.04, upgrade to 24.04 first, then continue here. Ubuntu does not support skipping an LTS release.

If you run Python virtual environments, record what is installed in each one now. They break during the upgrade (details further down), and a requirements file makes the rebuild a one-liner:

/opt/appvenv/bin/pip freeze > ~/appvenv-requirements.txt

Machines with proprietary NVIDIA drivers need one more check before you start. The upgrade refetches the entire driver payload, roughly 400 MB for the 580 series, and readers have reported refetches dying on checksum or GPG errors partway through an otherwise healthy run. Note which driver series the machine carries now, so you can put the same one back afterwards:

dpkg -l | grep nvidia-driver-

Our lab machine carried nvidia-driver-580, so 580 is the series to reinstall if the upgrade drops it. Whatever yours prints, write the series number down before you run the upgrader.

What Changes in the Upgrade

These are the versions on our test server before and after the upgrade:

Component	Ubuntu 24.04	Ubuntu 26.04
Kernel	6.8.0	7.0.0
Python	3.12.3	3.14.4
sudo	sudo 1.9.15p5 (C)	sudo-rs 0.2.13 (Rust)
coreutils	GNU coreutils 9.4	uutils coreutils 0.10.0 (Rust)
OpenSSH	9.6p1	10.2p1
systemd	255	259
OpenSSL	3.0.13	3.5.5
Codename	Noble Numbat	Resolute Raccoon

For the feature-level view, see our Ubuntu 26.04 LTS features guide and the 26.04 vs 24.04 comparison.

Step 1: Fully Update Ubuntu 24.04

Bring the current release fully up to date first. full-upgrade also pulls in packages that a plain upgrade holds back:

sudo apt update && sudo apt full-upgrade -y

Then reboot if a kernel or core library was updated. The upgrade tool checks for this and refuses to continue while the flag file exists:

[ -f /var/run/reboot-required ] && sudo reboot

Our freshly patched server needed that reboot. Running the upgrade without it stops immediately:

Checking for a new Ubuntu release
You have not rebooted after updating a package which requires a reboot. Please reboot before upgrading.

A patched, rebooted machine still has one more way to refuse the upgrader, and it is the check most likely to bite on a server that has been sitting for a while.

“Please install all available updates for your release before upgrading”

do-release-upgrade refuses to start while any installed package still has a newer version waiting, and the only ones it ignores are phased updates. A package on hold is the usual cause. apt full-upgrade respects the hold and reports nothing left to do, but the upgrader still sees the newer version. This one-liner runs the same test the tool runs and prints the packages that block it:

python3 -c 'import apt; c=apt.Cache(); print([p.name for p in c if p.is_upgradable and "Phased-Update-Percentage" not in p.candidate.record])'

On our 24.04 test VM, putting nano on hold reproduced the error, and the one-liner named only that package. A phased cloud-init update was pending at the same time and didn’t count:

['nano']

Release the holds and run the full upgrade again. Once the one-liner prints an empty list, do-release-upgrade gets past this check:

apt-mark showhold
sudo apt-mark unhold $(apt-mark showhold)
sudo apt full-upgrade -y

An upgrade that failed partway blocks the check the same way, because the package never reached its new version. On the same VM a full root disk stopped snapd mid-unpack. Free some space, run sudo dpkg --configure -a, then repeat the full upgrade.

No holds, and the one-liner still names packages? Then apt can see a newer version it cannot install, and apt full-upgrade lists the package under “kept back” instead of upgrading it. The upgrader counts it as pending all the same. Ask apt which source offers that version, using the package name the one-liner printed:

apt-cache policy ubuntustudio-audio-core

To reproduce this on 24.04, we served a newer ubuntustudio-audio-core from a local repository with a dependency nothing could satisfy. The candidate comes from that extra source, not from archive.ubuntu.com:

ubuntustudio-audio-core:
  Installed: 24.04.22
  Candidate: 24.04.23
  Version table:
     24.04.23 500
        500 file:/home/ubuntu/repo ./ Packages
 *** 24.04.22 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
        100 /var/lib/dpkg/status

Installing the package by name makes apt say what stops it. If apt instead offers to remove packages and asks to continue, answer n, since this step is only a diagnosis:

sudo apt install ubuntustudio-audio-core

The end of the output names the unmet dependency:

The following packages have unmet dependencies:
 ubuntustudio-audio-core : Depends: ubuntustudio-pipewire-config (>= 26) but 24.04.26.7 is to be installed
E: Unable to correct problems, you have held broken packages.

Disable or delete the source that offers the newer version (usually a PPA or a repository line left over from another release), then run sudo apt update. The one-liner went back to an empty list on our VM, and the upgrader stopped complaining. If the newer version comes from an archive.ubuntu.com line, keep that source enabled and look at the package the dependency line names instead: a hold or a third-party copy of that package is what needs fixing.

“The repository ‘file:/cdrom noble Release’ does not have a Release file”

Desktop and Ubuntu Studio installs made from a USB stick or DVD can keep the source line the installer used to read packages from the install media. Once the media is gone, sudo apt update in Step 1 ends with this error. do-release-upgrade stops at its update stage with “Error during update. A problem occurred during the update. This is usually some sort of network problem”, even though the network is fine. Find the line:

grep -rn cdrom /etc/apt/sources.list /etc/apt/sources.list.d/

We added the installer’s line by hand to reproduce the error, and grep found it at the end of /etc/apt/sources.list:

/etc/apt/sources.list:5:deb [check-date=no] file:///cdrom noble main restricted

Comment it out, then confirm apt updates cleanly. If grep reported a file under /etc/apt/sources.list.d/, run the sed against that file instead:

sudo sed -i '/^deb .*file:\/\/\/cdrom/s|^|# |' /etc/apt/sources.list
sudo apt update

A failed run restores your original sources before it exits, so nothing needs cleaning up. Start sudo do-release-upgrade again once apt update finishes without errors.

Step 2: Confirm the Upgrade Policy

The do-release-upgrade tool ships in update-manager-core. Server images include it, but install it explicitly on minimal builds:

sudo apt install -y update-manager-core

Check which releases the tool is allowed to offer:

grep -v '^#' /etc/update-manager/release-upgrades

The policy should read lts:

[DEFAULT]
Prompt=lts

If it says never, someone disabled release upgrades on purpose. Find out why before you change it to lts.

Step 3: Check That 26.04 Is Offered

Ask the tool whether a new LTS is available:

sudo do-release-upgrade -c

On 24.04 it now reports the point release:

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Canonical only publishes a new LTS to existing LTS users once the first point release ships. Ubuntu 26.04 came out on 23 April 2026, but 24.04 machines were not offered it until 26.04.1 landed in late August. Earlier guides, including the first version of this one, told you to force the upgrade with -d. Drop that flag now. The plain command upgrades you to the supported release.

“There is no development version of an LTS available”

This message means the tool found no newer LTS in meta-release-lts. A machine that’s already on 26.04 prints it on every check:

Checking for a new Ubuntu release
There is no development version of an LTS available.
To upgrade to the latest non-LTS development release
set Prompt=normal in /etc/update-manager/release-upgrades.

If you see it on 24.04, run lsb_release -ds first. A box that already upgraded prints this message too. Otherwise, confirm Prompt=lts from Step 2, update update-manager-core, and check that the server can reach changelogs.ubuntu.com over HTTPS. Don’t switch to Prompt=normal to make it go away. That moves the server onto the nine-month interim release track.

Step 4: Run the Upgrade

Start it from a tmux or screen session so a dropped SSH connection does not kill it. Over SSH, the interactive frontend also offers to start a backup sshd on port 1022. It only helps if that port is reachable, so open it in ufw or your cloud security group before you start:

sudo do-release-upgrade

The tool works through these stages:

1. Disables every third-party repository and PPA by adding Enabled: no to its .sources file
2. Rewrites ubuntu.sources from noble to resolute
3. Calculates the upgrade (757 package changes on our server: 643 upgrades and 114 new packages) and asks you to confirm
4. Downloads and installs everything, asking about config files you have modified (keep your version unless you know the new default is what you want)
5. Removes obsolete packages and prompts for the reboot

It does not re-enable the repositories it switched off, even when they already publish packages for 26.04. Docker and the git-core PPA both had resolute builds available, and both stayed disabled. The post-upgrade section below shows how to bring them back.

On our test server (4 vCPUs, 4 GB RAM), the download phase took about 5 minutes and the install about 8. The whole run took 13 minutes 44 seconds.

For automation, the non-interactive frontend answers every prompt itself and keeps your existing config files on conflicts. That is the mode our test used:

sudo do-release-upgrade -f DistUpgradeViewNonInteractive

Use it only on a server whose upgrade you have already rehearsed on a clone. It will not stop to ask about anything.

The screenshot below is from the non-interactive run on our third test machine, mid-way through the same 24.04.5 to 26.04.1 upgrade. The base-files package carries the release identity files, so this pass is where the machine stops being a 24.04 install on disk:

Watching for this point in the log tells you the upgrade has committed to the new release. Everything before it can still be rolled back with the 24.04 snapshot.

Step 5: Reboot

Reboot into the 7.0 kernel:

sudo reboot

Physical servers with a long firmware POST take a few minutes to come back. Give them that time before you reach for the console.

Step 6: Verify the Upgrade

Confirm the release:

lsb_release -a

It should name the 26.04 point release, not a development branch:

Distributor ID:	Ubuntu
Description:	Ubuntu 26.04.1 LTS
Release:	26.04
Codename:	resolute

Check the kernel, the toolchain swaps and failed units in one pass:

uname -r; python3 --version; sudo --version | head -1; ls --version | head -1; ssh -V; systemctl --failed --no-legend | wc -l

Every component reports its 26.04 version, and no systemd unit failed:

Then check that your services came back. On our box, nginx, docker and containerd were all active, and containers still ran. They were still running the 24.04 Docker packages at this point, because Docker’s repository was disabled.

Re-enable Third-Party Repositories

Find the repositories the upgrade switched off:

grep -l '^Enabled: no' /etc/apt/sources.list.d/*.sources

Both third-party sources on our server were listed:

/etc/apt/sources.list.d/docker.sources
/etc/apt/sources.list.d/git-core-ubuntu-ppa-noble.sources

Repos still in the one-line .list format do not get Enabled: no. The upgrader comments their lines out instead, so open any .list files in /etc/apt/sources.list.d/ and check them by eye too.

Before re-enabling one, confirm the vendor publishes a resolute suite. Open <repo URL>/dists/resolute/Release in a browser or with curl -I. A 404 means the vendor has no 26.04 build yet, and pointing the repo at resolute will break apt update. Docker and the git-core PPA both returned 200, so we pointed them at resolute and removed the disable line:

sudo sed -i -e 's/^Suites: noble$/Suites: resolute/' -e '/^Enabled: no$/d' /etc/apt/sources.list.d/docker.sources /etc/apt/sources.list.d/git-core-ubuntu-ppa-noble.sources

Refresh the package lists and look at what changed:

sudo apt update && apt list --upgradable

Every Docker and git package now has a 26.04 build waiting to replace the 24.04 one:

containerd.io/resolute 2.3.6-1~ubuntu.26.04~resolute amd64 [upgradable from: 2.3.6-1~ubuntu.24.04~noble]
docker-buildx-plugin/resolute 0.37.1-1~ubuntu.26.04~resolute amd64 [upgradable from: 0.37.1-1~ubuntu.24.04~noble]
docker-ce-cli/resolute 5:29.8.2-1~ubuntu.26.04~resolute amd64 [upgradable from: 5:29.8.2-1~ubuntu.24.04~noble]
docker-ce-rootless-extras/resolute 5:29.8.2-1~ubuntu.26.04~resolute amd64 [upgradable from: 5:29.8.2-1~ubuntu.24.04~noble]
docker-ce/resolute 5:29.8.2-1~ubuntu.26.04~resolute amd64 [upgradable from: 5:29.8.2-1~ubuntu.24.04~noble]
docker-compose-plugin/resolute 5.6.0-1~ubuntu.26.04~resolute amd64 [upgradable from: 5.6.0-1~ubuntu.24.04~noble]
git-man/resolute 1:2.55.0-0ppa1~ubuntu26.04.2 all [upgradable from: 1:2.55.0-0ppa1~ubuntu24.04.2]
git/resolute 1:2.55.0-0ppa1~ubuntu26.04.2 amd64 [upgradable from: 1:2.55.0-0ppa1~ubuntu24.04.2]

Install them with sudo apt full-upgrade -y. A repository left disabled does not break anything on day one. The failure mode is slower: that software never gets another security update. For a fresh Docker setup on the new release, follow installing Docker CE on Ubuntu 26.04.

Finally, remove packages the new release no longer needs and check disk usage:

sudo apt autoremove -y --purge && df -h /

Usage on our 29 GB root went from 2.8 GB to 4.0 GB:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        29G  4.0G   25G  14% /

The old 6.8 kernel stays installed as a GRUB fallback. Leave it until the server has run cleanly on 7.0 for a while.

What Breaks After Upgrading

Python virtual environments stop finding their packages

A venv’s interpreter is a symlink to /usr/bin/python3, which is now 3.14, while its packages sit in lib/python3.12/site-packages. The venv still starts, but every third-party import fails. Our test venv did exactly that:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

Recreate the venv and reinstall from the requirements file you saved before the upgrade. Our venv lives in root-owned /opt, hence the sudo. Run both commands as whichever user owns the venv, or a service account’s environment ends up owned by root:

sudo python3 -m venv --clear /opt/appvenv && sudo /opt/appvenv/bin/pip install -r ~/appvenv-requirements.txt

--clear wipes the old environment. Without the requirements file you are rebuilding the package list from memory. See Python on Ubuntu 26.04 for the venv and pip changes in the new release.

sudo is now sudo-rs

The command is still called sudo, and our sudoers drop-in kept working unchanged (sudo -l -U deploy listed the same rule). Piping a password with sudo -S also worked. Test anything that depends on unusual sudoers features, such as plugins or complex Defaults lines, before you trust it in production. If something breaks, the original C sudo is still installed and you can switch back through alternatives:

sudo update-alternatives --set sudo /usr/bin/sudo.ws

The alternatives system confirms the switch, and sudo --version then reports Sudo version 1.9.17p2:

update-alternatives: using /usr/bin/sudo.ws to provide /usr/bin/sudo (sudo) in manual mode

Return to sudo-rs with sudo update-alternatives --auto sudo. Our sudo-rs guide covers the differences in detail.

ls and most coreutils are the Rust uutils versions

The upgrade installs coreutils-from-uutils, so /usr/bin/ls now resolves to /usr/lib/cargo/bin/coreutils/ls. Ubuntu kept cp, mv and rm on GNU, so /usr/bin/cp links to gnucp and still reports GNU coreutils 9.7. Shell scripts that parse coreutils output or rely on obscure GNU flags are where differences show up. If one breaks, swap GNU coreutils back in. coreutils-from-uutils is a protected package, so apt needs the explicit flag to remove it:

sudo apt install --allow-remove-essential coreutils-from-gnu coreutils-from-uutils-

After that, ls --version reports ls (GNU coreutils) 9.7. The same command with the two package names swapped returns you to uutils. More on what differs in our Rust coreutils guide for Ubuntu 26.04.

OpenSSH 10 drops DSA keys

OpenSSH 10.0 removed DSA support completely. Any user or automation still authenticating with an ssh-dss key is locked out after the upgrade. Grep authorized_keys files for ssh-dss before you upgrade, and replace those keys with Ed25519. Our SSH server configuration guide covers the relevant sshd_config settings, and journalctl filtering helps when you need to find the rejected logins in the systemd 259 journal.

Can I upgrade directly from Ubuntu 22.04 to 26.04?

No. Ubuntu requires sequential LTS upgrades: 22.04 to 24.04 first, then 24.04 to 26.04. Reboot and verify between the two hops. Our 24.04 to 26.04 hop took under 14 minutes, so with both reboots and checks, budget about an hour for the full path.

Is it safe to upgrade a production server?

Rehearse it on a clone first. The base system upgraded cleanly on our test server with zero failed units. The risk sits in your stack: Python modules built for 3.12, scripts that hit coreutils or sudo edge cases, and third-party repos left disabled. Once the upgrade succeeds, work through the Ubuntu 26.04 server post-install checklist and the server hardening guide.

What if the upgrade fails halfway through?

Reconnect (through the backup sshd on port 1022 if you opened it and the main sshd is down) and finish the interrupted package configuration:

sudo dpkg --configure -a && sudo apt -f install

Read /var/log/dist-upgrade/main.log and apt.log to see where it stopped. If the system will not boot, pick the old 6.8 kernel from the GRUB menu, or restore the backup you took before Step 1. Cloud images hide the GRUB menu, so you need the out-of-band console to reach it, and the old kernel is only a recovery path, not somewhere to stay.

NVIDIA driver packages fail with GPG checksum errors

A run that dies while fetching the NVIDIA packages names them in the errors, and the errors point at checksums or GPG signatures rather than at a broken mirror. We could not reproduce the failure itself: on a fully updated 24.04 machine carrying nvidia-driver-580 from the Ubuntu archive, do-release-upgrade carried the driver across cleanly. The package list in /var/log/dist-upgrade/main.log included every nvidia package with no fetch or checksum errors, and DKMS built the 580.178.04 module for both the old 6.8 kernel and the new 7.0 one. What we did verify is the recovery, and it works whatever trips the fetch.

Remove the driver stack first. apt’s pattern purge catches the metapackage, the kernel source, the DKMS package and every library in one pass:

sudo apt purge '~nnvidia'

The summary on our machine listed 19 packages for removal, from nvidia-driver-580 down to xserver-xorg-video-nvidia-580, and freed 1154 MB:

Clear out the dependencies nothing else needs, then run sudo do-release-upgrade again. With no nvidia package installed, nothing references the failing files. Do not reinstall the driver before the upgrade; that puts the failing packages straight back into its path.

sudo apt autoremove -y

Reinstall the same series once the upgrade is done. On 26.04 the 580 series is still in the archive, and the metapackage lands at 580.178.04:

sudo apt install nvidia-driver-580

The install pulls the kernel source, the DKMS package and the client libraries, then builds the module:

On a machine with the GPU present, ubuntu-drivers does the series lookup for you. The plain form installs the full stack, desktop pieces included:

sudo ubuntu-drivers list
sudo ubuntu-drivers install nvidia:580

Keep the plain form on desktops. The --gpgpu variant installs the compute stack only and leaves out the X.Org driver the purge above removed, which puts a desktop machine at a login screen with no display driver. Both forms depend on PCI detection, and on a box without an NVIDIA device they answer in ways that name no package: the plain form claims everything is already installed, and the --gpgpu form reports no drivers found. On our lab VM, which has no NVIDIA hardware and no driver installed, the plain form reports success:

All the available drivers are already installed.

The --gpgpu form is blunter about the same situation:

Either message usually means the PCI detection step found nothing to match nvidia:580 against, and a headless box with the GPU pulled sees the same thing. If the GPU is present and you still see them, check that the series still exists in the archive with apt-cache policy nvidia-driver-580. The metapackage install above does not depend on detection, and it works wherever the archive still carries the series.

Confirm the module built for the new kernel before you reboot. Two lines means both the 7.0 kernel and the 6.8 fallback carry the driver:

dkms status
nvidia/580.178.04, 6.8.0-149-generic, x86_64: installed
nvidia/580.178.04, 7.0.0-43-generic, x86_64: installed

Reboot once the module is built for the new kernel so it loads on the next start. If the driver came from NVIDIA’s own repository instead of the Ubuntu archive, reinstall it from that repository after the upgrade, because the upgrade disables third-party sources along with everything else.

After the reinstall on our driver test machine, before any reboot, the base checks from Step 6 already read clean: the machine reports 26.04.1 on the 7.0 kernel and SSH is still running:

The module itself will not be in use until the reboot happens, but nothing about the purge and reinstall cycle leaves the system in a degraded state, and the driver survives the next restart on its own.