Updating & Upgrading Ubuntu

A server you never update is a server slowly filling up with known security holes. Ubuntu ships fixes for bugs and vulnerabilities every single day, and your job as a server administrator is to pull those fixes in regularly and safely. This page explains the two very different kinds of updating: routine package updates (small, frequent, low risk) and full release upgrades (big, occasional, higher risk). Getting the difference clear in your head is the most important takeaway here.

Ubuntu uses apt (Advanced Package Tool, the program that installs, updates, and removes software) for everything. Almost all of this page is just apt plus a couple of specialist tools.

Two kinds of “upgrade”

People say “upgrade my server” to mean two completely different things. Mixing them up causes broken servers.

Operation	What it does	How often	Risk
apt upgrade	Updates installed packages within the same Ubuntu version (e.g. patches on 24.04)	Weekly, or daily for security	Low
apt full-upgrade	Same, but allowed to remove packages when needed to complete the update	Weekly	Low–medium
do-release-upgrade	Moves to a new Ubuntu version (e.g. 22.04 → 24.04)	Every couple of years	High

The number after Ubuntu (like “2204” meaning April 2022) is the release. Staying patched within your release is routine. Jumping to a new release is a planned event you should schedule, test, and back up before.

Step 1: Refresh the package list

apt update does not install anything. It only downloads the latest list of which package versions are available. Always run it first, otherwise apt is working from stale information.

sudo apt update

Output:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 126 kB in 1s (110 kB/s)
Reading package lists... Done
Building dependency tree... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.

To see exactly what would change before committing:

apt list --upgradable

Step 2: Apply the updates

apt upgrade installs the newer versions of everything you already have. The -y flag answers “yes” automatically, which is handy in scripts but use it carefully when watching the output.

sudo apt upgrade -y

Output:

Reading package lists... Done
The following packages will be upgraded:
  libssl3 openssl curl libcurl4 ...
12 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,420 kB of archives.
...
Setting up libssl3:amd64 (3.0.13-0ubuntu3.4) ...

When to use full-upgrade instead: plain apt upgrade will never remove an installed package, so if a new version requires dropping an old one, it skips that update and leaves it “held back”. apt full-upgrade is allowed to remove packages to complete everything. On a normal server this is safe and recommended.

sudo apt full-upgrade -y

Clean up afterwards

Old dependencies and cached download files pile up. Reclaim disk space:

sudo apt autoremove --purge -y
sudo apt clean

Security updates specifically

The most important updates are security patches. On Ubuntu, the unattended-upgrades package can install security updates automatically while leaving everything else for you to do manually. This is the recommended default for production servers.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Check the config in /etc/apt/apt.conf.d/50unattended-upgrades. By default it enables only the security pocket, which is what you want:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Automating security updates is good practice. Automating all updates (including feature changes) on a production box is risky — a routine update can restart a service at a bad moment. Keep automation scoped to security only.

Rebooting after a kernel update

Most updates apply instantly. But when the kernel (the core of the operating system that talks to the hardware) is updated, the running system is still using the old kernel until you reboot. Ubuntu signals this by creating a flag file: /var/run/reboot-required.

Check for it before walking away from a maintenance window:

[ -f /var/run/reboot-required ] && echo "Reboot needed" || echo "No reboot needed"

Output:

Reboot needed

You can also see which packages triggered the requirement:

cat /var/run/reboot-required.pkgs

When it’s safe, reboot:

sudo reboot

When NOT to reboot immediately: if the box is serving live traffic, wait for a maintenance window. The patched kernel is downloaded and ready; the reboot just activates it. (Ubuntu Pro offers “Livepatch” to apply some kernel fixes without rebooting — useful on servers that must stay up.)

Major release upgrades

To move to a brand-new Ubuntu version, never edit the package sources by hand. Use the official tool, do-release-upgrade, which handles the migration in the correct order.

First make sure you’re fully patched on your current release, then run:

sudo apt update && sudo apt full-upgrade -y
sudo do-release-upgrade

Output:

Checking for a new Ubuntu release
Get:1 Upgrade tool signature [1,554 B]
...
Reading cache
You have to download a total of 1,204 M.
Continue [yN]

Notes that save you pain:

• Run it inside tmux or screen (terminal multiplexers that keep your session alive). If your SSH connection drops mid-upgrade over a plain shell, the upgrade can break.
• LTS servers only see a new LTS by default. To jump before the .1 point release, use sudo do-release-upgrade -d.
• Always back up (or snapshot the VM) first. Test on a staging server before touching production.

Best Practices

• Always run sudo apt update before any upgrade so apt has fresh data.
• Use apt full-upgrade on servers so nothing gets silently held back.
• Enable unattended-upgrades for security patches only; do feature updates by hand.
• Check /var/run/reboot-required after upgrades and schedule reboots for kernel changes.
• Run apt autoremove periodically to stop /boot filling with old kernels.
• For release upgrades, back up first, use tmux, and test on staging before production.
• Subscribe to Ubuntu security notices so you know when a critical fix lands.

Related Topics

• APT package management
• Installing software
• Systemd services
• The boot process
• Viewing logs with journalctl