Ubuntu apt update vs apt upgrade: Refreshing the package index is not an upgrade

You run sudo apt update, but the installed program stays at the same version. That is expected: update refreshes information about available packages; upgrade changes installed packages. To tell where an update stopped, separate the repository, the local package index, and the packages on the machine.

What does apt update refresh?

The diagram separates the index refresh from package installation. Its v1 and v2 labels are illustrative versions, not measurements from a particular Ubuntu release.

Ubuntu obtains package names, versions, and dependency information from configured repositories. apt update refreshes that local index, as Ubuntu's package-management guide explains:

sudo apt update

You can then inspect available upgrades:

apt list --upgradable

At this point, the installed binaries have not changed merely because you refreshed the index. If apt update reports a repository, network, DNS, or signature error, inspect that failure before proceeding. A stale or partially refreshed index may not describe the package versions you intended to install.

sudo apt update

# Inspect configured repository locations
ls -l /etc/apt/sources.list /etc/apt/sources.list.d/

Repository configuration varies by Ubuntu version; inspect the relevant files in sources.list.d/ rather than assuming all entries live in one file.

What changes when apt upgrade runs?

After refreshing the index, apt upgrade calculates eligible upgrades for installed packages, asks for confirmation, and downloads and installs them:

sudo apt upgrade

Review the proposed packages and disk-space change before confirming, especially on a server. Adding -y removes that decision point. For a single package, name it explicitly:

sudo apt install curl

apt install also uses the local index. Refreshing it first is sensible on a new machine or one that has not been updated recently.

How can you check the steps before changing packages?

The following sequence checks whether curl is installed, refreshes package information, inspects the upgrade candidate, and installs it only if that change is needed:

# Current installation and version
dpkg -s curl 2>/dev/null | grep -E '^(Status|Version):'

# Refresh repository metadata
sudo apt update

# Inspect the candidate
apt list --upgradable 2>/dev/null | grep '^curl/' || true

# Run only when the package change is intended
sudo apt install curl

If dpkg -s finds nothing, the package may not be installed. If apt list --upgradable finds nothing, do not immediately conclude that it is current: first check whether the index refresh succeeded, the package is installed, and the repository supports your Ubuntu release.

For automation, verify that the repository refresh succeeds, the required package is available, and the expected executable and version exist after installation. A service package may also need a restart or a reboot.

What should change planning include on a server?

Package upgrades can affect libraries, kernels, and running services. Review the candidate list, choose a maintenance window if necessary, keep a recoverable backup, and test the change in a comparable environment. Record which servers succeeded so that one failed host does not remain on a different version unnoticed.

apt autoremove can delete dependencies APT considers unused. Preview the candidates before removing them, especially when a service might still expect a tool that was installed indirectly:

sudo apt autoremove --dry-run

Key takeaways

apt update refreshes the local index from repositories; apt upgrade updates eligible installed packages using that information. Check for index errors and review candidates before installing. On a production server, include service restarts, reboot needs, and recovery in the change plan.