Can You Downgrade Ubuntu 26.04 to 24.04?

Can you downgrade Ubuntu 26.04 to 24.04?

You cannot downgrade Ubuntu 26.04 to 24.04 in place. No tool, no do-release-upgrade flag and no apt setting takes a server back one release. To get back to 24.04 you can restore the snapshot or backup you took before the upgrade. You can also build a fresh 24.04 server and move your data onto it. Often the better choice is to stay on 26.04 and fix the one thing that broke.

This guide ranks those paths by cost. It also explains why pointing apt back at noble (the code name of 24.04) does not give you a downgrade. Your database is usually the part that decides which path you can take.

What Ubuntu's own pages say about rolling back

Ubuntu Server's official guide, "How to upgrade your Ubuntu release", has no section on downgrading or rolling back. Its only safety advice is to back up first: "It is extremely important that the data is safely copied to a backup location to allow restoration if any problems occur." The restore it means is a restore from that backup.

On Ubuntu's own Discourse forum, a user asked how to go from 24.04 back to 22.04 without wiping the disk. None of the replies is marked as an official Canonical statement. They all give the same answer. One reply says there is no "downgrade" function similar to an "upgrade" function, and no "undo" for an upgrade. Another says it is "impossible by design, the deb packaging system can only go forward based on version numbers of packages." The closest thing to a downgrade in that thread is restoring a backup.

So the supported tool only goes forward, and if the upgrade fails, the documentation's answer is your backup.

Why a release upgrade cannot run backwards

A release upgrade is thousands of package upgrades run together. Each one is a step forward. Three facts stop you from walking those steps back.

dpkg does not check dependencies on a downgrade. dpkg is the low-level tool that installs .deb files. The 24.04 dpkg manual says it plainly: "At present dpkg does not do any dependency checking on downgrades." The downgrade itself is allowed by default. So dpkg will put an older package on disk even when another installed package needs the newer one. A release is a large set of packages that depend on each other, so reversing it one package at a time is not safe.

Package scripts have already run. A package can ship maintainer scripts, which are small programs that run before and after it is installed. During an upgrade they can rewrite configuration or data so the new version can use it. Installing the old package later does not undo that work. The old program can then find files in a format it never knew.

Services may have moved to a new major version. The default postgresql package on 24.04 depends on PostgreSQL 16. On 26.04 it depends on PostgreSQL 18. The default mysql-server moves from MySQL 8.0 on 24.04 to MySQL 8.4 on 26.04. A database major version can change how it stores data on disk. The PostgreSQL manual says file system level backup methods "will not work" for moving between major versions. PostgreSQL also has checks that stop a server from starting on a data directory from an incompatible version. That check protects your data. It also means the old binaries will not simply read the new data.

The same reasoning applies to a desktop. A desktop just has more packages that depend on each other.

Check what the upgrade actually changed

Before you choose a path, find out what moved. Run these on the 26.04 server:

lsb_release -ds
uname -r
ls /boot/vmlinuz-*
pg_lsclusters
mysql --version

lsb_release -ds should print the 26.04 release name. ls /boot/vmlinuz-* shows which kernels are installed, which matters for path 3. pg_lsclusters exists when PostgreSQL comes from Ubuntu's packages. It lists each cluster with its version, port and data directory. A version 18 cluster holding your data means your data is now in the new format. If it still shows only a version 16 cluster, the upgrade did not move that cluster. In that case, check which binaries serve it before you go further.

mysql --version prints the client version. An 8.4 result after the upgrade means the server package moved too.

The apt history log records every package the upgrade touched:

zgrep -h 'Upgrade:' /var/log/apt/history.log* | head

Path 1: restore the snapshot taken before the upgrade

This is the cheapest path. It is also the only one that gives you back the exact 24.04 server you had. If your provider took a snapshot or a backup before you ran do-release-upgrade, restoring it puts the disk back to that moment. The packages, the kernel, the database files and /etc all match again, because that copy of the disk was never upgraded.

The price is everything written after the snapshot. A restore returns the whole disk to its state at snapshot time, so all of these go back too:

• database rows written since the snapshot
• files your users uploaded
• mail that arrived on the server
• logs, including the logs of the upgrade
• certificates that renewed after the snapshot
• users, cron jobs and configuration you changed since

If the server ran for hours or days on 26.04, some of that data matters. Copy it off before you restore. A quick way to find changed files is to list everything newer than the moment you started the upgrade. Replace the time below with yours:

sudo find /etc /home /srv -type f -newermt '2026-10-14 09:00' > ~/changed-since-upgrade.txt
wc -l ~/changed-since-upgrade.txt

Database rows are the hard part. New rows live in the new database version's format, and you can only carry them back as a logical dump. Path 2 has the same problem, so read the dump section below before you restore.

Two more rules apply. First, take a snapshot of the current 26.04 server before you restore the old one. If the restore goes wrong, you can still return to where you are now. Second, be clear about what you are restoring from. A snapshot kept with the same provider as the server is not the same thing as a backup, and VPS snapshots vs backups explains the difference.

Path 2: rebuild on a fresh 24.04 image

If you have no snapshot from before the upgrade, build a new server from a clean 24.04 image and move your work across. This takes more time. In return, every package on the new box comes from one release, which is what you want.

Capture what matters on the 26.04 server first, while it still runs:

mkdir -p ~/migrate
apt-mark showmanual > ~/migrate/manual-packages.txt
sudo tar czf ~/migrate/etc.tgz -C / etc
sudo tar czf ~/migrate/crontabs.tgz -C / var/spool/cron/crontabs
getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 {print $1}' > ~/migrate/users.txt
sudo chown -R "$USER": ~/migrate
chmod 700 ~/migrate

apt-mark showmanual lists the packages someone installed by name, without everything they pulled in. The etc.tgz archive holds your configuration. It also holds the SSH host keys in /etc/ssh and the password hashes in /etc/shadow, so treat the folder as secret. That is why the last line closes it to other users. crontabs.tgz holds each user's crontab. System cron files in /etc/cron.d are already in the /etc archive. users.txt lists the normal login accounts.

Then dump the databases, as the next section shows, and copy the whole folder to another machine:

rsync -a ~/migrate/ you@backup.example.com:migrate-26.04/

Copy the folder onto the fresh 24.04 server and work inside it. Read the package list before you install it. It holds names from 26.04, and some of them do not exist on 24.04.

cd ~/migrate
sudo apt update
xargs -a manual-packages.txt sudo apt install -y

If one name is missing from the 24.04 archive, apt installs nothing. It stops with a line such as E: Unable to locate package postgresql-18. Delete or rename that line in the file and run the command again. Versioned names like this one are exactly the packages that moved.

Do not unpack etc.tgz over the new /etc. Those files came from newer program versions, and an older version can refuse an option it does not know. Unpack the archive to a side folder and copy back only what you need:

mkdir -p ~/etc-2604
tar xzf etc.tgz -C ~/etc-2604
sudo diff -ru /etc/nginx ~/etc-2604/etc/nginx

After you copy a service's files back, test them before you restart it. sudo nginx -t and sudo sshd -t both check configuration without applying it. If you copy the old SSH host keys back, clients connect without a warning. If you do not, each client shows WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! once, and you must remove the old entry from its known_hosts file.

Will a PostgreSQL or MySQL dump from 26.04 restore on 24.04?

Do not assume it will. Neither project promises that a dump moves to an older major version.

PostgreSQL. The pg_dump manual says it is not guaranteed that its output loads into a server of an older major version. That is true even when the dump came from a server of that older version. The manual adds that loading into an older server "may require manual editing of the dump file". The PostgreSQL 16 manual says the same, and 16 is the version 24.04 ships. Two more details matter here. pg_dump refuses to dump a server newer than its own major version, so use the 26.04 server's own tools, not the 24.04 ones. The manual also recommends --quote-all-identifiers when a dump goes to a different major version, because each version has its own list of reserved words.

On the 26.04 server:

sudo -u postgres pg_dumpall --quote-all-identifiers > ~/migrate/pg-all.sql

On the 24.04 server, after the postgresql package is installed:

cd ~/migrate
sudo -u postgres psql < pg-all.sql 2>&1 | tee restore.log
grep ERROR restore.log

A message that the postgres user could not change directory to your home folder is harmless. It appears because the postgres user cannot read your home folder, and your shell does the file reading and writing anyway. Read every ERROR line in the log. A line saying a role already exists is usually harmless, because the 24.04 install already created the postgres role. A syntax error means the version gap: the dump uses something PostgreSQL 16 does not understand, and you must edit the dump by hand. If your data uses features that only exist in the new version, there may be no clean way back.

MySQL. The MySQL 8.4 manual supports the path from 8.4 LTS (long-term support) to 8.0 only through a logical dump and load, or through replication. It adds a condition: "Only supported for rollback purposes (that is, if no new server functionality has been applied to the data)". So the documented way back depends on whether anything new in 8.4 has touched your data. Dump your application databases by name:

sudo mysqldump --single-transaction --routines --events --databases appdb > ~/migrate/appdb.sql

Load it on 24.04 with sudo mysql < appdb.sql. Then recreate the application users and their grants by hand. An error that stops the load means the dump holds something 8.0 cannot read.

The rule is the same for both databases. Restore the dump on a test 24.04 server, start the application against it, and check real data. Do this before you delete the 26.04 server.

Why pinning apt back to noble is not a downgrade

A common forum answer is to change the apt sources from the 26.04 code name back to noble, then pin those packages to a high priority. It looks like a downgrade, but the result is something else.

apt does not take a package backwards on its own. The apt_preferences manual says apt will "Never downgrade unless the priority of an available version exceeds 1000." So you have to force it with a pin. With that pin in place, apt starts to replace newer packages with older ones, and dpkg does no dependency checking on those downgrades. The same manual warns that downgrading is risky and that mixing distribution releases causes more problems, because packages from one release were never tested next to packages from another.

What you get is a server that holds part of 26.04 and part of 24.04. If one core library stays at its 26.04 version, every package that needs that version stays too. Ubuntu's own apt documentation names "combinations of packages from different releases or third party repositories" as one reason apt keeps packages back. The data in your database is still in the new format as well, so the old database server may not start on it.

If a server is already in that state, set the sources back to the release it mostly runs, and repair the packages with the steps in fixing broken packages with apt. Then choose a path from a clean starting point.

Path 3: stay on 26.04 and fix the regression

Most downgrade requests start with one broken thing: a driver, a kernel, one service or one changed default. Fixing that one thing often costs less than paths 1 and 2. 26.04 has standard security maintenance until May 2031, so it is not a short-lived place to stay.

A kernel regression. The server boots, but the network card or the storage misbehaves. Check whether the old kernel is still installed with ls /boot/vmlinuz-*. If it is, you can boot it while you wait for a fixed kernel. On Ubuntu, GRUB_DEFAULT=1 names a submenu and not your old kernel, so read how to pin which kernel your VPS boots next before you change GRUB. Do not remove the old kernel until the new one works. Leave cleaning up old kernels for later.

A service that changed. The apt history log above shows which packages moved. Read the release notes for that package, and compare its new default configuration with your old file in /etc. When dpkg keeps your edited configuration file, it can save the package's new version beside it with a .dpkg-dist ending. When it installs the new version, it can save your old file with a .dpkg-old ending. Find them all:

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old'

Each file it finds marks a place where the package and your configuration disagreed during the upgrade.

An upgrade that stopped half way. A server where do-release-upgrade crashed has a different problem from one where the upgrade finished and the server works badly. If the upgrade did not finish, follow recovering a failed Ubuntu release upgrade before you think about going back.

Which path to pick

Pick path 1 when a snapshot from before the upgrade exists and the data written since is small, or easy to dump and carry. Pick path 2 when there is no snapshot, or when you want a clean 24.04 install anyway. Pick path 3 when you can name the one thing that broke.

Going back to 24.04 is a reasonable place to land. Standard security maintenance for 24.04 runs to May 2029, and ESM (Expanded Security Maintenance) runs to May 2034. When you try again, remember that the upgrade guide says direct LTS to LTS upgrades "are only available after the first point release". The notes on what changed in Ubuntu 26.04.1 and when to upgrade cover that timing. Take a snapshot and test your database dump first. Then follow the 24.04 to 26.04 upgrade guide with a way back already in place.

FAQ

Can I downgrade Ubuntu 26.04 to 24.04 without reinstalling?

No. Ubuntu has no downgrade tool, and its upgrade guide only plans for failure with a backup. dpkg does no dependency checking on downgrades, so it cannot reverse a release safely. Your real choices are to restore a snapshot or backup taken before the upgrade, to rebuild on a fresh 24.04 image, or to stay on 26.04 and fix the specific problem.

Will my PostgreSQL data work after going back to Ubuntu 24.04?

Not directly. The default PostgreSQL on 26.04 is version 18, and on 24.04 it is version 16. A data directory cannot move between major versions. Take a dump with the 26.04 server's own pg_dumpall --quote-all-identifiers. PostgreSQL does not guarantee that a dump loads into an older major version, so restore it on a test 24.04 server and read every error before you rely on it.

Why not just change the apt sources back to noble?

apt never downgrades a package unless a pin priority above 1000 forces it, and dpkg does no dependency checking on downgrades. Forcing it leaves a server with packages from two releases that were never tested together, which is neither 24.04 nor 26.04. Database files in the new format also stay new, so the old database server may refuse to start on them.

How long is Ubuntu 24.04 supported if I go back?

Canonical's release cycle page lists standard security maintenance for 24.04 LTS until May 2029, and ESM (Expanded Security Maintenance) until May 2034. For comparison, 26.04 LTS has standard security maintenance until May 2031. Going back buys you time, but you will need to upgrade again before standard support for 24.04 ends.