Ask
19
@distro_dana ·

Package lists 404 on a server with automatic updates turned on — and the hostname resolves fine

A server with unattended updates enabled started failing to refresh its package lists. The errors are not-found responses from the mirror, not connection failures, and the mirror hostname resolves and responds to a ping perfectly well.

So the server is reachable and it is answering — it just does not have what my machine is asking for.

This started within the last couple of weeks with no action on my part. What causes a mirror to serve a 404 for a distribution it was serving fine a month ago?

4 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @sysadmin_selin · 3w ago

    Worth pointing out the specific trap in your setup: unattended updates on a short-support release is a combination that fails quietly and then dangerously.

    While the release is supported, automatic updates work and you stop thinking about the machine. When it lapses, the updates start failing — and unattended upgrade tooling generally reports failures somewhere nobody reads. So the machine transitions from "patched automatically" to "receiving nothing" with no visible change, and it can sit like that for a long time.

    Two things worth doing on every machine you run this way:

    • Alert on update failures, not just on update availability. A server that has not successfully refreshed in a week should page somebody.
    • Prefer long-term support releases for anything unattended. The whole point of automating updates is not thinking about the machine, and a nine month support window is incompatible with that.
    24
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @inventory_ivo · 3w ago

    If you go the repoint-to-archive route, do it knowingly and put an expiry on it.

    What that configuration means is: this machine will never receive another security update. That is acceptable for a few days while you plan a rebuild, and it is not acceptable as a steady state for anything reachable from a network you do not control.

    Write the date in the repository file as a comment. It is the cheapest possible reminder and it has saved me from finding three-year-old "temporary" pins more than once.

    19
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @distro_dana · 3w ago

    A 404 rather than a connection error is the whole diagnosis: the mirror is fine, and the directory for your release is no longer on it.

    That happens when a release reaches end of life. Interim releases have short support windows — often around nine months — and when one lapses, its files are removed from the general mirror network and moved to an archive host. The mirror keeps serving every supported release perfectly while returning not-found for yours.

    So nothing broke. Your release retired on a published date and the mirrors implemented that.

    The immediate fix is to repoint your sources at the archive host that holds retired releases, which restores your ability to install packages from the frozen final state. The real fix is to upgrade to a supported release, because the archive receives no security updates and never will.

    28
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @certs_cem · 3w ago

    Small diagnostic point that generalises well: when a package manager fails, read whether the error is DNS, connection, TLS, or HTTP status — those are four different problems with four different owners.

    A 404 is the server telling you your request was understood and there is nothing there. That immediately rules out your network, your resolver and your certificates, which is most of what people check first.

    12
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report