Why the upgrade is not urgent, and when it becomes reasonable
Ubuntu 26.04 LTS was released on 23 April 2026. As with every LTS, Canonical only opens the jump from the previous LTS at the first point release: 26.04.1 was announced on 27 August 2026, but the upgrade offer was held back a few more weeks while fixes for rust-coreutils regressions were backported. The release team announced the opening on 29 September 2026, with a progressive rollout on desktop and do-release-upgrade available at any time on servers.
Let us be candid: nothing is pressing. Ubuntu 24.04 LTS receives standard security updates until May 2029, and until May 2034 with Ubuntu Pro. An up-to-date 24.04 VPS is not an exposed VPS. 26.04 itself is maintained until May 2031.
The upgrade becomes reasonable when three conditions are met: your third-party repositories (Docker, PHP, Node, monitoring agents) publish for resolute, a clone of the VPS has passed the upgrade with your real stack, and you have a maintenance window agreed with the client. For an agency, the right moment is often when a fleet is being standardised: one base to document instead of two.
What this guide lets you do
- Decide between in-place upgrade and a fresh VPS — on measurable criteria, not habit.
- Have a real safety net — a backup already restored once, not a snapshot nobody has tested.
- Survive an SSH drop — thanks to the
screensession the tool opens itself and the fallback daemon on port 1022. - Know where the point of no return is — and therefore what your backup must cover before you reach it.
- Anticipate what breaks —
sudo-rs,rust-coreutils, PHP, MySQL, OpenSSH,docker-composev1, third-party repositories. - Bring third-party repositories back — with the right release name, without reintroducing
apt-key. - Repeat the procedure across a fleet — every step is checked by a command, so it can be reproduced.
Upgrade in place or reinstall a fresh VPS
An in-place upgrade keeps the IP address, SSH host keys, accounts and configuration. It mostly fails where the server has drifted away from a standard installation. Reinstalling on a fresh VPS costs a migration, but leaves the old server intact until the DNS switch: it is the only scenario that offers a real rollback.
Decide with four questions. How many third-party repositories and PPAs are active? Beyond two or three, each one is an unknown that the tool disables during the upgrade. Has your backup ever been restored? If not, the in-place upgrade is a gamble. How much downtime can the client tolerate? According to the Ubuntu documentation the upgrade takes several hours, and the machine reboots at the end. Is the server described in code (Ansible, cloud-init, Compose)? If so, a fresh VPS is quick to rebuild and reinstalling becomes the safer choice.
Rule of thumb: documented server and containerised stack, reinstall; legacy server with few third-party repositories and a proven backup, upgrade in place, after a trial on a clone.
Prerequisites before running anything
The VPS must run a fully updated 24.04: do-release-upgrade refuses otherwise, with an explicit message. Plan a window of several hours, someone present to answer the tool's questions, and an out-of-band console (the provider's web or VNC console) in case SSH does not come back. Port 1022/tcp must be openable temporarily in the firewall.
The tool computes the disk space it needs and stops if space is short: check df -h / and df -h /boot beforehand, and clear the APT cache if needed. On the application side, you need a backup of the data off the VPS, and a snapshot of the whole machine provided by the platform.
A point of honesty: the breaking changes listed below come from the official 26.04 release notes and the documentation of the packages concerned. They were not recorded by a full trial on our side on a Docker, Nginx and PHP-FPM stack. That is precisely why the procedure goes through a clone.
The procedure, step by step
Inventory what comes from outside the distribution
List third-party APT sources with
ls /etc/apt/sources.list.d/and spot packages outside the Ubuntu archive withapt list --installed 2>/dev/null | grep -v ubuntu. Note the PHP version (php -v), whether the old Compose binary is present (which docker-compose && docker-compose version) and the content of/etc/sudoers.d/. This list is your test plan.Back up, then restore once
A platform-side VPS snapshot is only a safety net if it has already been restored once. Take the snapshot, restore it on a test machine, check that the services start. Back it up with an application-level backup stored off the server (databases, volumes,
/etc): our guide Restic backups on a VPS covers the setup.Upgrade a clone first
Create a test VPS from the snapshot (from 99 DH/month) and run the whole procedure on it. Record every question the tool asks, every failed service, every disabled repository. The production upgrade should hold no more surprises.
Fully update 24.04
The Ubuntu Server documentation prescribes
sudo apt updatethensudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true. If the file/run/reboot-requiredexists, reboot before going further. Finally, check that/etc/update-manager/release-upgradescontainsPrompt=lts.Prepare the fallback access
When run over SSH, the upgrade warns that it will start an additional SSH daemon on port 1022, without opening it in the firewall. Open it yourself:
sudo ufw allow 1022/tcp. Keep the provider's web console open in another tab.Start the upgrade
Run
sudo do-release-upgrade, without-d: that option is for development releases and is no longer needed since the LTS path opened. The tool relaunches itself inside ascreensession namedubuntu-release-upgrade-screen-window. If your connection drops, reconnect and resume it withsudo screen -d -r ubuntu-release-upgrade-screen-window. Logs are in/var/log/dist-upgrade/.Answer the questions without reflexes
The tool announces the disabled third-party repositories, then the number of packages to install, upgrade and remove. Read the list of removals. For every locally modified configuration file (
sshd_config,php.ini,nginx.conf), keep your version by default and compare afterwards with the.dpkg-distfile.Cross the point of no return knowingly
The Ubuntu documentation is clear: once the download has finished, the process cannot be cancelled. Packages are replaced and the distribution provides no way back to 24.04. From then on, your only rollback is restoring the snapshot from step 2.
Reboot and verify
The system is only considered upgraded after the reboot offered at the end of the procedure. Then check
cat /etc/os-release,uname -r,systemctl --failedand your services' logs. Close the fallback port withsudo ufw delete allow 1022/tcp.Re-enable third-party repositories, then Docker
Rewrite each third-party source with the release name
resolute. Docker documents a.sourcesfile whoseSuitesline reads the name from/etc/os-release. For PHP, Ondřej Surý's PPA now points topackages.sury.org/php/for Resolute. Then check your stacks with our guide Docker v29 migration on a VPS.
24.04 and 26.04: what changes under your applications
Scroll the table
| Component | Ubuntu 24.04 LTS | Ubuntu 26.04 LTS |
|---|---|---|
| Kernel (GA) | 6.8 | 7.0 |
| PHP (Ubuntu archive) | 8.3 | 8.5 |
| Python 3 | 3.12 | 3.14 |
| OpenSSL | 3.0 series | 3.5 series |
| OpenSSH | 9.6p1 | 10.2p1, DSA keys removed |
| MySQL | 8.0 | 8.4 LTS, `mysql_native_password` locked by default |
| sudo and coreutils | C sudo, GNU coreutils | `sudo-rs` and `rust-coreutils` by default; `cp`, `mv`, `rm` stay GNU |
| Compose | `docker-compose` v1 package (1.29.2) | v1 package absent; `docker-compose-v2` (2.40.3) |
What breaks: what the release notes say
The most visible change is sudo-rs, now the default provider. The original implementation stays installed as sudo.ws. Settings such as requiretty, timestamp_type or mailto in a sudoers file can trigger an unknown-setting error, I/O logging does not exist and sudo-ldap is removed. Switching back to the old sudo goes through sudo update-alternatives --set sudo /usr/bin/sudo.ws, which the Ubuntu announcement discourages without forbidding it.
The core utilities come from rust-coreutils, except cp, mv and rm. The release notes still list open CVEs on this package and an ACL inheritance defect with mkdir -p. The coreutils-from-gnu package restores the GNU versions if a backup or deployment script depends on them.
For a web server, also note: apt-key is removed, the libapache2-mod-php module loses PHP's JIT because of a systemd hardening setting (PHP-FPM is recommended), and cgroup v1 support disappears with systemd 259.
Breaking changes to test on the clone
- sudo — run
sudo visudo -cand replay your scripts that callsudowithout a terminal. - Shell scripts — run your backups and deployments as they are; a
rust-coreutilsdifference shows up on rare options ofdate,lsorstat. - PHP 8.5 — check loaded extensions with
php -mand your CMS compatibility; moving from 8.3 skips an intermediate major release. - MySQL 8.4 — accounts using
mysql_native_passwordare locked by default; find them before the upgrade. - SSH — DSA keys are no longer accepted, and OpenSSH now warns when the key exchange is not post-quantum.
- Compose v1 — the
docker-composev1 package no longer exists in 26.04; any script callingdocker-composewith a hyphen must move todocker compose. - Time synchronisation — chrony replaces systemd-timesyncd on fresh installs; on an upgraded server the switch is manual and optional.
- Third-party repositories — every disabled source must be rewritten for
resolute, and its key managed outsideapt-key.
Close what the upgrade opened
After the reboot, check that the fallback daemon is gone (sudo ss -tlnp | grep 1022 must return nothing) and that the firewall rule is removed. Compare /etc/ssh/sshd_config with sshd_config.dpkg-dist if it exists, then validate the configuration with sudo sshd -t before restarting the service. Our Linux hardening checklist then serves as a full check.
Troubleshooting: the messages you may see
“Please install all available updates for your release before upgrading.” The system is not fully up to date: replay the apt dist-upgrade command from step 4, including the phased-updates option.
“You have not rebooted after updating a package which requires a reboot.” A kernel or library is waiting for a reboot. Reboot, then start the upgrade again.
“No new release found.” Check Prompt=lts in /etc/update-manager/release-upgrades. With Prompt=never, the tool says so explicitly and refuses.
“Required apt sources are missing” The tool can no longer find a usable Ubuntu source, often because of a custom mirror. Accept to continue with the default sources, or fix the main source before starting again.
Foreign packages list that cannot be scrolled. The release notes report this defect on upgrades from 24.04: cancel, purge unneeded foreign packages, then start again.
The SSH connection drops. Reconnect on port 22 or 1022, then resume the session with sudo screen -d -r ubuntu-release-upgrade-screen-window.
One upgrade per VPS, one method for the whole fleet
Moving from 24.04 to 26.04 is not an emergency: it is a project to plan before May 2029, at your pace and your clients'. What makes the difference is not the command, which fits on one line, but what surrounds it: an inventory, a backup already restored, a trial on a clone, an agreed window, a rollback you know how to run.
For an agency, the benefit is turning this procedure into a routine. Write down the breaking changes met on the first clone, and they become the test plan for the next VPS. The whole fleet ends up on a single base, documented once, maintained until May 2031. This guide describes the procedure; the release upgrade remains your responsibility, and ServOrbit does not run it on your VPS.
