Ubuntu 26.04.1 Home Server Upgrade Guide: 24.04 to 26.04 Safely

Quick answer

Ubuntu 26.04.1 LTS was officially released on 27 August 2026. It is the sensible point at which many Ubuntu 24.04 LTS home-server users will first consider moving to 26.04 LTS, but it does not mean every working server should upgrade immediately.

Stay on Ubuntu 24.04 LTS if it is stable, supported and doing everything you need. Consider 26.04.1 when you need its newer hardware support or platform changes and have confirmed that your Docker, Jellyfin, storage and remote-access setup is supported.

For an established home server, use this order:

confirm the point release and supported upgrade path
→ inventory packages, repositories, mounts and services
→ create and verify independent backups
→ update Ubuntu 24.04 fully
→ upgrade with do-release-upgrade
→ reboot locally
→ verify storage and networking before applications
→ verify Docker and Jellyfin
→ retain the recovery image until the server proves stable

Do not use do-release-upgrade -d on an important server. The -d flag selects a development release path and is not the normal production upgrade method.

---

What Ubuntu 26.04.1 changes

Canonical’s first 26.04 point release rolls the security updates and high-severity bug fixes published since 26.04 into refreshed installation media. Its point-release summary also lists accumulated installer and hardware-support fixes.

For an existing 26.04 server, the point release arrives through normal package updates; it is not a separate reinstall. For a 24.04 LTS server, treat the move to 26.04 as a full operating-system release upgrade and plan a recovery route before starting.

Canonical security notice USN-8629-1, published on 12 August 2026, fixed multiple Linux kernel vulnerabilities affecting Ubuntu 26.04 LTS across x86, networking, Netfilter and other subsystems. The notice requires a reboot after the standard system update and warns that its kernel ABI change may require third-party kernel modules to be rebuilt.

This is supporting context for keeping the upgraded server fully patched. It is not a reason to combine kernel troubleshooting with the release upgrade itself.

Should you upgrade from Ubuntu 24.04 LTS?

Situation	Recommendation
The server is stable and all hardware works	Stay on 24.04 unless 26.04 solves a real problem
You need newer hardware enablement	Test 26.04.1 on equivalent hardware first
Docker and Jellyfin are household-critical	Wait until repositories, backups and rollback are verified
The server is remote-only	Do not upgrade without console or out-of-band recovery access
Root or boot storage is nearly full	Fix capacity before attempting the release upgrade
Storage mounts use fragile device names	Convert and test the mount design before upgrading
Third-party repositories are poorly documented	Resolve or remove them before the upgrade
The host is easy to rebuild and guests/data are independent	A clean installation may be easier to reason about

Ubuntu 24.04 LTS remains supported. A point release is a useful decision point, not a deadline.

What changes between 24.04 and 26.04?

Ubuntu 26.04 LTS moves the server to a newer kernel, toolchain and package baseline. That can improve support for newer CPUs, chipsets, network controllers and storage hardware, but it can also change driver behavior, service defaults and third-party repository compatibility.

For a home server, the highest-risk areas are:

• kernel modules and hardware acceleration
• network-interface names and firewall behavior
• /etc/fstab, USB disks and network mounts
• Docker’s Apt repository and daemon configuration
• Jellyfin packages, FFmpeg and GPU access
• SSH access after firewall or network changes
• Python environments and locally compiled tools
• PPAs and vendor repositories that do not publish Resolute packages

Do not assume the newer kernel will fix a hardware issue until the exact device has been tested.

Step 1: record the current server

Create a dated maintenance record and capture:

cat /etc/os-release
uname -a
hostnamectl
lsb_release -a 2>/dev/null
df -hT
df -ih
lsblk -o NAME,MODEL,SERIAL,SIZE,FSTYPE,UUID,MOUNTPOINTS
findmnt
systemctl --failed
ip -brief address
ip route

Record installed kernels and held packages:

dpkg -l 'linux-image*' | awk '$1 == "ii" {print $2, $3}'
apt-mark showhold

Save the output somewhere other than the server being upgraded.

Step 2: inventory third-party repositories

Release upgrades commonly disable third-party repositories because packages built for the old release may not exist for the new one.

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

For each non-Ubuntu source, record:

Repository	What uses it	26.04 support confirmed?	Recovery plan
Docker	Docker Engine and plugins	Check vendor documentation	Restore the supported Resolute source only after the OS upgrade
Jellyfin	Native Jellyfin packages	Check current package availability	Keep a package or container rollback plan
Tailscale	Remote access	Check current package availability	Preserve local-console access
Other PPA/vendor	Record the package	Confirm individually	Remove, replace or hold deliberately

Do not mechanically change every repository codename from noble to resolute. Confirm vendor support first.

Step 3: inventory Docker before touching Ubuntu

If the host runs Docker:

docker version
docker compose version
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker network ls
docker volume ls
docker system df

For each Compose project, save the resolved configuration and image references:

cd /path/to/compose-project
docker compose config > compose.resolved.before-ubuntu-26-04.yaml
docker compose config --images

Back up:

• Compose files
• .env files and secrets using secure storage
• bind-mounted configuration directories
• named-volume data
• application databases using their supported backup method
• /etc/docker/daemon.json, if present
• the Docker Apt source and signing-key paths

Do not pull new application images during the Ubuntu release upgrade. Keep the application layer unchanged so failures can be attributed to the operating-system change.

Related SmallGrid guides:

• How to Install Docker on Ubuntu Server
• How to Safely Update Docker Engine on Ubuntu
• How to Update Docker Containers Safely
• Docker Compose Explained for Beginners

Step 4: protect Jellyfin

Record the Jellyfin version and installation method.

For a native installation:

dpkg -l | grep -E '^ii\s+jellyfin'
systemctl status jellyfin --no-pager

For Docker:

docker inspect jellyfin --format '{{.Config.Image}}'
docker inspect jellyfin --format '{{json .Mounts}}'
docker inspect jellyfin --format '{{json .HostConfig.Devices}}'

Before the Ubuntu upgrade:

• stop Jellyfin cleanly
• make an offline backup of its data and configuration
• record plugins and external repositories
• record media paths and permissions
• record GPU device mappings and group IDs
• test one known direct-play file and one known transcode, if used
• start the existing version again and confirm the backup did not damage service

Do not combine the Ubuntu upgrade with a Jellyfin 12 migration. Keep Jellyfin on the proven version until Ubuntu, storage, Docker and hardware access are stable.

Related guides:

• Jellyfin on Ubuntu
• Jellyfin Docker Volume Paths Explained
• Jellyfin Folder Permissions on Ubuntu
• Jellyfin Library Not Showing Files

Step 5: verify storage and /etc/fstab

Record the current mounts:

findmnt --verify --verbose
findmnt
lsblk -f
cat /etc/fstab

Confirm that persistent disks use UUIDs or another stable identifier rather than relying on /dev/sdX names.

For USB, merger, network or application-specific mounts, record:

• source device or network path
• filesystem type
• mount options
• dependency ordering
• owner and numeric UID/GID
• services that must wait for the mount
• expected behavior when the device is absent

Fix existing mount warnings before the release upgrade. A successful boot into 26.04 is not useful if Docker or Jellyfin writes into an empty mount-point directory while the media disk is missing.

Step 6: make recoverable backups

At minimum, create:

• a restorable system image or equivalent rebuild plan
• a separate backup of application data and configuration
• a copy of /etc
• Compose definitions and secure secrets
• Jellyfin data/configuration
• current package and repository inventories
• a copy of important SSH keys and access configuration

Verify the backups by restoring representative files or, ideally, restoring the server into an isolated test environment.

Use Backups That Don’t Lie: 3-2-1 for Home Servers for the wider design.

Step 7: confirm console and SSH recovery

Do not perform a release upgrade through SSH unless you also have a working local console, IP KVM or other recovery path.

Record:

ss -lntup
systemctl status ssh --no-pager
sudo sshd -t
sudo ufw status verbose

Confirm you can log in with a second administrator session before beginning. Keep the existing session open while testing the new one.

If Tailscale is the normal route, confirm ordinary LAN or console access independently. Do not make the VPN your only recovery method during its underlying OS upgrade.

Step 8: fully update Ubuntu 24.04

Only begin when Canonical has enabled the supported upgrade path.

sudo apt update
apt list --upgradable 2>/dev/null
sudo apt full-upgrade
sudo apt --simulate autoremove

Review every proposed removal before running a real sudo apt autoremove; it is optional and should not remove anything you still need. Then reboot into the fully updated 24.04 kernel:

sudo reboot

After reconnecting:

cat /etc/os-release
uname -a
systemctl --failed
findmnt --verify --verbose

Resolve failed services, broken packages, missing mounts and repository errors before proceeding.

Step 9: check whether the supported upgrade is offered

Install the release-upgrade tooling if it is not already present:

sudo apt install update-manager-core

Confirm the LTS prompt policy:

grep '^Prompt=' /etc/update-manager/release-upgrades

For an LTS-to-LTS server upgrade, the expected setting is:

Prompt=lts

Check the supported path:

sudo do-release-upgrade --check-dist-upgrade-only

If no supported release is offered, stop. Do not force the production server onto the development channel with -d.

Step 10: perform the release upgrade

Use a local console where possible. Start the supported upgrader:

sudo do-release-upgrade

During the upgrade:

• read package-removal summaries carefully
• note which third-party repositories are disabled
• preserve locally modified configuration only when you understand the consequence
• save a copy or diff when choosing between local and maintainer configuration
• do not interrupt package configuration
• do not power off the server
• keep the recovery console available

Step 11: reboot and verify the operating system first

After the upgrader completes and requests a reboot:

sudo reboot

Then check:

cat /etc/os-release
uname -a
systemctl --failed
journalctl -b -p warning --no-pager
df -hT
df -ih
findmnt --verify --verbose
ip -brief address
ip route

Do not start debugging Jellyfin until networking, DNS, time, storage and the base operating system are healthy.

Step 12: repair and verify repositories

Review disabled and changed sources:

grep -RhsE '^(deb |Types:|URIs:|Suites:|Components:|Signed-By:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
sudo apt update
apt-cache policy

Re-enable a vendor repository only after its documentation explicitly supports Ubuntu 26.04 and the correct signing key and source format are confirmed.

Docker’s official Ubuntu installation documentation lists Ubuntu Resolute 26.04 LTS as supported. Still confirm that Apt offers the expected Engine, CLI, containerd, Buildx and Compose packages before re-enabling the source on the upgraded server.

Step 13: verify Docker without updating applications

systemctl status docker --no-pager
docker version
docker compose version
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker network ls
docker volume ls

For each stack:

cd /path/to/compose-project
docker compose config
docker compose ps
docker compose logs --timestamps --tail=100

Do not run a broad docker compose pull. First prove that the same application images, mounts, networks and secrets still work on the upgraded host.

Step 14: verify Jellyfin and media access

Check the service or container, then test the actual application.

Native installation:

systemctl status jellyfin --no-pager
journalctl -u jellyfin -b --no-pager | tail -200

Docker:

docker compose ps jellyfin
docker compose logs --timestamps --tail=200 jellyfin

Verify:

• expected media mounts are present
• Jellyfin can read the media as its real service/container user
• users, watched status and libraries remain present
• a known direct-play file works
• a known transcode works, if used
• /dev/dri or another GPU device is still available
• plugins and external integrations load
• remote access follows the intended private route

If a library appears empty, stop scans and writes until the underlying mount is confirmed. Use Jellyfin Library Not Showing Files to diagnose in the correct order.

Step 15: complete a controlled observation period

For at least several days, monitor:

systemctl --failed
journalctl -p warning --since today --no-pager
df -hT
free -h
docker stats --no-stream

Also verify:

• scheduled backups complete
• unattended upgrades run normally
• disks remount after another controlled reboot
• Docker containers restart in the intended order
• Jellyfin scans and playback remain stable
• SSH and Tailscale reconnect after reboot
• temperatures and power behavior remain normal

Keep the pre-upgrade recovery image until this observation period passes.

Rollback is a restore, not an uninstall

An Ubuntu release upgrade changes hundreds of packages, repository definitions and configuration files. There is no dependable command that converts an upgraded 26.04 server back into its previous 24.04 state.

A credible rollback is one of:

• restore the complete pre-upgrade system image
• reinstall Ubuntu 24.04 and restore documented configuration and application data
• fail back to a separately prepared host
• restore a tested VM snapshot and any matching external application data

Do not mix post-upgrade application data with an older application or operating-system state unless the application’s restore guidance explicitly supports it.

Reasons to remain on Ubuntu 24.04

Stay on 24.04 LTS when:

• it is stable and fully supported
• 26.04 offers no needed feature or hardware fix
• a required vendor repository does not support Resolute
• Jellyfin or GPU acceleration has not been verified on your hardware
• you lack console access
• backups have not been restored successfully
• the server cannot tolerate an extended maintenance window
• you would be relying on an untested downgrade

Waiting is a valid maintenance decision, not neglect. Continue applying normal 24.04 security updates while preparing.

Final checklist

• Canonical has released Ubuntu 26.04.1.
• The supported LTS upgrade is offered without -d.
• Final release notes and known issues were reviewed.
• Current versions, repositories, packages and mounts were recorded.
• Independent backups and the recovery path were tested.
• Local-console access works.
• Ubuntu 24.04 was fully updated and healthy first.
• Third-party repositories support Ubuntu 26.04.
• Storage and networking work after reboot.
• Docker works with the existing images and data.
• Jellyfin sees its libraries and passes playback tests.
• Backups complete on the upgraded system.
• A second controlled reboot succeeds.
• The recovery image is retained through the observation period.

Use Home Lab Update Routine for ongoing maintenance after the upgrade.

Official references

• Ubuntu 26.04 release notes
• Ubuntu 26.04.1 release announcement
• Ubuntu 26.04.1 point-release changes
• Ubuntu 26.04 release schedule
• Ubuntu Server release-upgrade procedure
• Docker Engine installation on Ubuntu
• Jellyfin Linux installation