Ubuntu 26.10 on a server: what changes

What changes in Ubuntu 26.10 on a server

Ubuntu 26.10 on a server splits OpenSSH into two packages, removes OpenSSL engine support, deprecates the BerkeleyDB map types in Postfix and moves MySQL from 8.4 LTS to 9.7 LTS. For a production VPS the advice is simple: stay on Ubuntu 26.04 LTS (long-term support), and run 26.10 on a separate test box. Each change below is a preview of what you will meet at the next LTS release, so use 26.10 to find the parts of your config that depend on it.

Ubuntu 26.10, code name "Stonking Stingray", is scheduled for release on 15 October 2026. This guide was written on 8 October 2026 from the draft release notes, and re-checked against them on 12 October 2026. On that day the notes still described 26.10 as in development. They now give the kernel as Linux 7.3 and systemd as version 261. The kernel in the release images, 7.3.0-9.9, is based on 7.3-rc6, because the final upstream 7.3 release comes after general availability. The sections for support lifespan and upgrades were still empty headings, so this guide gives no values for those. Read the Ubuntu 26.10 release notes for them once they are filled in.

The systemd update also finishes a removal announced in earlier notes: systemd-sysv-generator, which built services from /etc/init.d scripts at runtime, is gone. Archive packages that relied on it now ship a systemd service or were removed. On 26.04, list the services that still come from an init script:

grep -l 'systemd-sysv-generator' /run/systemd/generator.late/*.service 2>/dev/null

Each file it prints is a service with no native unit. Write a systemd unit for any you still need before the next LTS.

Most commands below are checks you run on your current 26.04 server today. They read config and print results. They change nothing. The rest run on the 26.10 test box, and each one says so.

Should you run Ubuntu 26.10 on a production VPS?

For most servers, no. Ubuntu 26.04 LTS gets security updates and critical bug fixes for five years, until May 2031. Ubuntu Pro extends that to ten years. The 26.10 notes do not yet state a support period at all. The Ubuntu release cycle page says interim releases get nine months of updates, so check it before you plan around one. The wider trade between the two release types is covered in LTS versus interim releases on a server.

Where 26.10 is useful is as a test box. Create a small second VPS from a fresh 26.10 image, copy your configuration onto it, and see what breaks. A fresh install also matters for one specific reason: it gets the non-Kerberos OpenSSH build by default, which an upgraded system may not.

An in-place upgrade from 26.04 is a different question, and the notes do not answer it yet. Their Upgrades section was still empty on 12 October. Wait for that section before you upgrade anything you care about. If do-release-upgrade later reports that nothing is available, why do-release-upgrade finds no new release covers the usual causes. Before any release upgrade, read how to recover a failed Ubuntu release upgrade, so you know the way back before you need it.

First confirm which release a box runs:

grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release

OpenSSH 10.5 is split into openssh and openssh-gssapi

GSSAPI (Generic Security Service Application Program Interface) is the layer OpenSSH uses for Kerberos logins. Kerberos is a network single sign-on system. In 26.10, OpenSSH comes from two source packages. The openssh packages have no GSSAPI or Kerberos support. That support now lives only in openssh-gssapi. The notes add four points that matter on a server:

• Both packages are at version 10.5.
• Fresh installs of 26.10 get the non-GSSAPI build of both the server and the client.
• The GSSAPI and non-GSSAPI binary packages conflict, so installing one removes the other.
• The release upgrader checks the system for signs that Kerberos is used with OpenSSH, and may select the GSSAPI variants when it finds them.

The word "may" is the reason to check by hand. If your logins depend on Kerberos and the box ends up on the non-GSSAPI build, those logins fail, because the code that handles them is not in the binary. Run these on your 26.04 server now:

sudo sshd -T | grep -i gssapi
grep -rni 'gssapi' /etc/ssh/
ls -l /etc/krb5.keytab
dpkg -l | grep -E 'krb5|sssd|realmd'

sshd -T prints the configuration sshd actually uses. A line reading gssapiauthentication yes means the server accepts Kerberos logins. /etc/krb5.keytab is the usual place for a host's Kerberos key, so a file there is a strong sign the box is joined to a Kerberos realm. If sshd reports no and the other three commands find nothing, the non-GSSAPI build is the right one for you and you can stop here.

If you do use Kerberos, test it on the 26.10 box with the openssh-gssapi variant, and keep a second SSH session open while you swap packages. A package conflict that removes the server you are logged in through is a lockout. After any change, run sudo sshd -t. It validates the config and prints nothing when the config is good.

The package split is one SSH change. Key exchange has changed too, and what changed with post-quantum SSH covers that side.

Sequoia sq and sqv arrive beside gpg and gpgv

OpenPGP is the standard behind package signatures and signed release files. 26.10 adopts Sequoia PGP, written in Rust, into the main archive. Its sq tool is the counterpart to gpg, and sqv is the counterpart to gpgv, the verify-only tool. The notes also say gpg and gpgv are still in main as of 26.10.

That sentence promises nothing about later releases. Treat it as a reason to know where your own scripts call GnuPG. On 26.04:

grep -rlwE 'gpgv?' /usr/local/bin /usr/local/sbin /etc/cron.d /etc/cron.daily 2>/dev/null

Each file it lists calls gpg or gpgv. On the 26.10 box, sq --help and sqv --help show the syntax, so you can see what a port of each script would look like. Sequoia is part of a wider move, which the Rust rewrites in Ubuntu's base system follows component by component.

The last GNU cp, mv and rm move to Rust uutils

The default core utilities in 26.10 run entirely on uutils, the Rust implementation. The notes say cp, mv and rm were kept on GNU until now because of compatibility issues. They have now been migrated too.

Those three are the commands that backup and deploy scripts use most. Compare how they report themselves on 26.04:

cp --version | head -n 1
ls --version | head -n 1

The first line of each output names the implementation. Because these three tools waited the longest, any script that uses an unusual flag of cp, mv or rm is the one to run on the 26.10 box. Run it against a copy of real data and compare the result with the same run on 26.04. A difference in permissions, ownership, timestamps or symlink handling is exactly what this test exists to find.

The OpenSSL ENGINE is removed

PKCS#11 (Public-Key Cryptography Standards number 11) is the standard interface to hardware tokens and HSMs (hardware security modules). Older OpenSSL versions reached those devices through a plugin type called an engine. 26.10 ships OpenSSL 4, which no longer supports engines, so the OpenSSL ENGINE has been removed. The libengine-pkcs11-openssl package now ships only the PKCS#11 provider, and the notes say configurations that still reference the pkcs11 engine must be migrated to it.

Most VPSs never touch PKCS#11. Find out whether yours does:

dpkg -l libengine-pkcs11-openssl
grep -niE 'engine|pkcs11' /etc/ssl/openssl.cnf
grep -rn 'ssl_engine' /etc/nginx/ 2>/dev/null
grep -rn 'SSLCryptoDevice' /etc/apache2/ 2>/dev/null
grep -rn -- '-engine' /usr/local/bin /etc/cron.d 2>/dev/null

ssl_engine is the nginx directive that loads an engine, and SSLCryptoDevice is the Apache one. Ignore lines that start with #, because they are comments. A match on the word engine in openssl.cnf can also be plain comment text, so read each line. If every command comes back empty, or dpkg reports the package is not installed, nothing on this box uses an engine. If something does, the port to a provider has to be done and tested on 26.10 before it is ever needed in production.

Postfix hash: and btree: maps are deprecated

Postfix stores lookup tables, such as virtual aliases and transport maps, as map files. The hash: and btree: types use BerkeleyDB. In 26.10 they are deprecated. They still work, but using them now prints a deprecation warning, and the notes say such maps should be migrated to other formats. Postfix itself is at 3.11.7 in this release.

On 26.04, list every BerkeleyDB map Postfix uses:

postconf -n | grep -E '(hash|btree):'
grep -rnE '(hash|btree):' /etc/postfix/
postconf default_database_type
postconf -m

The first two commands find maps named with an explicit type. The third matters because postmap with no type prefix builds the database type that default_database_type names. A plain postmap /etc/postfix/virtual therefore makes a hash map whenever that value is hash. postconf -m lists the map types your Postfix build supports.

The notes do not name a replacement. The postmap manual lists the file types it can create, including cdb and lmdb, and says lmdb supports concurrent writes and reads from different processes. If postconf -m lists lmdb, a migration of one map on the test box looks like this:

sudo postmap lmdb:/etc/postfix/virtual
sudo postconf -e 'virtual_alias_maps = lmdb:/etc/postfix/virtual'
sudo postfix check
sudo postfix reload

The first line builds /etc/postfix/virtual.lmdb from the same source file. The second points Postfix at it. postfix check reports configuration problems before the reload. If lmdb is missing from postconf -m, run apt-cache search postfix to see which map-type packages Ubuntu ships. Then send a test message and confirm the deprecation warning is gone:

sudo journalctl --since -10min | grep -i deprecat

HAProxy 3.4: the program section is gone

HAProxy moves from 3.2 to 3.4.2, skipping the 3.3 feature release. 3.4 is an upstream LTS branch, supported until 2031-Q2. The program section is gone. HAProxy deprecated it in 3.1 and removed it in 3.3, so on Ubuntu you meet the removal at the jump to 3.4. The master-worker global directive is deprecated but not removed, and HAProxy's 3.3 announcement says to use the -W or -Ws command-line arguments instead. dispatch and option transparent are deprecated too, and some settings that used to pass are now errors. One example from the notes: http-send-name-header can no longer target the connection, content-length, host or transfer-encoding headers.

The change most likely to surprise you is quieter. The default load-balancing algorithm changes from roundrobin to random (power of two choices). A backend with no balance line uses the default, so its traffic pattern changes on upgrade with no edit to your file. Other defaults move as well: option abortonclose is now on by default in mode http backends, and cpu-policy now defaults to performance.

On 26.04, find the lines that will matter:

grep -nE '^\s*(program|master-worker)' /etc/haproxy/haproxy.cfg
grep -nE '^\s*(backend|balance)' /etc/haproxy/haproxy.cfg
grep -n 'http-send-name-header' /etc/haproxy/haproxy.cfg

Any program section is a process HAProxy was starting for you. Move it to its own systemd service before the upgrade. A master-worker line still loads on 3.4, but it is deprecated, so plan to move that setting to the command line. Any backend listed by the second command with no balance line under it will switch to random. If you need round-robin, write balance roundrobin in that backend, which works on both versions. On the 26.10 box, validate the copied file before you start the service:

haproxy -c -f /etc/haproxy/haproxy.cfg

MySQL moves from 8.4 LTS to 9.7 LTS

MySQL is updated from 8.4 LTS to 9.7 LTS, starting with 9.7.2. MySQL Shell, mysqlsh, is at 9.7.1 in the same release. A jump across major versions is where a database upgrade goes wrong, so check the data before the packages move.

MySQL Shell has an upgrade checker. Its documentation says the target version can be any release up to the version of the Shell you run, and that a short form such as 9.7 checks against the release that matches the Shell. The 26.10 box has a 9.7 Shell, so run the checker from there against your 26.04 server. Open an SSH tunnel to the database first, so port 3306 never faces the internet:

ssh -N -L 3307:127.0.0.1:3306 you@your-26-04-server

Then, in a second terminal on the 26.10 box:

mysqlsh -- util check-for-server-upgrade dbadmin@127.0.0.1:3307 --target-version=9.7

Use a MySQL account that can log in over TCP. If root on your server logs in through the local socket only, it cannot use the tunnel, which is why the example uses a separate admin account. The checker sorts what it finds by severity. Every error it reports must be fixed on 26.04 before an upgrade can work.

PHP, Valkey and Apache: the smaller version jumps

PHP goes from 8.5.4 to 8.5.9. The notes describe these as bugfix and security point releases with no new language features, so this is the same PHP branch 26.04 already runs.

Valkey, the Redis-compatible key-value store, is updated to the 9.1 major release, starting with 9.1.2. The notes do not say which Valkey version 26.04 ships, so check your own with valkey-server --version and read the Valkey upgrade notes for every major release in between.

Apache, the apache2 package, goes from 2.4.66 to 2.4.68. The notes say the 2.4.67 and 2.4.68 releases together fix around 25 CVEs (Common Vulnerabilities and Exposures). The package is also rebuilt against OpenSSL 4 and Lua 5.5. If you stay on 26.04, find out whether those fixes have reached your Apache by checking your server for known CVEs.

A test plan for the 26.10 box

1. Create a fresh 26.10 VPS. Do not upgrade a production server to get one.
2. Copy over /etc/ssh/sshd_config.d/, /etc/postfix/, /etc/haproxy/ and your web server config.
3. Run each validator: sudo sshd -t, sudo postfix check, haproxy -c -f /etc/haproxy/haproxy.cfg, then sudo nginx -t or sudo apache2ctl configtest.
4. Run your backup and deploy scripts against copied data, and compare the results with 26.04.
5. Run the MySQL upgrade checker against the 26.04 database.
6. Record every failure as a task to fix on 26.04, before the next LTS release makes it urgent.

A fix you make on 26.04 now, such as an explicit balance roundrobin, works on both releases. That is the real value of an interim release on a server. For how 26.04 itself has moved since launch, see what Ubuntu 26.04.1 changed.

FAQ

Should I upgrade my production VPS from Ubuntu 26.04 LTS to 26.10?

For most servers, no. Ubuntu 26.04 LTS gets security updates and critical bug fixes for five years, until May 2031, and ten years with Ubuntu Pro. On 12 October 2026 the 26.10 release notes still did not state a support period or an upgrade path. Run 26.10 on a separate test VPS, and use it to find config that will break at the next LTS release.

What kernel and systemd versions does Ubuntu 26.10 use?

Linux 7.3 and systemd 261, according to the release notes as read on 12 October 2026. The kernel in the release images, 7.3.0-9.9, is based on 7.3-rc6, because the final upstream 7.3 release comes after 26.10 ships. Some third-party sites gave other kernel versions before the notes were filled in, so go by the notes. To confirm on a 26.10 box, run uname -r and systemctl --version.

Will Kerberos SSH logins still work on Ubuntu 26.10?

Only with the openssh-gssapi package. Fresh 26.10 installs get the openssh build, which has no GSSAPI or Kerberos support. The release upgrader checks for signs of Kerberos use and may select the GSSAPI variant, but verify it yourself with sudo sshd -T | grep -i gssapi and keep a second SSH session open while you change packages.

Do Postfix hash: maps stop working in Ubuntu 26.10?

No. The hash: and btree: map types still work in 26.10, but each use now prints a deprecation warning. The release notes say to migrate those maps to another format. Find them with postconf -n | grep -E '(hash|btree):', and run postconf -m to see which other map types your Postfix supports, such as lmdb or cdb.

Is gpg removed in Ubuntu 26.10?

No. Sequoia's sq and sqv arrive in the main archive as counterparts to gpg and gpgv, and the notes state that gpg and gpgv are still in main as of 26.10. List your own scripts that call GnuPG now, so a later change does not surprise you.