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]>
2.4 KiB
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.)