Phase 4 · Free

4.5 A Troubleshooting Method You Can Repeat

Guessing works sometimes. A method works every time, and it is what separates a tech people trust from one they tolerate. CompTIA teaches a six-step model. It is worth memorizing because it is simply what good troubleshooters already do.

20 minPhase 4: Break It, Fix ItFree

Phase 4. Lesson 5 of 5. About 20 minutes.

Plain entry

Guessing works sometimes. A method works every time, and it is what separates a tech people trust from one they tolerate. CompTIA teaches a six-step model. It is worth memorizing because it is simply what good troubleshooters already do.

Terms

  • Theory of probable cause: your best guess at why, which you then test.
  • Change one thing at a time: if you change three things and it works, you do not know which fixed it.

Depth: the six steps (CompTIA A+ model)

  1. Identify the problem. What exactly is wrong? When did it start? What changed? (/var/log/apt/history.log, last, journalctl --since.) Back up before you touch anything.
  2. Establish a theory of probable cause. Start with the obvious: cable, typo, full disk, recent update.
  3. Test the theory. If it is wrong, form a new one or escalate.
  4. Plan the fix and do it. Know how to undo it.
  5. Verify full system functionality. Did it actually fix it, and did you break something else? Add prevention.
  6. Document findings, actions, and outcome.

Worked example: “sudo stopped working”

you is not in the sudoers file.
  1. Identify: groups shows you without sudo. Someone ran usermod -G without -a.
  2. Theory: user was removed from the sudoA Linux command that runs a single command with administrator (root) privileges, after checking that your account is allowed to do so. Read more → group.
  3. Test: getent group sudo does not list you. Confirmed.
  4. Fix: boot recovery mode (lesson 4.3), root shellThe program that reads the commands you type, runs them, and shows the results; Bash is the default on most Linux systems. Read more →, mount -o remount,rw /, then usermod -aG sudo you. Reboot.
  5. Verify: sudo -v succeeds; groups shows sudo.
  6. Document it in break-fix-log.md, including the lesson: usermod -G replaces groups, -aG adds.

Use the same template for every break in the lab.

Why it works this way

The method forces one change at a time. If you change three things and it starts working, you do not know which one fixed it, and you may have broken something else. Writing a hypothesis before testing also keeps you honest: a test only means something if you said beforehand what result would prove you wrong.

Self-check

  1. Name the six steps in order.
  2. Why back up before step 4?
  3. What is the difference between usermod -G and usermod -aG?

Answers: (1) Identify, theory, test, plan and implement, verify, document. (2) So you can undo a bad fix. (3) -G replaces the group list, -aG appends.

Sources