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]>
42 lines
1.5 KiB
Markdown
42 lines
1.5 KiB
Markdown
# Knowledge Check: Linux Troubleshooting
|
|
|
|
---
|
|
|
|
**1. What's the difference between OBSERVE and GATHER EVIDENCE?**
|
|
|
|
*Answer:* OBSERVE names the specific symptom (what actually failed, precisely). GATHER EVIDENCE
|
|
collects the raw facts (logs, config, process/port state) needed to understand WHY, before
|
|
guessing at a cause.
|
|
|
|
---
|
|
|
|
**2. Why does FORM HYPOTHESIS come before TEST, rather than jumping straight to REPAIR?**
|
|
|
|
*Answer:* A hypothesis is a specific, falsifiable guess at the cause based on evidence already
|
|
gathered — testing it BEFORE repairing confirms you're about to fix the right thing, rather than
|
|
making a change that might not address the actual cause at all.
|
|
|
|
---
|
|
|
|
**3. A fix works, but the same failure happens again a week later. Which framework step was
|
|
most likely skipped?**
|
|
|
|
*Answer:* PREVENT RECURRENCE — the immediate symptom was resolved, but whatever allowed the
|
|
underlying cause to occur in the first place was never addressed.
|
|
|
|
---
|
|
|
|
**4. Why is "repair the minimal confirmed cause" better than "try several things until it
|
|
works"?**
|
|
|
|
*Answer:* A minimal, confirmed repair means you actually know what fixed it and can prevent
|
|
recurrence deliberately. Trying multiple things at once means even success leaves you unable to
|
|
say WHICH change mattered — and unable to reliably prevent the same failure next time.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 3 is a good real-world check-in — ask if anyone has a personal
|
|
example of a fix that didn't actually stick.
|
|
|
|
**Approximate timing:** 5 minutes.
|