archinstall/docs/obsidian/0.1.archinstall-stack.md

System Design: Archinstall Stack Analysis

This document evaluates the existing archinstall codebase architecture in the context of the new mddosinstall MVP goals (a stripped-down, secure, barebones Hyprland + quickshell installer).

1. Requirements & Constraints

• Functional: The system must install Arch Linux, specifically configuring zram, systemd-boot (quiet+plymouth), NetworkManager, greetd, and a Hyprland profile.
• Non-functional: The codebase must be maintainable, minimizing technical debt by aggressively pruning unused profiles, applications, and legacy TUI menus.
• Constraints: The system is an offline/live-environment installer script, built entirely in Python using curses/TUI for user interaction.

2. High-Level Architectural Flow

1. Entry Point (main.py): Parses arguments, initializes logging, and invokes the TUI.
2. TUI/UI Layer (archinstall/tui/ and archinstall/lib/menu/): Manages the curses-based menus where the user configures the system.
3. Data Models (archinstall/lib/models/): Holds the state of the user's choices (Disk, Network, Profile, etc.).
4. Hardware/System Abstraction (archinstall/lib/): Executes shell commands via archinstall.lib.command.SysCommand to interact with Pacstrap, systemd, and disk utilities.
5. Execution (archinstall/lib/installer.py): Consumes the configuration models to mount disks, pacstrap base packages, chroot in, configure the bootloader, and export the logs/handoff data.

3. Deep Dive: Component Stack Analysis

Below is an analysis of each major module/directory in the archinstall stack, its original intent, and the architectural decision (Keep, Modify, or Delete) for the MVP.

3.1. Core Engine & Entry Points

Component	Original Intent	Decision	Notes
archinstall/main.py	Primary entry point, argument parsing, main execution loop.	Modify	Simplify the CLI arguments if necessary, wire it to the new 7-step hierarchical global menu.
archinstall/lib/installer.py	The main Installer class that handles the pacstrap and chroot logic.	Modify	Needs modifications for Phase 5 (Post-Install Handoff) to ensure mddos_config.json and logs are safely copied to /etc/mddos/.
archinstall/lib/command.py	Wrapper for executing and logging shell commands (SysCommand).	Keep	Essential for our cmd_history.txt and install.log requirements.
archinstall/lib/hardware.py	Hardware detection (CPU microcode, Graphics cards).	Keep	Required for the automatic ucode injection and the NVIDIA driver warning fallback.

3.2. User Interface (TUI & Menus)

Component	Original Intent	Decision	Notes
archinstall/tui/	The curses framework building blocks (checkboxes, inputs, lists).	Keep	Core UI library. We will heavily reuse the checkbox list components.
archinstall/lib/menu/global_menu.py	The main menu the user sees.	Modify	Complete rewrite required (Phase 1) to implement the 7-step hierarchy (Locales, Disk, System, Auth, Profile, Advanced, Install).
archinstall/lib/general/system_menu.py	Handles kernel, audio, etc.	Modify	Strip old options, implement systemd-boot defaults, zram swap, and pacman checkboxes.

3.3. Profiles & Applications (The "Bloat")

Component	Original Intent	Decision	Notes
archinstall/default_profiles/desktops/	JSON configs for GNOME, KDE, XFCE, Sway, etc.	Delete	Nuke everything except a customized hyprland.json to enforce the Secure Barebones MVP.
archinstall/default_profiles/servers/	JSON configs for web servers, database servers.	Delete	Not relevant to a Hyprland desktop installer.
archinstall/lib/profile/	Logic for parsing and installing desktop profiles.	Modify	Hardcode the Hyprland lock and display the "More desktop environments will be given support later" tooltip.
archinstall/applications/	Helper scripts to install generic apps (like tailscale, docker, etc.).	Delete	The PRD explicitly defers "Additional packages" to the post-install wizard. This folder can be purged.

3.4. System Configuration Modules

Component	Original Intent	Decision	Notes
archinstall/lib/disk/	Disk partitioning, BTRFS, LUKS, formatting logic.	Keep	The PRD states disk configuration will be kept the same. Excellent, battle-tested code.
archinstall/lib/bootloader/	GRUB, systemd-boot, Limine logic.	Modify	Enforce systemd-boot (quiet + plymouth) as the default. Strip GRUB if deemed unnecessary for modern UEFI systems (optional, but recommended for simplicity).
archinstall/lib/network/	NetworkManager, iwd, systemd-networkd configurators.	Keep / Modify	Keep NetworkManager logic, ensure it defaults to NM instead of systemd-networkd as per PRD.
archinstall/lib/authentication/	Users, passwords, sudo, polkit setups.	Modify	Implement the Lock root account logic and dynamic UI disabling (Phase 3).

3.5. Auxiliaries

Component	Original Intent	Decision	Notes
archinstall/locales/	Language translations.	Keep	Internationalization is good, even if the default is English.
archinstall/scripts/	Standalone example scripts or test harnesses.	Delete	Mostly clutter for an opinionated fork.

4. Scale and Reliability

• Scale: Does not apply to a local installer script.
• Reliability: By strictly limiting the Desktop Environments (Hyprland only) and Display Managers (greetd only), we drastically reduce the state-space of potential failures. The system is inherently more reliable than upstream archinstall.

5. Trade-off Analysis

• Trade-off 1 (Flexibility vs. Maintenance): Deleting 90% of the default_profiles/ and applications/ severely limits user choice during the install phase. However, it guarantees a predictable baseline system for the post-install wizard, reducing developer maintenance burden by orders of magnitude.
• Trade-off 2 (Root Account Locking): Defaulting to locking the root account prevents users from relying on legacy root logins. The trade-off is they must ensure their primary user has correct sudo/polkit permissions, which archinstall currently handles reasonably well but must be thoroughly tested.

6. Output & Revisit Strategy

• As the system grows, we will need to revisit archinstall/lib/profile/ to re-introduce other environments (Sway, KDE) once the base architecture proves stable.
• The immediate next step is to begin systematically deleting the Delete components to clean the workspace, followed by refactoring the global_menu.py.