Ubuntu 22.04 to 24.04 In-Place with do-release-upgrade

An in-place LTS upgrade works. It works reliably. What breaks is the box you ran it on without a snapshot, without disabling your third-party repositories, and without deciding in advance what you would do if it came up wrong.

The upgrade path from Ubuntu 22.04 LTS to 24.04 LTS opened with the 24.04.1 point release in August 2024, which is when do-release-upgrade started offering the jump to Noble Numbat on machines set to track LTS releases. The tool itself is good. The failure mode is almost never the upgrader; it is the operator treating a production server like a laptop. This is how to run it defensively on a box you actually care about.

Snapshot before you touch anything

The single decision that separates a calm upgrade from a bad afternoon is whether you can get back to where you started in one command. A distribution upgrade rewrites your kernel, your init-managed services, your apt sources and hundreds of packages. If it goes wrong halfway through, there is no clean apt route back. You want a whole-system restore point taken while the machine is still 22.04.

On a cloud instance, take a provider-level image or volume snapshot from the console or CLI — that is the fastest rollback you will ever have. On bare metal or a VM you control, an LVM snapshot of the root logical volume is the practical equivalent, provided you have free space in the volume group. Take it, and write down how to restore it before you need to.

# Confirm you are actually on 22.04 first
lsb_release -a

# Fully update the running system before upgrading
sudo apt update
sudo apt full-upgrade -y
sudo apt --purge autoremove -y

# If a reboot was requested, take it now, then continue
[ -f /run/reboot-required ] && echo "REBOOT NEEDED" && sudo reboot

# LVM snapshot of the root LV (adjust VG/LV names to your system)
# Check yours with: sudo lvs
sudo lvcreate --size 10G --snapshot --name root_pre2404 /dev/ubuntu-vg/ubuntu-lv

# Verify the snapshot exists and is active
sudo lvs -o lv_name,lv_size,origin,snap_percent

Size the snapshot for the churn you expect during the upgrade, not the size of the filesystem — 10–20 GB is usually ample for a server. If the snapshot fills to 100% it is dropped and becomes useless, so watch snap_percent if the box is busy. And test that you know the restore procedure for your platform. A snapshot you have never restored is a hope, not a rollback.

Third-party repositories are the usual saboteur

do-release-upgrade disables third-party sources automatically and comments out your PPAs before it starts, precisely because a repository built for 22.04 (jammy) has no 24.04 (noble) packages and will either block the pre-flight check or drag in mismatched versions. The problem is not that it disables them — it is that it re-enables nothing, and you are left afterwards with a half-configured system if you forget which ones you had. Inventory them yourself, on purpose, so re-adding is deliberate.

# List every third-party apt source so you have a record to restore from
grep -rn --include='*.list' --include='*.sources' 
  -E '^[^#]' /etc/apt/sources.list.d/ 2>/dev/null

# Note down any manually held packages — held packages can stall the upgrade
apt-mark showhold

# Optionally release holds you no longer need
# sudo apt-mark unhold <package>

Save that output somewhere off the box. After the upgrade you will re-add each PPA against noble, not jammy, and only the ones you still need. Ubuntu 24.04 also moves the base apt configuration to the deb822 format in /etc/apt/sources.list.d/ubuntu.sources; your own .list files keep working, but this is the moment to migrate them to .sources if you have been meaning to. Treat repository hygiene as part of the upgrade, not an afterthought — the same configuration discipline you enforce in CI applies to the machines under the pipeline.

Running the upgrade over SSH without hanging yourself

On a remote server the risk is losing your SSH session mid-upgrade and leaving the machine in a partially-configured state. do-release-upgrade guards against this: it starts the process inside a detachable screen session and opens a second SSH daemon on port 1022 as a fallback route in, so a dropped connection does not kill the upgrade. Let it. Do not run it inside your own fragile terminal and walk away.

# On a server, this is the correct invocation. It self-manages screen.
sudo do-release-upgrade

# If the release is not yet offered on your machine and you have
# genuinely decided to go early, -d targets the development/proposed path.
# Do NOT use -d on a server you care about unless you mean it.
# sudo do-release-upgrade -d

Check /etc/update-manager/release-upgrades reads Prompt=lts if you expected the offer and did not get it — with Prompt=normal it will only move between interim releases as they appear. During the run you will hit the interactive configuration-file prompts whenever a package ships a new default that differs from a file you edited. Read each one. The safe default is keeping your version, but for anything you never touched, taking the maintainer’s version keeps you aligned with the new release. Never blind-enter through these on sshd_config, sudoers, or your firewall rules.

After the reboot: verify, don’t assume

Ubuntu 24.04 ships the 6.8 kernel, Python 3.12 as the default, and Netplan 1.0, with NetworkManager now using Netplan as its storage backend. Most servers come through cleanly, but the two things that actually bite are networking and services that depended on the old Python. Verify both before you declare victory.

# Confirm the release and kernel
lsb_release -a
uname -r          # expect a 6.8-series kernel

# Any service that failed to start after the upgrade
systemctl --failed

# Netplan config is valid and matches what you expect
sudo netplan status
sudo netplan generate

# Re-add your third-party PPAs — against noble now, not jammy
# sudo add-apt-repository ppa:your/ppa
sudo apt update && sudo apt full-upgrade -y

Walk your actual application: hit the endpoints, tail the logs, confirm the database is reachable, check that anything pinned to a system Python still imports. An upgrade is a change with a real failure rate, and it belongs in the same operational picture as everything else you ship — the kind of thing your change-failure and recovery metrics should already be watching. If the box comes up wrong and you cannot fix it inside your maintenance window, this is where the snapshot earns its keep: restore, reboot onto 22.04, and go home. Then work out what broke on a machine that isn’t in production.

The in-place upgrade is not the gamble. Running it with no snapshot, no repository inventory, and no rehearsed way back — that is the gamble. Do the prep and the upgrade is boring, which is exactly what you want it to be.