On a Debian or Ubuntu server, `apt install curl` fails with "Unable to locate package curl", and on a different, rarely-touched box an install fails with a 404 while downloading the .deb. What does `apt update` actually do, and why do both failures go away once you run it?
answer
- metadata, not software
- lists live under /var/lib/apt
- unknown name versus missing file
- the pool keeps only current versions
- update and install in one run
basics
~20 sapt update refreshes the package index from every configured repository and installs nothing. With no index apt cannot resolve the package name at all; with a stale index it asks the mirror for a .deb the archive has already replaced, so the download 404s.
solid answer
~40 s`apt update` contacts every repository configured in `/etc/apt/sources.list` and `/etc/apt/sources.list.d/`, downloads their signed release and `Packages` indexes, and caches them under `/var/lib/apt/lists/`. It never installs or upgrades anything — it only refreshes apt's picture of what exists and at which version. A minimal image or a cleaned apt cache has no index at all, so `apt install curl` prints `Unable to locate package curl`; that means *this box* knows of no such package, not that Debian lacks it. On a machine whose index is weeks old, the version it recorded may already have been superseded on the mirror, and Debian and Ubuntu pools keep only current versions, so fetching the recorded filename returns 404. That is why automation always runs the update and the install in the same invocation.
go deeper
Be able to say plainly that apt update refreshes the package lists and installs nothing, and that install or upgrade is what changes the system. Knowing to run it first on a fresh machine is the expected reflex.
Explain where the index is cached, what a Packages stanza contains, and why a stale Filename entry produces a 404 rather than an older version being installed. Distinguish "no index" from "outdated index" by the error text.
Show that you treat index age as a diagnostic signal during an incident, and that you pair update with install in one invocation in provisioning so a cached or replayed step cannot install from a stale picture. Recognise clock skew and disabled components as separate causes.
Own the fleet policy: which suites are enabled, how index freshness is guaranteed on machines that are rebuilt versus long-lived, and whether reproducibility needs a pinned snapshot mirror rather than a live archive that drops superseded versions underneath you.
## Two commands that sound alike On Debian and Ubuntu, `apt update` and `apt upgrade` do unrelated jobs. `update` refreshes metadata. `upgrade` changes installed software. Nothing on disk changes as a result of `apt update` except apt's own cached index — which is exactly why running it is cheap and why leaving it out breaks everything downstream. ## What the index actually is Each entry in `/etc/apt/sources.list`, or in a `.list` / deb822 `.sources` file under `/etc/apt/sources.list.d/`, names an archive URI, a suite (`bookworm`, `noble-updates`, …) and one or more components (`main`, `universe`, …). For each of those, `apt update` fetches the signed `InRelease` file and the compressed `Packages` index it points at, then stores the result under `/var/lib/apt/lists/`. A `Packages` index is a flat list of stanzas, one per available package version: ``` Package: curl Version: 8.5.0-2ubuntu10.6 Depends: libc6 (>= 2.38), libcurl4t64 (= 8.5.0-2ubuntu10.6) Filename: pool/main/c/curl/curl_8.5.0-2ubuntu10.6_amd64.deb ``` Everything apt decides — `apt search`, `apt show`, which version is the candidate, what the dependencies are, and above all the `Filename:` it will download — is answered out of that cached file. apt does not ask the mirror "what do you have?" at install time; it consults the copy it took the last time you ran `update`. ## Failure one: there is no index A freshly built minimal image, a debootstrapped root, or a machine where `/var/lib/apt/lists` was emptied has no stanzas to search. `apt install curl` then reports: ``` E: Unable to locate package curl ``` That message is routinely misread as "curl is not in Debian". It means only that no *currently known* index offers a package with that name. The same message appears for a genuinely different reason: the package lives in a component you never enabled — many Ubuntu packages sit in `universe`, and `contrib`/`non-free` are separate on Debian. If `apt update` alone does not fix it, the next question is which components are configured, not whether the package exists upstream. ## Failure two: the index is stale Debian and Ubuntu archives are not version museums. When `curl 8.5.0-2ubuntu10.6` supersedes `…10.5` in `noble-updates`, the older `.deb` is dropped from the pool. An index cached before that point still carries the old `Filename:`, so apt requests a path that no longer exists and you get: ``` E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/c/curl/curl_8.5.0-2ubuntu10.5_amd64.deb 404 Not Found ``` The fix is `apt update`, not `--fix-missing` and not switching mirrors. This is the single most common apt failure on long-lived boxes and inside build automation, and it is why the idiom is one shell invocation: ``` apt-get update && apt-get install -y curl ``` Splitting the two across steps that can be cached or replayed independently reintroduces exactly the staleness the pair exists to avoid. ## When `apt update` itself fails * **Clock skew.** If the machine's clock is behind, apt rejects the release metadata with `E: Release file for … is not valid yet`, and the repository is simply not updated. Fix the clock (NTP/chrony); do not reach for options that disable the check. * **A suite that no longer exists.** After a distribution release upgrade, or when a suite reaches end of life and moves to an archive host, the index URL itself 404s and apt reports that the repository has no Release file. * **A partial failure.** apt can finish with warnings when one of several sources failed, so a script that only checks the exit status can proceed on a half-refreshed index. Read the output, or fail the run explicitly when any source errored. ## What to run next After an update, `apt list --upgradable` shows what changed without touching anything, and `apt-get -s upgrade` simulates the transaction. The modification times under `/var/lib/apt/lists/` tell you how old the picture was before you refreshed it — a useful thing to note during an incident, because a box whose index is six months old has probably not been patched in six months either.
- Does `apt update` ever change which packages are installed on the machine?No. It only rewrites the cached indexes under `/var/lib/apt/lists/` and reports how many packages are upgradable. On Ubuntu, `apt-daily.timer` runs it periodically in the background, which is why the counts in the MOTD move without anyone touching the box; the separate `apt-daily-upgrade.timer` and unattended-upgrades are what actually install things.
- An `apt update` fails with "Release file for … is not valid yet". What is going on?The machine's clock is behind the archive's metadata timestamps, so apt treats the release file as not yet valid and refuses to use that repository. It is a clock problem, not a repository problem — check `timedatectl`, get NTP or chrony syncing, and re-run. Suppressing the validity check hides a skew that will also break TLS and log correlation.
- How do you see what a fresh `apt update` would change without installing anything?`apt list --upgradable` lists each package with its installed and candidate versions. `apt-get -s upgrade` (or `-s full-upgrade`) simulates the whole transaction and prints the plan, including anything that would be held back, without touching dpkg. Both read the cached index only, so run them after the update.
saying these in an interview costs you the question
- Thinks apt update also upgrades installed packages
- Reads "Unable to locate package" as the package not existing in Debian
- Assumes mirrors keep every historical .deb, so old indexes stay valid
- Answers a 404 on a .deb with --fix-missing instead of updating
- Believes apt queries the mirror live during install