Ubuntu 26.04.1 Upgrade Not Showing? Why do-release-upgrade Says No New Release

Quick answer

Status, 19 October 2026: Canonical enabled the supported Ubuntu 24.04 LTS → 26.04.1 LTS upgrade path on 29 September 2026.

Ubuntu Server users can now start the supported upgrade with:

sudo do-release-upgrade

Desktop offers are being rolled out progressively, so some desktop systems may still wait for the graphical notification.

If an Ubuntu Server system that is fully patched still says no new release is available, that is now a troubleshooting condition rather than the expected rollout state. Check Prompt=lts, package health, repository access and the release-upgrade tooling before considering anything more aggressive.

For the actual home-server procedure, use Ubuntu Server 24.04 to 26.04.1 Upgrade Guide for Home Servers. It covers backups, SSH recovery, /etc/fstab, Docker, Jellyfin, third-party repositories and post-reboot verification.

Do not use do-release-upgrade -d on an important home server just because the normal path is not appearing.

Why might the upgrade still not appear?

Ubuntu’s first point release is normally the point at which users of the previous LTS begin receiving the next LTS upgrade offer.

Ubuntu 26.04.1 was released before the supported 24.04 upgrade path opened. That earlier delay is now historical: Canonical announced on 29 September 2026 that upgrades were enabled.

If a supported Ubuntu 24.04 system still does not see the release, common reasons now include:

• the current 24.04 installation is not fully updated
• /etc/update-manager/release-upgrades is not set to Prompt=lts
• held or broken packages prevent a clean upgrade calculation
• third-party repositories or package conflicts block the upgrader
• the system is not on a supported Ubuntu release or architecture
• a desktop notification has not yet arrived during the progressive graphical rollout

Use the checks below and the official 26.04 release notes. Do not change the system to a development-release channel to bypass a missing offer.

Should you use do-release-upgrade -d?

On a disposable test machine, advanced users may deliberately choose to test an early or development upgrade path.

On a production home server, that is a different risk calculation.

If the machine runs services such as:

• Jellyfin
• Docker Compose stacks
• Sonarr or Radarr
• Samba or NFS shares
• mounted USB storage
• MergerFS pools
• reverse proxies
• SSH-only administration

then forcing the upgrade before the normal supported rollout can turn a routine operating-system upgrade into a recovery job.

SmallGrid’s recommendation for a home server is simple:

Use the normal supported 24.04 LTS to 26.04.1 LTS path. If it is missing, fix the underlying release-upgrader or package-health issue instead of forcing a development upgrade.

How to check whether the upgrade is available

First make sure the current system is healthy and fully updated:

sudo apt update
sudo apt full-upgrade

Reboot if the system says one is required:

sudo reboot

Then check the current Ubuntu version:

lsb_release -a

or:

cat /etc/os-release

When you are back online, run:

grep '^Prompt=' /etc/update-manager/release-upgrades
apt-mark showhold
sudo do-release-upgrade

The expected setting for an LTS-to-LTS upgrade is Prompt=lts. Also resolve held packages, interrupted package operations and unsupported third-party repositories before retrying.

If it still reports that no new release is available, follow Ubuntu Server 24.04 to 26.04.1 Upgrade Guide for Home Servers and review the official release notes. Do not use -d or switch to Prompt=normal merely to force this LTS upgrade.

What to prepare before upgrading

A home server has more to protect than a normal desktop. Complete these steps before starting the supported upgrade.

1. Back up Docker Compose files

Find the Compose projects you actually use and copy their configuration somewhere outside the server.

Typical files include:

compose.yaml
docker-compose.yml
.env

Do not rely on remembering how a stack was built six months ago.

2. Record your running containers

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Also record the Docker and Compose versions:

docker version
docker compose version

3. Back up Jellyfin configuration

For Docker, identify the host path mounted as Jellyfin’s configuration directory.

For a native Jellyfin installation, confirm where the server database and configuration are stored before upgrading the operating system.

Do not treat the media library itself as a substitute for a Jellyfin database/configuration backup.

4. Save /etc/fstab

Storage is one of the easiest ways to turn an OS upgrade into a confusing media-server failure.

sudo cp /etc/fstab ~/fstab-before-ubuntu-26-04
cat /etc/fstab

Then verify the active mounts:

findmnt
lsblk -f

Record any UUIDs, network mounts, MergerFS entries or special mount options that your media setup depends on.

5. Check disk space

df -h

Pay particular attention to /, /boot, /var and anywhere Docker stores images or volumes.

6. Protect SSH access

If this is a headless server, make sure you have a recovery path before changing the operating system.

Check SSH is enabled and running:

systemctl status ssh --no-pager

If possible, make sure you also have local console, hypervisor console or physical access available during the upgrade window.

7. Record permissions on media storage

For a Jellyfin server, record how access currently works before changing anything.

Native example:

id jellyfin
namei -l /mnt/media
getfacl -p /mnt/media

Docker example:

docker exec jellyfin id
docker inspect jellyfin --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

This gives you a working baseline if media disappears after the OS upgrade.

Do not upgrade and troubleshoot at the same time

Before moving from 24.04 to 26.04, fix existing issues first.

Do not begin the OS upgrade if:

• Jellyfin currently cannot see part of the library
• Docker containers are restarting unexpectedly
• a storage mount is unreliable
• /etc/fstab contains untested changes
• the root filesystem is almost full
• SSH access is intermittent
• package management already reports dependency errors

An LTS upgrade is much easier to diagnose when the starting system is known-good.

The full SmallGrid upgrade guide is now live

The supported rollout is open, so the preparation work on this page now feeds into the full procedure:

Ubuntu Server 24.04 to 26.04.1 Upgrade Guide for Home Servers

Use that guide for:

1. pre-upgrade health checks
2. backups and recovery planning
3. Docker and Compose state capture
4. storage and /etc/fstab
5. SSH and local-console recovery
6. the supported do-release-upgrade process
7. post-reboot networking and mount checks
8. Docker verification
9. Jellyfin playback and hardware-acceleration checks
10. rollback and observation

Official sources

• Upgrades from Ubuntu 24.04 LTS to Ubuntu 26.04.1 LTS now enabled
• Ubuntu announcement: 24.04 LTS to 26.04.1 LTS upgrades enabled
• Ubuntu 26.04 LTS release notes

Recap

The supported Ubuntu 24.04 LTS to 26.04.1 LTS upgrade path is now enabled.

For Ubuntu Server, sudo do-release-upgrade is now the normal supported starting point once 24.04 is fully patched and healthy. If the release still does not appear, troubleshoot the release-upgrade configuration instead of forcing a development path.

For a production Jellyfin or Docker home server, use the full SmallGrid upgrade guide and keep recovery access, backups, mounts and application state at the centre of the maintenance window.

Keep the permanent fix nearby

Affected SmallGrid guides