Ubuntu 26.04.1 na wetin, and why server no download?

Wetín Ubuntu point release be

An Ubuntu point release, like 26.04.1, na the release wey you already get, with every update wey dem publish since launch join inside fresh installation media. E no be new version. The archive wey e install from no change, and the suite name for your apt sources no change too. So, server wey dem install and patch already no get anything to download when point release appear.

Two things dey happen that day. Dem rebuild the media: new ISO files and new cloud images, wey dem build from the archive as e be that week. And the version string change: lsb_release -a begin report 26.04.1 LTS where e report 26.04 LTS before.

Everything else don already dey your system. Ubuntu dey publish fixes continuously into the -security and -updates pockets of one suite, resolute for 26.04 and noble for 24.04. Point release na snapshot of that update stream. No separate destination dey wey you need move go.

Wetin make your patched server no get anything to download

Na one small package dey hold the point number. Run this:

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

dpkg -S answer base-files: /etc/lsb-release. The base-files package dey release the files wey hold your version string, so when dem publish one point release, new base-files dey enter the -updates pocket and your next sudo apt upgrade go install am. Na that one package be the complete visible effect of point release for machine wey dey run. You don install everything else inside am weeks ago as ordinary updates.

One common way wey machine fit fall behind dey. The default /etc/apt/apt.conf.d/50unattended-upgrades dey enable -security origin for its Allowed-Origins block and leave the -updates line commented out. So machine wey dey use automatic updates alone go take security fixes but skip the rest. That machine go continue report older point number for months. E correct to do so because e truly no get those packages. Open the file and check which lines get comment: how unattended upgrades dey configured for Ubuntu explain that block line by line.

When di next point release land

Learn di cadence, no be di date. Di first point release of an LTS dey come some months after di original wey release for April, and di ones after am dey follow roughly six-month intervals, as dem dey track each interim release. Dates fit change. Canonical's 26.04 release announcement schedule di first point release for 4 August 2026, and 26.04.1 actually release on 27 August 2026. Dis na normal thing and e no mean say problem dey. Now wey e don arrive, wetin 26.04.1 actually contain worth reading before you decide whether e change anything for your server. Take di date of di next one from di Ubuntu release cycle page or di 26.04 LTS release notes, instead of any article, including dis one.

Why dem no offer 26.04 from 24.04 until the first point release

Because upgrade prompt dey configured to wait, and you fit read that configuration for 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 for the shipped file long pass this excerpt, and e worth reading everything. Prompt=lts na the default for LTS install, and e dey do two things: e limit the offer to LTS releases, and e send the check go another list.

Dem name that list for a second file:

cat /etc/update-manager/meta-release

URI point to https://changelogs.ubuntu.com/meta-release, and URI_LTS point to https://changelogs.ubuntu.com/meta-release-lts. With Prompt=lts, the upgrader dey read the LTS list, and e no offer the new LTS as upgrade target until e first point release don exist. Fetch the list and check am yourself:

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

Each release na one block of Dist:, Version:, Supported: and UpgradeTool: lines. The upgrader need that block before e fit offer anything. As of 10 October 2026, the list end with the 26.04 block: Dist: resolute, Version: 26.04.1 LTS, Supported: 1, and one UpgradeTool: line wey point inside resolute-updates. Canonical explain the rule plainly for the 26.04 LTS release announcement: users of 24.04 LTS go get automatic upgrade offer when 26.04.1 release. The 26.04.1 release announcement of 27 August 2026 push that back: the offer through Update Manager go follow a couple of weeks after the release, after backports wey fix regressions for rust-coreutils don land. Dem enable upgrades on 29 September 2026, and dem roll out the offer gradually over the following days.

So for a 24.04 server before dem enable upgrades, na this the check print:

sudo do-release-upgrade -c

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.

The wording fit mislead person, because nobody ask for development version. But with Prompt=lts, na simply how the upgrader dey say say nothing newer dey for the LTS list. No new release found. na the message for the same situation under Prompt=normal. Before dem enable upgrades, either result healthy, no be broken result. The path don open now, so for fully patched 24.04 server, the same command go name the release, and the same message go show for login banner:

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

Notice the version wey e name. You no upgrade go 26.04, then upgrade again go 26.04.1. You upgrade once and land for the current state of 26.04.

Two other things fit make that check return empty: Prompt=never, wey some provider images set, and proxy or mirror wey no fit reach changelogs.ubuntu.com. Another message, Please install all available updates for your release before upgrading, mean say the check succeed and the upgrader want fully patched starting point. do-release-upgrade dey report say e no find new release dey handle the remaining causes. When you ready, the 24.04 to 26.04 upgrade itself na separate work with e own preparation.

The -d flag point the same check go development list, and na how people move before the path open. The wait get reason: na the period when dem dey fix upgrade blockers wey early movers report. For server wey you rent and depend on, na good reason to let the wait do e work.

Wetín the hardware enablement kernel mean for VPS

An LTS dey ship one kernel for im whole life, the GA (general availability) kernel, and e dey offer another rolling track wey dem call HWE (hardware enablement). HWE track dey come through point releases. For server, na the one part of point release wey genuinely get new code, instead of just repackaging wetin you already get.

24.04 na the example wey we go use. E ship with kernel 6.8 and e go remain for 6.8 on GA track throughout the full five years of standard support. HWE track start for the second point release: 24.04.2 bring the 6.11 kernel from Ubuntu 24.10, and 24.04.3 bring 6.14 from Ubuntu 25.04. As of August 2026, na this pattern dem don establish, and 26.04 follow the same shape.

The package name show which track you dey use:

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

linux-generic na the GA track. linux-generic-hwe-24.04 na the rolling one. Desktop installs dey default to HWE, while server installs dey default to GA. But provider images for VPS often use another narrower option, like linux-virtual or cloud-specific linux-kvm. Check instead of assuming, because the default depend on who build your image.

For rented virtual hardware, hardware enablement mostly no concern you. Your server dey see virtio devices, plus the paravirtualised network and disk interfaces wey the hypervisor present. Those drivers don stable for the kernel for more than one decade. New laptop need HWE. VPS almost never need am. Wetin newer kernel actually give you here na kernel features: newer io_uring and eBPF work, or filesystem fix wey you get specific reason to want. wetin new for Linux kernel 7.1 na the way to decide whether any of dem worth the churn.

The cost na reboots and risk. HWE meta package dey pull new upstream kernel roughly every six months, so you accept kernel jump and reboot on that schedule. Out-of-tree modules wey DKMS build, like vendor driver or zfs-dkms package wey you install instead of the ZFS modules Ubuntu already ship inside im kernel packages, fit fail to build against the new version. That build dey happen when dem install the kernel package, so the error go show for apt output. If nobody read the output, you go discover am during boot. Each kernel still leave the previous one behind, and na so small /boot fit fill up. Read how to remove old kernels from full /boot and how to choose which kernel your VPS go boot before you need dem, no be after.

To move go HWE track, na one command and one reboot:

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

uname -r after the reboot suppose report the newer version. Leave the previous kernel installed until you don boot the new one and check your services. If the new kernel no boot, recovery na to select the older entry for the boot menu, and that entry must still dey there. If e no dey, you don enter how to recover VPS wey no boot after kernel update matter.

Another -edge variant of the HWE package dey available. E dey take the next kernel before the point release. Na for testing dem create am. Leave am alone for server.

For rented server, the default answer na GA kernel: one kernel version for five years, with security fixes backported to am throughout the whole period and no scheduled version jump. Move go HWE when you fit name the feature wey you need.

Fresh install wey you do today no be the same as one wey you do last month

Images dey rebuild more often than point releases dey happen. Ubuntu dey publish cloud images wey get serial stamp, and each provider dey refresh im Ubuntu templates according to im own schedule. So two servers wey you create six months apart from the same menu entry fit boot different kernel versions and start with different package versions. None of dem wrong.

This matter pass as e dey sound. Runbook wey talk say make you run five commands after installation dey quietly assume starting state wey no longer dey exist. Check lsb_release -a and uname -r for every box instead of trusting the label wey you click, then define the end state for code so the starting state no go matter again. one first Ansible playbook for VPS na the smallest useful version of that.

Make you move when point release show, or make you wait?

• If you dey already use 26.04, you no get anywhere to move go. Continue to take updates, and the point number go follow by itself.
• If you dey use 24.04, standard support go reach middle of 2029 (Canonical release list talk say na June 2029, while the release cycle page talk say na May 2029), so waiting no cost much. The first point release na opportunity, no be deadline.
• Upgrade one copy first. Take snapshot of the server, or rebuild the same stack for throwaway VPS, run the upgrade there, and record how long e take.
• If na newer kernel you want, instead of newer release, HWE track go give you that for 24.04 without any LTS upgrade.

The bigger question of which release to use as your base dey covered for LTS versus interim releases for a server.

Wetin to check for your own box

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

Healthy result suppose look like this: lsb_release -a go report your release together with the current point number, uname -r go match the kernel track wey you intend to use, Prompt=lts go dey present, and the check go either name the release wey e go offer, wey for patched 24.04 server na now 26.04.1 LTS, or report say nothing newer dey, wey na the correct answer for 26.04. Anything else na something wey you suppose understand before upgrade, no be during upgrade.

FAQ

I need do anything when point release like 26.04.1 come out?

No, as long as the server don already dey on that release and dey receive updates. Point release dey package updates wey don already publish into new installation media. Running machine dey receive the same content as dem publish am, through apt upgrade, or through apt full-upgrade for the occasional update wey need remove installed package, which plain upgrade dey hold back. The version string for lsb_release -a dey change when base-files package update. No separate release dey to move go, and no need reinstall.

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

Most times na because automatic updates dey limited to security fixes. Default /etc/apt/apt.conf.d/50unattended-upgrades dey enable -security origin and leave -updates line commented out, while base-files package wey carry the version string dey come through -updates. Run sudo apt update && sudo apt full-upgrade by hand and check whether base-files dey appear for the list. If e dey listed as kept back, something dey pin or hold am.

Why 24.04 server no dey offer me 26.04?

By now, e suppose don offer am. Prompt=lts for /etc/update-manager/release-upgrades na the default for LTS, and e dey check the LTS list for https://changelogs.ubuntu.com/meta-release-lts, where the new LTS no dey offered until the first point release. 26.04.1 release on 27 August 2026, upgrades from 24.04 enable on 29 September 2026, and as of 10 October 2026 that list get resolute block for 26.04.1 LTS with Supported: 1. Before upgrades enable, sudo do-release-upgrade -c print There is no development version of an LTS available., and that one correct behaviour. If your server still no dey offer the upgrade, check say Prompt no set to never, say the server fit reach changelogs.ubuntu.com, and say every available update don install.

I suppose install HWE kernel for my VPS?

Most times, no. Hardware enablement dey support hardware wey newer pass the release, and VPS dey present virtio devices whose drivers don dey inside kernel for years. GA kernel dey stay on one version for the whole LTS lifetime, with fixes backported to am. Use HWE kernel when you fit name the kernel feature wey you need, and accept say you go then take kernel jump and reboot roughly every six months.