jschoubben
aafeb5c9df
012 named its own closing condition — a scenario with four images coming up — and the scenario now stocks seven and has raised cleanly many times at the memory the wrong diagnosis had raised. 001 is answered by the host reading the package database back after installing. 002 was NOT answered and was present here too, so it is a fix rather than a note: a stale index is now named instead of reported as a failed install.
67 lines
3.0 KiB
Markdown
67 lines
3.0 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-08-22
|
|
located-in: [mesh-host]
|
|
fixed-by: mesh-host — a stale package index is named rather than reported as a failed install
|
|
amended-design:
|
|
---
|
|
|
|
# 002 — A declared package can fail purely because the node's index is stale
|
|
|
|
## Symptom
|
|
|
|
A package install ran without first synchronising the node's package index. It therefore
|
|
requested a version the mirrors had already superseded, and received a 404 from every one of
|
|
them.
|
|
|
|
The package exists. The declaration is correct. The node's view of what exists is old.
|
|
|
|
## Why this matters
|
|
|
|
The failure has nothing to do with the module, the manifest or the mirror. It is a property of
|
|
when the node last synchronised, which nothing in the mesh manages or reports. Two nodes given
|
|
the same declaration on the same day can produce different outcomes, and neither says why.
|
|
|
|
Combined with [issue 001](../001-failed-package-install-reports-success/00-report.md), the
|
|
failure is not only environmental but silent: today the node ends up without the package and
|
|
the job is green.
|
|
|
|
## Evidence
|
|
|
|
- Observed 2026-08-22, same declaration as issue 001.
|
|
- Documented as a recurring shape in the knowledge base under package installation failures,
|
|
where it is recorded as appearing in two disguises.
|
|
|
|
## Open questions
|
|
|
|
- Should the mesh own package-index freshness as a node property, the way it owns module
|
|
versions — or is an index sync part of the install step?
|
|
- A partial sync is unsafe on the platform in use; a full upgrade is the only sanctioned fix.
|
|
Does that make index freshness a scheduled node concern rather than a pipeline one?
|
|
|
|
## How it is answered
|
|
|
|
*2026-08-31. It was present in the replacement too, which is why this is a fix rather than a note
|
|
saying the new mesh does not have it.*
|
|
|
|
**The failure is named.** A machine asking for a version the mirrors have replaced now says so, and
|
|
says what fixes it — a full upgrade of the machine.
|
|
|
|
**It is deliberately not fixed by synchronising.** `pacman -Sy <pkg>` installs a package built
|
|
against libraries the machine does not have: a partial upgrade, unsupported on this distribution,
|
|
which surfaces much later as something apparently unrelated. That is a decision about the whole
|
|
machine, and a host that made it silently while applying one resource would be taking a large
|
|
decision in a small place.
|
|
|
|
So the host distinguishes the two cases and leaves the decision where it belongs. **A declaration
|
|
that is wrong and a machine that is out of date fail identically otherwise, and they are fixed in
|
|
completely different places.**
|
|
|
|
**And the package manager's own words were being thrown away** — the output was read into `_`, so
|
|
the 404s that name the cause never reached anybody. Whatever it said is now part of the failure,
|
|
which is the rule everywhere else here and was not being followed in the one place where the reason
|
|
exists only in the output.
|
|
|
|
*Checked by a stale-index failure being named as one, an ordinary missing package not being, a
|
|
single mirror timing out not being, and a successful install still saying nothing.*
|