#!/usr/bin/env bash
set -Eeuo pipefail

# Wird von tuxflotte-installer.service beim Boot direkt auf tty1 gestartet -
# unabhaengig davon, ob config/installer.conf einen Auto-Modus-
# Aktivierungscode mitbringt (personalisierte Kunden-ISO, siehe
# scripts/build_customer_iso.sh) oder nicht (generisches Test-/
# Entwicklungsabbild): installer.sh fragt in letzterem Fall selbst
# interaktiv nach (12_enrollment_auth.sh, 05_network.sh-WLAN-Auswahl), auf
# genau dieser Konsole - der Service leitet dafuer TTYPath=/dev/tty1 durch.
#
# Schreibt zusaetzlich zur journal-Ausgabe (StandardOutput=journal+console
# im systemd-Unit) in eine Logdatei - per SSH/Konsole nachtraeglich
# einsehbar, ohne journalctl zu brauchen.
LOG_FILE="/var/log/tuxflotte-installer.log"

/opt/tuxflotte/scripts/installer.sh 2>&1 | tee -a "${LOG_FILE}"
STATUS="${PIPESTATUS[0]}"

# Live gefunden (31.08.2026): ein ExecStopPost, der beim Dienstende
# getty@tty1.service neu startet, ist unzuverlaessig (Race mit dem eigenen
# TTY-Teardown dieses Dienstes - der Job wurde angestossen, blieb aber
# "inactive/dead"). Stattdessen: diese Konsole faellt nach installer.sh
# (egal ob Erfolg, kontrollierter Abbruch an einem Commit-Gate, oder
# Fehler) deterministisch in eine interaktive Root-Shell - kein Race,
# garantiert nutzbare Konsole fuer Fehlersuche/manuellen Neustart. Im
# Erfolgsfall mit tatsaechlichem Deployment loest 40_backend.sh ohnehin
# selbst einen Reboot aus, wodurch diese Shell nie sichtbar wird.
{
    echo
    echo "Tuxflotte-Installer beendet (Exit-Code: ${STATUS})."
    echo "Diese Konsole steht fuer Fehlersuche/manuellen Neustart zur Verfuegung."
    echo
} | tee -a "${LOG_FILE}"

exec /bin/bash --login