Ubuntu 26.10 Server Upgrade Checklist: 12 Checks Before Leaving LTS

cat /etc/os-release
uname -r
dpkg --print-architecture

Record the current release from VERSION_ID. If it is not Ubuntu 26.04 LTS, do not assume the same upgrade path applies.

Check the official release documentation before planning an upgrade. A release being scheduled or having beta images available does not mean it is ready for production deployment.

apt-mark showhold
dpkg --audit
apt list --upgradable

These commands inspect package state without performing a release upgrade.

Review repository configuration:

grep -RhsE \
'^(deb |URIs:|Suites:)' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/ \
2>/dev/null

Check whether external repositories, PPAs, custom packages, and vendor agents explicitly support the proposed target release.

Third-party repositories are commonly disabled during Ubuntu release upgrades, while software installed from them may remain on the system. This can create dependency and maintenance problems.

df -h
df -i
lsblk -f

Pay particular attention to the root filesystem, /var, package-cache space, and any separate /boot or EFI system partition.

Do not assume a fixed amount of free space is enough for every server. The required headroom depends on the package set, filesystem layout, and upgrade plan.

For a broader diagnostic workflow, see the Linux Server Health Check Checklist.

dpkg-query -W \
'openssh*' \
'krb5*' 2>/dev/null

On systems running OpenSSH, review the effective server configuration using the available sshd utility and appropriate privileges:

sudo sshd -T

For configurations using Match directives, the effective result may depend on the connection context. Test the actual authentication methods your administrators and automation use.

The official Ubuntu 26.10 release notes explain that GSSAPI/Kerberos support moves to the openssh-gssapi package family. Ubuntu’s release upgrader is designed to detect indications of GSSAPI use and select appropriate packages, but that detection should not replace validation.

Confirm whether access depends on SSH keys, passwords, Kerberos tickets, bastion hosts, or another authentication system.

For a wider access review, use the Linux Server Security Audit Checklist.

openssl version -a

dpkg-query -W \
'openssl' \
'libssl*' 2>/dev/null

These commands report the current system’s package information. They do not establish whether every application will work with OpenSSL 4.

Inventory applications with native OpenSSL dependencies, including custom binaries, authentication components, TLS integrations, and PKCS#11 configurations.

Ubuntu 26.10’s release notes specifically identify the move away from the legacy PKCS#11 engine toward the provider interface.

Test affected applications in an isolated environment using the actual target release.

systemctl --failed

systemctl list-units \
--type=service \
--state=running \
--no-pager

journalctl -p err -b -n 30 \
--no-pager

These commands provide a baseline of systemd service state and recent errors. Journal access may depend on account permissions.

The Ubuntu 26.10 release notes identify additional compatibility considerations, including HAProxy configuration changes and removal of support for generating systemd services from legacy System V init scripts.

If you use HAProxy, validate its configuration against the version shipped by the target release. If services rely on legacy /etc/init.d scripts, verify that supported native systemd units exist.

For service inspection and safer operational changes, review systemctl Commands Explained.

uname -r
lsmod
systemd-detect-virt

If DKMS is installed, inspect registered modules:

dkms status

The last command may be unavailable on servers without DKMS.

Inventory any out-of-tree modules, proprietary GPU drivers, backup agents, endpoint security software, VPN components, or vendor tools that rely on particular kernel interfaces.

For cloud systems, check the hosting provider’s supported guest operating systems, image availability, and recovery procedures.

Before planning the upgrade, document:

• The most recent successful backup.
• Coverage of databases, application files, and configurations.
• Independent storage outside the original server.
• Backup encryption and access to recovery keys.
• The result of a recent isolated restoration test.

Filesystem snapshots may be useful, but they are not automatically equivalent to consistent, independent backups.

Use the Linux Server Backup & Restore Checklist to verify data coverage, backup integrity, recovery objectives, and restoration procedures.

A useful staging test should reproduce:

• The source Ubuntu release and package set.
• Relevant third-party repositories and applications.
• Representative application configurations.
• Database engines and compatible test data.
• Authentication and remote access methods.
• Service startup after a full reboot.

Perform the release upgrade only inside the isolated environment and only when an appropriate target-release image or supported upgrade path is available.

Record failures and compare application behavior with the original baseline.

Check that you have the necessary recovery capabilities:

• Provider console or equivalent emergency access.
• A verified way to reach the server if SSH fails.
• Documented access credentials and recovery keys.
• Independent backups and compatible recovery media.
• A tested method to restore the previous server state.

Ubuntu does not provide a general supported in-place downgrade from a newer release back to an older LTS version. Recovery usually requires restoration or redeployment from a known-good state.

A snapshot may help where provider support and application consistency are confirmed, but it should not be treated as an automatic rollback guarantee.

Document the operational change:

• Approved maintenance date and time.
• Expected customer or application impact.
• Maximum acceptable downtime.
• Recovery-point and recovery-time objectives.
• Required personnel and escalation contacts.
• Application-specific acceptance tests.

A successful reboot does not prove that the application is healthy.

Plan to verify authentication, networking, application responses, database connectivity, background jobs, monitoring, and backups after the change.

Write a short decision record answering:

• Which required capability is missing from the current environment?
• Why is upgrading the operating system the appropriate solution?
• Can the requirement be met while remaining on LTS?
• Are all critical applications compatible?
• Can the team support the shorter interim-release lifecycle?
• Are the staging tests and recovery procedures successful?

If there is no clear operational benefit, remaining on Ubuntu 26.04 LTS is a valid and often preferable outcome.