[Unit]
Description=Tuxflotte Installer Auto-Start
Conflicts=getty@tty1.service
After=getty@tty1.service NetworkManager.service
Wants=NetworkManager.service

[Service]
Type=idle
ExecStart=/opt/tuxflotte/scripts/boot-autostart.sh
StandardInput=tty-force
StandardOutput=console
StandardError=console
TTYPath=/dev/tty1
TTYReset=yes
TTYVHangup=yes
# Live gefunden (31.08.2026): ein ExecStopPost, der getty@tty1.service beim
# Dienstende neu startet, ist unzuverlaessig (Race mit dem eigenen
# TTY-Teardown). Geloest stattdessen in boot-autostart.sh selbst: die
# Konsole faellt nach installer.sh deterministisch in eine interaktive
# Shell, kein getty-Neustart noetig.
#
# StandardOutput/Error war zuerst "journal+console" (journalctl konnte die
# Installationsausgabe so zusaetzlich zeigen) - Nutzer-Feedback (01.09.2026,
# echter Hardware-Test): "Der Kernel Zeitstempel ist für den Kunden nicht
# interessant, sondern nur verwirrend." journald spiegelt Konsolen-Ausgaben
# im kmsg-Stil mit einem monotonen "[  12.345678]"-Zeitstempel je Zeile -
# genau das sah aus wie ein Kernel-Log, obwohl es nur unsere eigene
# Installationsausgabe war. "console" (ohne "journal+") verbindet fd1/fd2
# stattdessen direkt mit /dev/tty1, ohne journald-Vermittlung: kein
# Zeitstempel-Praefix mehr, und "-t 1" ist ab hier wieder ein echter,
# zuverlaessiger tty-Test (siehe TUXFLOTTE_TTY_LIVE in boot-autostart.sh).
# journalctl -u tuxflotte-installer zeigt dadurch nur noch die eigenen
# Lebenszyklus-Meldungen des Dienstes, nicht mehr die volle
# Installationsausgabe - die bleibt weiterhin vollstaendig in
# /var/log/tuxflotte-installer.log einsehbar (das war laut Kopfkommentar
# oben ohnehin schon der dokumentierte Weg, "ohne journalctl zu brauchen").

[Install]
WantedBy=multi-user.target