Ubuntu 26.04.1: what changed, when to upgrade

Ubuntu 26.04.1 in short

Ubuntu 26.04.1 LTS (long-term support) was released on 27 August 2026, four months after Ubuntu 26.04 LTS shipped on 23 April 2026. It is a roll-up of the existing release: the same Linux 7.0 kernel and the same package set, with every stable release update (SRU) and security update published up to 25 August 2026 built into fresh install media. A 26.04 server that has been running apt full-upgrade already has everything in it. A 24.04 LTS server is the one this release matters for, because the first point release is when Canonical opens the upgrade path from the previous LTS. As of 18 September 2026 that path is not open yet, and one public text file tells you the day it opens.

What a .1 point release is

A point release is a snapshot. Canonical takes the 26.04 archive as it stands, with all the updates that have landed in resolute-updates and resolute-security since April, and builds new ISO and cloud images from it. The release announcement puts it in one sentence: "This point release includes many updates and updated installation media has been provided, so that fewer updates will need to be downloaded after installation." Nothing changes about support. The five years still count from April 2026, so 26.04.1 is supported until April 2031, exactly like the April image. The general mechanics, including why later point releases carry a newer kernel and this one does not, are in how Ubuntu point releases work. What follows is specific to 26.04.1.

What changed in Ubuntu 26.04.1

The full list is on the official 26.04.1 release notes page. It is long, and most of it is desktop and laptop hardware. Below are the entries that matter on a server.

Kernel: still Linux 7.0, no HWE stack yet

26.04 LTS shipped with Linux 7.0, up from 6.8 in 24.04. The .1 release stays on 7.0. The notes list several linux SRU builds under the kernel section (the 7.0.0-15.15 tracker among them), so uname -r on a patched machine shows a higher ABI (application binary interface) number than the April image, but the same 7.0 series. There is no HWE (hardware enablement) kernel in 26.04.1. Ubuntu's kernel lifecycle page states the pattern: ".2 and newer point releases ship with an updated kernel" for the desktop, while "Server installations default to the GA kernel and provide the enablement kernel as optional." GA means general availability, the kernel the release launched with. On a VPS this means you stay on 7.0 for the life of the release unless you choose otherwise, and whether a server should take the HWE kernel at all is a separate decision you do not need to make today.

One kernel fix is worth naming. Bug 2158267, "Performance regression causes SDXL inference slowdown (~42x)", was fixed in the generic kernel and most cloud flavours. If you run inference workloads on 26.04 and saw them slow down after a kernel update, that is the entry to read.

Server and cloud fixes

• openssl: a security update for the "HollowByte Denial of Service issue" (bug 2161371).
• rsync: "Regression fixes from May 2026 security update" (bug 2155874). If rsync broke for you in May, .1 media carries the fix.
• exim4: three security updates, including a one-byte write into a freed buffer and an information disclosure in PROXYv2.
• ca-certificates: the Mozilla certificate authority bundle moved to version 2.86.
• systemd: a delay in cloud-init caused by a systemd-networkd resolve hook is fixed (bug 2148619), and the core now opens its netfilter socket only when needed.
• libvirt and qemu: a fix for "excessive memory allocation when physical_package_id is large", and a fix for a race between iothreads and throttle groups.
• apparmor: a new upstream release, plus a profile fix for "uucore locales reads". uucore is the shared code under rust-coreutils, and this fix belongs to the same story that is delaying the 24.04 upgrade prompt, covered below.
• ubuntu-meta: pollinate was removed from the cloud-minimal, server, server-minimal and server-raspi seeds, and curl was added explicitly to cloud-minimal and server-minimal. Both changes apply to what a fresh install from .1 media contains.
• debootstrap: "Detect and support SHA512 in Release index files", which matters if you build chroots or containers from the 26.04 archive.
• base-files: /etc/os-release now reads 26.04.1, and the earlier "missing LTS in VERSION" bug is fixed, so the string reads 26.04.1 LTS (Resolute Raccoon).

Installer media

The new ISOs carry four livecd-rootfs fixes. The one a VPS user may meet is "fix: update nocloud password data format" (bug 2149891), which affects unattended installs that pass a password through the NoCloud datasource. The others set kernel and initrd permissions in the casper directory to 0644 and correct two riscv64 boot options. On a provider image you rarely install from ISO, so the practical effect is that a template built from 26.04.1 boots with the security updates through 25 August 2026 already applied.

The release upgrader

Five ubuntu-release-upgrader entries are in .1, and one of them affects every 26.04 machine. Bug 2154602, "data/release-upgrades: set Prompt=lts for resolute", fixed a mistake in the April release: /etc/update-manager/release-upgrades shipped with Prompt=normal, which is the interim-release setting. Version 1:26.04.22 sets it to Prompt=lts. Without that fix, a 26.04 server would be offered 26.10 in October. The others are quirks for the 24.04 path ("mark libfile-libmagic-perl for install on Noble"), a Raspberry Pi quirk, a lint cleanup, and a refreshed mirror list.

How a 26.04 server reaches 26.04.1

There is no upgrade to run. The point release is the archive state, and your server tracks the archive through apt. Two commands bring any 26.04 install to the same state as the .1 media, or past it.

sudo apt update
sudo apt full-upgrade

Use full-upgrade rather than upgrade. apt upgrade refuses to remove anything, so when a package update needs an old package gone it prints The following packages have been kept back and leaves them at the old version. full-upgrade is allowed to remove, so it finishes the job. Check the version string afterwards.

grep VERSION= /etc/os-release

You should see VERSION="26.04.1 LTS (Resolute Raccoon)". If the string still lacks the .1, the base-files update has not been applied, which usually means apt update failed against your mirror. Read the output of apt update again. A mirror that has not synced yet is the common cause on a fresh provider image.

Next, find out whether the kernel moved.

cat /var/run/reboot-required
uname -r

*** System restart required *** means a package that needs a reboot was installed, and on a server that is almost always the kernel. uname -r shows the kernel that is running now. The new one is not active until you reboot, so reboot when you can afford a minute of downtime. If the machine does not come back, a VPS that stops booting after a kernel update almost always boots on the previous kernel from the GRUB menu. Once it is up on the new kernel, sudo apt autoremove --purge clears the old ones, and cleaning up old kernels on Ubuntu covers what to keep.

Last, confirm the upgrader fix landed.

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

You should see Prompt=lts. If you see Prompt=normal, you or a provisioning script edited that file before .1, so dpkg kept your copy instead of installing the new one. Set it to lts by hand. The difference decides whether your server is offered 26.10 next month or the next LTS in 2028, and why a server should stay on LTS releases covers the reasoning.

Why a 24.04 server still says there is nothing to upgrade to

This is the part that confuses people, because 26.04.1 exists and the upgrader still says no. The reason is one flag in one text file that Canonical controls.

On a 24.04 server, /etc/update-manager/release-upgrades holds Prompt=lts. With that setting, do-release-upgrade downloads https://changelogs.ubuntu.com/meta-release-lts and reads the list of releases in it. For each release newer than yours, it checks a Supported: field. The relevant loop in update-manager's MetaRelease.py, trimmed:

for dist in dists:
    if dist.date > current_dist.date:
        if not dist.supported and not self.useDevelopmentRelease:
            continue
        upgradable_to = dist
        break

A release with Supported: 0 is skipped as if it did not exist. You can read the file yourself.

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A4 '^Dist: resolute'

As of 18 September 2026 it prints this:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04.1 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

The Version line already says 26.04.1, so the file was updated for the point release. Only the Supported flag is still 0. Because of that, the loop finds no upgradable release, new_dist stays empty, and do-release-upgrade prints the message written for the Prompt=lts case:

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.

Read that message as "no LTS is being offered to you yet", and ignore the hint about Prompt=normal. Setting it would make the upgrader read the interim-release list instead and offer you 25.10, a release with nine months of support, and you would then need a second upgrade to reach 26.04. The shorter No new release found. message is the same condition on a machine whose file already says Prompt=normal, and what to do when do-release-upgrade finds no new release goes through both messages and their other causes. One more message is worth knowing. Please install all available updates for your release before upgrading. means you have pending updates on 24.04, and the fix is sudo apt full-upgrade before you try again.

Why has the flag not flipped? The 26.04.1 announcement said: "Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils." 26.04 is the first LTS where ls and the other core utilities come from rust-coreutils instead of GNU coreutils, and what the Rust rewrites in Ubuntu's base system change explains why an upgrade from 24.04 is where a regression in them appears first. Canonical is holding the automatic prompt until those fixes are in resolute-updates. When they are, the file changes to Supported: 1. From then on the SSH login banner on 24.04 shows New release '26.04.1 LTS' available. followed by Run 'do-release-upgrade' to upgrade to it., and the same command that said no starts offering 26.04.1 with no change on your side.

If you do not want to wait

The announcement also names the way around the flag: do-release-upgrade -d. The flag's help text reads "If using the latest supported release, upgrade to the development release", which sounds like 26.10 but is not, on an LTS. With Prompt=lts, -d does two things in the code above. It appends -development to the URL, so the upgrader reads meta-release-lts-development, and it sets useDevelopmentRelease, which is the second half of the continue condition. The Supported: 0 skip no longer applies, and resolute is offered. That file lists the newest LTS, so -d on 24.04 offers 26.04.1 rather than 26.10.

sudo do-release-upgrade -d

The cost is that you get 26.04.1 as the archive stands today, before the rust-coreutils backports Canonical is waiting on. On a server you can rebuild from a snapshot, that is a reasonable choice. On one you cannot, wait for the flag. Either way, take a snapshot first, and read the full 24.04 to 26.04 upgrade walkthrough for the SSH port 1022 fallback and the third-party repository handling. If the upgrade stops halfway, recovering a failed Ubuntu release upgrade is the page to have open.

The decision

Already on 26.04: nothing special to do. Run sudo apt update && sudo apt full-upgrade and reboot if /var/run/reboot-required exists. Then confirm Prompt=lts. You were never behind, because the point release is the update stream you were already on.

On 24.04: the upgrade path is about to open but, as of 18 September 2026, it is closed. Run the curl line above once a week. When Supported: reads 1, plan the upgrade with a snapshot taken first. If you want 26.04 before then, do-release-upgrade -d gives you 26.04.1 today, with the caveat above. 24.04 LTS itself is supported until April 2029, so waiting a few more weeks for the flag costs you nothing.

On 22.04 or an interim release: the release notes are explicit that "you must first upgrade to either Ubuntu 24.04 LTS or 25.10 before you can proceed to 26.04 LTS". Go to 24.04 first, then follow the 24.04 path above.

FAQ

Is Ubuntu 26.04.1 a new version I need to install?

No. Ubuntu 26.04.1 LTS, released on 27 August 2026, is the 26.04 archive with four months of updates built into new install media. A 26.04 server that runs sudo apt update && sudo apt full-upgrade is at or past the .1 state, and grep VERSION= /etc/os-release shows 26.04.1 LTS (Resolute Raccoon) once the base-files update is applied. Support still ends in April 2031, counted from the April 2026 release.

Why does do-release-upgrade on 24.04 say there is no development version of an LTS available?

Because Prompt=lts makes the upgrader read meta-release-lts, and that file lists 26.04.1 with Supported: 0. The upgrader skips unsupported entries, finds nothing newer, and prints the message written for the Prompt=lts case. Canonical flips the flag to Supported: 1 when the upgrade path opens, and the 26.04.1 announcement tied that to backports for rust-coreutils regressions. Do not set Prompt=normal; that offers 25.10, an interim release.

Does 26.04.1 include a new kernel?

No. 26.04.1 stays on the Linux 7.0 series that 26.04 LTS shipped with, updated through several SRU builds. The first HWE kernel arrives with a later point release, .2 by Ubuntu's usual pattern, and server installs default to the GA kernel even then. A VPS on 26.04 keeps 7.0 unless you opt into the HWE stack yourself.

Should I use do-release-upgrade -d to move from 24.04 now?

The announcement offers it for anyone who does not want to wait. -d with Prompt=lts reads the LTS development list and ignores the Supported: 0 flag, so it offers 26.04.1 rather than 26.10. You get the archive as it stands before the rust-coreutils backports Canonical is waiting on. Take a snapshot first. Use it on a server you can rebuild, and wait for the flag on one you cannot.