A persistent, evidence-backed, long-term learning system and engineering portfolio for Linux, Unix, systems administration, troubleshooting, and Arch Linux.
- Linux / Arch Engineering Learning Repository
- Table of contents
- Overview
- Author & Learner Profile
- Core Philosophy
- Lab Architecture & Safety Gate
- Curriculum Roadmap (Phases 0–17)
- Primary Reference Sources
- Sample Evidence & Terminal Practice
- Repository Structure
- How to Use / AI Instructor Workflow
- Current Status & Active Milestone
- Feedback & Discussions
- License
This repository is a structured, long-term learning system for building real systems-engineering competence — not a collection of notes copied from tutorials.
It functions as part curriculum, part lab notebook, and part engineering portfolio. Every phase produces persistent artifacts — logs, command outputs, diagnostic evidence, architectural decisions, and error post-mortems — proving that skills are built through hands-on verification.
- Engineer: Muaz Islam (@muazislambabar)
- Primary Focus: Full-Stack Web Development (React, Node.js, Express, Databases, Cloud/APIs).
- Linux Track: Secondary, serious systems-engineering track dedicated to building deep Linux and Arch Linux proficiency (from command-line mastery and shell scripting to kernel/boot recovery, Docker infrastructure, systemd administration, and independent Arch Linux maintenance).
- Time Commitment: ~20 hours/week dedicated to Linux practice and labs.
- Competence over memorization. The goal is the ability to reason about a broken system from first principles, not reciting command flags from memory.
- "Don't administer by coincidence." (Adapted from The Pragmatic Programmer's "Don't Program by Coincidence" rule). If a command or fix works without an understanding of why, it is not complete.
- No topic is "complete" from reading alone. Every milestone requires demonstrated terminal evidence, root-cause analysis, and verification.
- Socratic instruction by default. The instructor (human mentor or AI) guides through targeted inquiry rather than handing over direct answers.
CONCEPT → EXPLANATION → GUIDED PRACTICE → INDEPENDENT EXERCISE → LAB
→ FAILURE SCENARIO → TROUBLESHOOTING → RECOVERY → ASSESSMENT → MASTERY
Tracks how much assistance was required to solve a problem, logged over time to ensure decreasing hint dependence and increasing engineering autonomy.
| Level | Name | Definition |
|---|---|---|
| H0 | Independent | Solved with zero assistance; learner proceeds independently. |
| H1 | Clarifying Question | Socratic question prompting the learner to re-read output or clarify objectives. |
| H2 | Conceptual Hint | High-level conceptual explanation without naming commands. |
| H3 | Subsystem Hint | Identifies the involved subsystem (e.g., storage, networking, permissions, systemd). |
| H4 | Diagnostic Direction | Recommends an investigation strategy or inspection path (e.g., check dmesg, journalctl, man). |
| H5 | Tool Category | Points to the command or utility family (e.g., ip, ss, systemctl, chmod). |
| H6 | Procedural Guidance | Provides sequential steps or syntax structure without giving the full answer. |
| H7 | Explicit Solution | Direct command or solution provided (triggers follow-up remediation). |
| Level | Meaning | Evidence Requirement |
|---|---|---|
| L0 | Unfamiliar | No prior knowledge or unverified claim. |
| L1 | Can recognize | Identifies terminology and syntax when seen. |
| L2 | Can explain | Explains how the subsystem works in plain language. |
| L3 | Guided performance | Executes correctly with documentation or hints. |
| L4 | Independent performance | Executes and verifies without hints. |
| L5 | Can troubleshoot | Diagnoses unexpected failures in the subsystem. |
| L6 | Can recover from failure | Restores system state after catastrophic failure or corruption. |
| L7 | Can teach / mentor | Teaches and defends architectural choices to another engineer. |
Every error is analyzed and categorized to identify recurring anti-patterns:
Command · Conceptual · Diagnostic · Reasoning · Safety · Documentation · Verification · Procedural · Architectural
Destructive, break-fix learning requires a well-defined blast radius. The environment is split into three tiers of increasing risk tolerance:
┌─────────────────────────┐ ┌─────────────────────────┐ ┌─────────────────────────┐
│ HOST SYSTEM │ │ DOCKER ENVIRONMENT │ │ DISPOSABLE ARCH VM │
│ (EndeavourOS) │ ───► │ (containers) │ ───► │ (virt-manager / KVM) │
│ │ │ │ │ │
│ Daily driver. │ │ App infra, backend │ │ Destructive │
│ Safe CLI navigation, │ │ processes, DBs, │ │ experiments: │
│ man/info research, │ │ reverse proxies, │ │ partitioning, FS │
│ non-destructive │ │ container lifecycle, │ │ corruption, systemd │
│ inspection only. │ │ volumes, networking. │ │ failure, bootloader/ │
│ │ │ │ │ initramfs breakage, │
│ │ │ │ │ live recovery drills. │
└─────────────────────────┘ └─────────────────────────┘ └─────────────────────────┘
LOW RISK CONTAINED RISK FULL DESTRUCTIVE RISK
| Tier | Environment | Target & Scope |
|---|---|---|
| Tier 1 | Host System (EndeavourOS) | Daily driver; safe CLI navigation, documentation research (man, info, --help), and read-only inspection. |
| Tier 2 | Docker Environment | Application infrastructure, backend services (Node.js, Postgres, Redis, Nginx), container lifecycles, and isolated bridge networks. |
| Tier 3 | Disposable Arch Linux VM (virt-manager / QEMU / KVM) |
Destructive break-fix labs — disk partitioning, filesystem corruption, systemd unit breakage, kernel/initramfs recovery, and emergency chroot repairs. |
Important
Host Safety Rule: If an operation carries a non-zero risk of breaking boot, networking, partitions, or system files, it is strictly forbidden on the host and must run in a disposable VM with a verified snapshot.
| Phase | Title | Focus & Core Competencies |
|---|---|---|
| 0 | Environment & Baseline | Lab safety boundaries, evidence formats, baseline diagnostic assessment. |
| 1 | Unix/Linux Mental Model | Kernel vs userspace, filesystem hierarchy standard, processes, streams, user space. |
| 2 | Shell & CLI Workflow | Command expansion, quoting rules, streams, redirection, pipelines, exit codes ($?). |
| 3 | Text Processing & Wrangling | grep, sed, awk, find, xargs, log parsing, regex, local man pages. |
| 4 | Filesystems & Permissions | POSIX permissions, ownership (chown/chmod), umask, SUID/SGID, sticky bit, sudo. |
| 5 | Processes & Observability | Process trees, ps, top/htop, signals (SIGTERM, SIGKILL), background jobs, /proc. |
| 6 | Arch Package Management | pacman, official mirrors, cache management, package signing, AUR, PKGBUILD, makepkg. |
| 7 | systemd & Services | Unit files, service lifecycle, targets, systemd timers, journald structured logging. |
| 8 | Networking & Remote Access | IP routing, DNS resolution, TCP/UDP sockets (ss/ip), SSH keys & hardening, firewalling. |
| 9 | Storage & Backups | Block devices (lsblk), partitioning (fdisk/parted), ext4/Btrfs, /etc/fstab, backup/restore drills. |
| 10 | Boot & System Recovery | UEFI, bootloader (systemd-boot/GRUB), initramfs (mkinitcpio), kernel parameters, live USB chroot. |
| 11 | Security & Hardening | Least privilege, file integrity, SSH hardening, network exposure, audit tools, OWASP overlap. |
| 12 | Defensive Automation | Robust Bash scripting (set -euo pipefail), idempotence, validation, scheduled jobs. |
| 13 | Virtualization Lab Ops | QEMU/KVM with virt-manager, snapshots, bridge networking, reproducible testbeds. |
| 14 | Docker for Full-Stack | Multi-stage Dockerfiles, Compose, bind mounts vs volumes, container networking, debugging. |
| 15 | Arch Administration | Clean Arch install from scratch in VM, post-install setup, maintenance procedures. |
| 16 | Break-Fix Troubleshooting | SadServers-style incident scenarios, mystery failure diagnosis, root-cause analysis (RCA). |
| 17 | Capstone Practical Exam | Fresh unconfigured VM, multi-point cascading failure injection, recovery, and technical defense. |
This curriculum is grounded in primary, authoritative documentation over secondary tutorials:
- Arch Linux:
- Linux Core & Kernel:
- Developer & Educational Resources:
Real evidence submitted during Phase 0 baseline assessment demonstrating command inspection and understanding:
# Investigating operating system distribution release safely
$ cat /etc/*-release
DISTRIB_ID="EndeavourOS"
DISTRIB_RELEASE="rolling"
PRETTY_NAME="EndeavourOS"
ID="endeavouros"
ID_LIKE="arch"
# Disambiguating kernel build timestamp vs exact kernel release version via `man uname`
$ uname -v
#1 SMP PREEMPT_DYNAMIC Fri, 28 Aug 2026 03:36:07 +0000
$ uname -r
7.1.11-arch1-1Lesson Logged: Shell arguments are whitespace-sensitive (e.g. cat /etc/* -release treats -release as an invalid option flag -r, whereas cat /etc/*-release properly expands file globs).
.
├── instructor/ # System bootstrap, AI behavioral contract, chat interface, state tracking
├── curriculum/ # Master roadmap (roadmap.md), competency map, and phase plans
├── modules/ # In-depth module plans and lesson exercises
├── progress/ # Competency matrix (competencies.md), milestone tracker, hint logs
├── labs/ # Objective-based lab definitions, safety checklists, lab architecture
├── assessments/ # Baseline diagnostic, module exams, and practical scorecards
├── evidence/ # Raw command outputs, terminal logs, reasoning proof
├── learning-log/ # Daily/weekly study logs and session retrospectives
├── mistakes/ # Classified error logs (ERROR_LOG.md) and root-cause analyses
├── troubleshooting/ # Incident post-mortems (INCIDENT_TEMPLATE.md) and diagnostic patterns
├── knowledge/ # Mental models, concept deep-dives, documentation research summaries
├── decisions/ # Durable engineering and architectural decision records
├── remediation/ # Targeted drill plans for observed weaknesses
├── retrospectives/ # Weekly and periodic meta-learning reflections
└── scripts/ # Helper scripts and automation tooling
- Bootstrap: The AI instructor reads
INSTRUCTOR_PROTOCOL.mdandinstructor/BOOTSTRAP.mdto load the behavioral contract, then checksinstructor/CURRENT_STATE.md. - Orient: Cross-reference
progress/progress.md,progress/competencies.md, and the active phase incurriculum/phases/. - Interact: The learner drives sessions naturally or using optional shorthand commands:
/status— Summarize active phase, competencies, and open weaknesses./learn— Start a new concept with Socratic inquiry./practice— Assign a hands-on terminal exercise with constraints./lab— Start or verify an objective-based lab./troubleshoot— Enter an incident break-fix scenario./quiz— Test diagnostic and conceptual reasoning.
- Log & Verify: All work is recorded in
evidence/,learning-log/, andprogress/. No progress is marked without verified output.
- Current Phase: Phase 0 — Environment Setup, Safety & Baseline Diagnostic
- Active VM Tool:
virt-manager/ QEMU / KVM (Installed on EndeavourOS host) - Docker Lab: Installed and verified functional (
hello-worldtest passed) - Baseline Diagnostic Progress: Task D1 (Orientation) completed; Tasks D2–D7 in progress.
- Weekly Commitment: ~20 hours/week.
This is a personal, evidence-backed learning repository and engineering portfolio.
- Contributions: Pull requests directly altering the learning records are not accepted, as this repository tracks individual learning progression.
- Feedback & Reuse: If you have suggestions or want to adapt this repository architecture/templates for your own learning journey, you are free to fork it, and feedback/discussions are warmly welcomed via GitHub Issues!
This repository and its curriculum templates are licensed under the MIT License. See the LICENSE file for full details and copyright information.
Last updated: 2026-09-06