Ubuntu point releases: what 26.04.1 is

What an Ubuntu point release is

An Ubuntu point release, such as 26.04.1, is the release you already have with every update published since launch folded into fresh installation media. It is not a new version. The archive it installs from does not change, and neither does the suite name in your apt sources, so a server that is installed and patched has nothing to download when one appears.

Two things ship on the day. The media is rebuilt: new ISO files and new cloud images, built from the archive as it stood that week. And the version string moves: lsb_release -a starts reporting 26.04.1 LTS where it reported 26.04 LTS before.

Everything else was already yours. Ubuntu publishes fixes continuously into the -security and -updates pockets of one suite, resolute for 26.04 and noble for 24.04. A point release is a snapshot of that stream. There is no separate destination to move to.

Why your patched server has nothing to download

Because the point number lives in one small package. Run this:

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S answers base-files: /etc/lsb-release. The base-files package ships the files that hold your version string, so when a point release is published, a new base-files lands in the -updates pocket and your next sudo apt upgrade installs it. That one package is the whole visible effect of a point release on a running machine. Everything else inside it, you installed weeks ago as ordinary updates.

There is one common way to fall behind. The default /etc/apt/apt.conf.d/50unattended-upgrades enables the -security origin in its Allowed-Origins block and leaves the -updates line commented out, so a machine on automatic updates alone takes security fixes and skips the rest. That machine keeps reporting an older point number for months, and it is right to do so, because it genuinely does not have those packages. Open the file and look at which lines are commented: how unattended upgrades are configured on Ubuntu goes through that block line by line.

When the next point release lands

Learn the cadence, not the date. The first point release of an LTS comes a few months after the April original, and the ones after it follow at roughly six month intervals, tracking each interim release. Dates move. Canonical announced the first 26.04 point release for the start of August 2026 and then pushed it back, which is routine and not a warning sign. Take the date from the Ubuntu release cycle page or the 26.04 LTS release notes rather than from any article, including this one.

Why 24.04 is not offered 26.04 until the first point release

Because the upgrade prompt is configured to wait, and you can read that configuration on your own box.

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

The comments in the shipped file are longer than that excerpt and worth reading in full. Prompt=lts is the default on an LTS install, and it does two jobs: it limits the offer to LTS releases, and it sends the check to a different list.

That list is named in a second file:

cat /etc/update-manager/meta-release

URI points at https://changelogs.ubuntu.com/meta-release and URI_LTS points at https://changelogs.ubuntu.com/meta-release-lts. With Prompt=lts the upgrader reads the LTS list, and the new LTS is not offered there as an upgrade target until its first point release exists. Fetch the list and look for yourself:

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

Each release is a block of Dist:, Version:, Supported: and UpgradeTool: lines. The upgrader needs that block before it can offer you anything. Canonical states the same rule in plain words in the 26.04 LTS release announcement: users of 24.04 LTS are offered the automatic upgrade when 26.04.1 is released.

So on a 24.04 server before that point:

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

That is a healthy result, not a broken one. When the path opens, the same command names the release, and the same message appears in the login banner:

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Notice which version it names. You never upgrade to 26.04 and then again to 26.04.1. You upgrade once and land on the current state of 26.04.

Two other things make that check come back empty: Prompt=never, which some provider images set, and a proxy or mirror that cannot reach changelogs.ubuntu.com. A different message, Please install all available updates for your release before upgrading, means the check succeeded and the upgrader wants a fully patched starting point. do-release-upgrade reporting no new release found works through the remaining causes. When the path is open and you are ready, the 24.04 to 26.04 upgrade itself is a separate job with its own preparation.

The -d flag points the same check at the development list, which is how people move before the path opens. The wait exists for a reason: it is the window in which upgrade blockers reported by early movers get fixed. On a server you rent and depend on, that is an argument for letting the wait do its work.

What the hardware enablement kernel means on a VPS

An LTS ships one kernel for its whole life, the GA (general availability) kernel, and offers a second, rolling track called HWE (hardware enablement). The HWE track is delivered through point releases, and it is the one part of a point release that is genuinely new code rather than a repackaging of what you already have.

24.04 is the worked example. It shipped with kernel 6.8 and keeps 6.8 on the GA track for its full five years of standard support. The HWE track started at the second point release: 24.04.2 brought the 6.11 kernel from Ubuntu 24.10, and 24.04.3 brought 6.14 from Ubuntu 25.04. As of August 2026 that is the established pattern, and 26.04 follows the same shape.

Which track you are on is a package name:

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

linux-generic is the GA track. linux-generic-hwe-24.04 is the rolling one. Desktop installs default to HWE and server installs default to GA, while provider images for a VPS often use something narrower again, such as linux-virtual or a cloud specific linux-kvm. Check rather than assume, because the default depends on who built your image.

On rented virtual hardware, hardware enablement mostly does not apply to you. Your server sees virtio devices, the paravirtualised network and disk interfaces the hypervisor presents, and those drivers have been stable in the kernel for over a decade. A new laptop needs HWE. A VPS almost never does. What a newer kernel actually buys you here is kernel features: newer io_uring and eBPF work, or a filesystem fix you have a specific reason to want. what is new in Linux kernel 7.1 is the way to decide whether any of that is worth the churn.

The cost is reboots and risk. The HWE meta package pulls a new upstream kernel roughly every six months, so you accept a kernel jump and a reboot on that cadence. Out of tree modules built with DKMS, ZFS being the usual one, can fail to build against the new version, and you find out at boot. Each kernel also leaves its predecessor behind, which is how a small /boot fills up. Read removing old kernels from a full /boot and choosing which kernel your VPS boots before you need them rather than after.

Moving to the HWE track is one command and a reboot:

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

uname -r after the reboot should report the newer version. Leave the previous kernel installed until you have booted the new one and checked your services, because the recovery path for a kernel that will not boot is to select the older entry in the boot menu, and that entry has to still exist. If it does not, you are in recovering a VPS that will not boot after a kernel update territory.

There is also an -edge variant of the HWE package that takes the next kernel ahead of the point release. It exists for testing. Leave it alone on a server.

The default answer for a rented server is the GA kernel: one kernel version for five years, with security fixes backported to it for the whole period and no scheduled version jump. Move to HWE when you can name the feature you need.

Why a fresh install today differs from one last month

Images are rebuilt more often than point releases happen. Ubuntu publishes cloud images stamped with a serial, and each provider refreshes its Ubuntu templates on its own schedule. So two servers you created six months apart from the same menu entry can boot different kernel versions and start with different package versions. Neither one is wrong.

This matters more than it sounds. A runbook that says to run five commands after installing quietly assumes a starting state that no longer holds. Check lsb_release -a and uname -r on every box instead of trusting the label you clicked, then define the end state in code so the starting state stops mattering. a first Ansible playbook for a VPS is the smallest useful version of that.

Should you move at the point release, or wait?

• If you are already on 26.04, there is nothing to move to. Keep taking updates and the point number follows on its own.
• If you are on 24.04, standard support runs to April 2029, so waiting is cheap. The first point release is an opening, not a deadline.
• Upgrade a copy first. Snapshot the server, or rebuild the same stack on a throwaway VPS, run the upgrade there, and time how long it takes.
• If what you want is a newer kernel rather than a newer release, the HWE track gives you that on 24.04 with no LTS upgrade at all.

The wider question of which release to stand on is covered in LTS against interim releases for a server.

What to check on your own box

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

A healthy result looks like this: lsb_release -a reports your release with its current point number, uname -r matches the kernel track you meant to be on, Prompt=lts is present, and the check either finds nothing or names the release it will offer. Anything else is worth understanding before an upgrade rather than during one.

FAQ

Do I have to do anything when a point release like 26.04.1 comes out?

No, as long as the server is already on that release and taking updates. A point release rolls already published updates into new installation media. A running machine receives the same content through apt upgrade as it is published, and the version string in lsb_release -a changes when the base-files package updates. There is no separate release to move to and no reinstall.

Why does my server still report an older point number after apt upgrade?

Usually because automatic updates are limited to security fixes. The default /etc/apt/apt.conf.d/50unattended-upgrades enables the -security origin and leaves the -updates line commented out, and the base-files package that carries the version string comes through -updates. Run sudo apt update && sudo apt full-upgrade by hand and check whether base-files appears in the list. If it is listed as kept back, something is pinning or holding it.

Why is my 24.04 server not offered 26.04?

Because Prompt=lts in /etc/update-manager/release-upgrades is the default on an LTS, and it checks the LTS list at https://changelogs.ubuntu.com/meta-release-lts, where the new LTS is not offered as an upgrade target until its first point release. Until then sudo do-release-upgrade -c prints No new release found. and that is correct behaviour. The wait is deliberate: it is the period in which upgrade problems found by early movers get fixed.

Should I install the HWE kernel on my VPS?

Usually not. Hardware enablement exists to support hardware newer than the release, and a VPS presents virtio devices whose drivers have been in the kernel for years. The GA kernel stays on one version for the life of the LTS, with fixes backported to it. Take the HWE kernel when you can name the kernel feature you need, and accept that you then take a kernel jump and a reboot roughly every six months.