# Milestones

## 2026-07-20

### First successful end-to-end interactive provisioning run on the live ISO

The full interactive provisioning pipeline ran successfully for the first time inside the live-ISO boot chain introduced in ADR-0003, from GRUB through `installer.sh` to a clean exit — tested live in Proxmox.

Boot flow:

GRUB (Tuxflotte entry, live medium)
→ Cinnamon live session autostarts a terminal (dracut pre-pivot `/updates` hook, no squashfs/EROFS modification)
→ installer.sh runs every module in sequence:
00_preflight → 05_network → 10_hardware → 12_enrollment_auth → 15_server_handshake → 17_device_status → 20_profile_selection → 25_installation_confirm → 30_runtime_blueprint → 40_backend (full Fedora backend lifecycle) → 20_storage → 99_finish

Verified components:

* Live-ISO boot with the GRUB auto/interactive entries (ADR-0003)
* Dracut `20-apply-live-updates.sh` hook injecting `/opt/tuxflotte` and autostart/sudoers config, no image remastering
* Device activation and enrollment against the real provisioning server
* Bereitstellungsvorlage selection and Commit Point confirmation
* Runtime Blueprint resolution against the real server (`fedora`/`schulcomputer` keys, not UUIDs)
* Full Fedora backend lifecycle (`backend_init` → `validate` → `generate_config` → `launch` → `postinstall`)
* Disk detection (`20_storage.sh`)

Bugs found and fixed only by this live run (none reproducible from isolated testing):

* `05_network.sh` crashed on live/ephemeral NetworkManager connections without a backing keyfile
* `20_storage.sh` was a pre-existing stub that never sourced the functions it called
* Missing execute bit on `backend.sh`, `30_runtime_blueprint.sh`, `40_backend.sh` (only ever tested via manually-chmod'd copies)
* sudoers.d drop-in needs explicit root ownership set via `xorriso -chown_r`/`-chgrp_r`, since the build has no local root

Result:

The live-ISO architecture from ADR-0003 is validated end-to-end, not just at the boot-menu level. `backend_launch()`/`backend_postinstall()` remain Phase 1 stubs — the native installer is not yet actually started.

## 2026-06-16

### First successful unattended Fedora installation

A Fedora virtual machine was successfully installed using a Kickstart definition served from the provisioning platform.

Installation flow:

Fedora Netinstall ISO
→ HTTPS
→ anode.tuxflotte.de
→ Kickstart definition
→ Automatic installation
→ Reboot
→ Successful login

Verified components:

* Proxmox VM
* Pangolin reverse proxy
* FastAPI provisioning service
* HTTPS / Let's Encrypt
* Fedora Kickstart
* Automatic partitioning
* User creation
* Package installation
* Post-install scripts
* Git repository access
* Ansible installation

Result:

The core architecture of the Tuxflotte Provisioning Platform has been validated end-to-end.