ced4568andClaude Sonnet 5
e007bcf000
Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37 activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per its "critical module" designation, with no lab by design — conceptual mastery via knowledge check and guided exercise, matching root-05-m00's own precedent. Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects the platform's own real nginx without touching it — a genuinely safe, real service-inspection target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/ verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection (ip/ss/getent/curl, each framed as answering one specific diagnostic question), linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed), and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested end-to-end via the real scenario-validation API, including negative tests confirming they fail when unsolved. Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# 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.)
|