# Linux Troubleshooting

## The RootNode troubleshooting framework

Every module in ROOT 02 has been building toward this: a repeatable, disciplined process for
diagnosing ANY Linux-level failure, not just the specific ones you've already seen.

```
OBSERVE
  ↓
GATHER EVIDENCE
  ↓
FORM HYPOTHESIS
  ↓
TEST
  ↓
REPAIR
  ↓
VALIDATE
  ↓
PREVENT
```

## Each step, and why skipping it costs you later

- **Observe** — what's the actual, specific symptom? Not "it's broken" — the exact error, the
  exact command that failed.
- **Gather evidence** — logs, process state, listening ports, config content — the raw facts,
  collected BEFORE guessing at a cause.
- **Form hypothesis** — based on the evidence (not a guess made before looking), what's the most
  likely cause?
- **Test** — check whether your hypothesis is actually true, ideally without yet making changes
  that could mask the real problem.
- **Repair** — make the minimal change that addresses the CONFIRMED cause, not a broad "try
  everything" fix.
- **Validate** — confirm the original symptom is actually gone, with real evidence, not
  assumption.
- **Prevent recurrence** — what would stop this from happening again? Skipping this step is how
  teams end up fixing the exact same incident repeatedly.

## Why "skip straight to fixing" costs you

Jumping straight from OBSERVE to REPAIR (skipping evidence and hypothesis) means you're guessing
— sometimes you'll get lucky, but you won't have LEARNED anything transferable, and you risk
"fixing" a symptom while leaving the actual cause untouched, guaranteeing a repeat. Every command
from Modules 1, 2, and 4 IS the "gather evidence" step, made concrete.

## Instructor Notes

**Lesson goal:** Consolidate every command this course taught into ONE disciplined process,
directly matching the identical framework `root-10-m03-troubleshooting-framework` teaches at the
Kubernetes level — introduced here first, at the Linux level, so it already feels familiar by
then.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** treating this as a rigid checklist to recite rather than
an actual habit — the value only shows up when it's applied under a real, unfamiliar failure
(this module's Lab).

**Discussion question:** "Describe a time you fixed something without understanding WHY it
broke. Did it come back?" (Real personal examples land this lesson better than abstract
description.)