Diagnosing a failure: what each output proves
Read what each output actually proves, narrow an unknown failure down to one component, and fix it without destroying the evidence that explained it.
A diagnostic output is not a verdict on the machine: it is one component’s answer to one narrow question, and most failures survive investigation because that answer was accepted as an answer to a wider one. This course takes the seven lab incidents in this curriculum and re-reads them for the reasoning rather than the root cause: what each output proves, how a hypothesis is killed, and why capture comes before repair.
What you will be able to do
- State what an output proves and what it leaves open, before choosing the next command
- Reject a probe whose success and failure are indistinguishable, such as `gzip -t` on an empty archive
- Narrow an unknown failure by stating what the hypothesis forbids, then going to look for it
- Capture the evidence a restart would delete, then apply a fix no wider than the cause
Outline
- 01
What the machine has already told you
Outputs that answer a narrower question than the one you were asking.
- 02
Dating the fault, then narrowing the region
A symptom's timestamp is not the fault's, and a hypothesis you cannot refute is no use to you.
- 03
Acting without erasing the evidence
The first move usually deletes the answer. This one does not.
Technical content last reviewed on 3 August 2026