# ADR-0006: Zurück zu Epiphany für den Kiosk-Modus

**Status:** Beschlossen
**Datum:** 21.07.2026

## Kontext

ADR-0005 entschied sich für Chromium statt Epiphany, weil Epiphany im Application-Mode kein wirklich chromeloses Fenster lieferte (Adressleiste und Fenstermenü blieben sichtbar).

Die Umsetzung von Chromium erwies sich als Sackgasse: Vier reale Boot-Tests in Proxmox scheiterten nacheinander an vier unterschiedlichen Fehlerklassen, jedes Mal in einer anderen Schicht der Lösung:

1. `dnf --installroot` direkt ins Live-Payload installiert → hätte `/etc/passwd` überschrieben (`liveuser` wäre verschwunden).
2. Fix (nur `usr/` kopieren) reichte nicht → `usr/` enthält alle ~350 Basis-Pakete → Kernel Panic beim Boot, weil `systemd`/`bash`/`glibc` des Live-Systems überschrieben wurden.
3. Fix (Isolation unter `/opt/tuxflotte/chromium`) behob den Absturz, aber der Dracut-Hook kopierte hunderttausende lose Dateien vor dem Pivot — mehrere Minuten Bootzeit, zusätzlicher RAM-Druck.
4. Fix (Auslieferung als SquashFS-Image, gemountet statt kopiert) behob die Bootzeit, aber Chromium startete gar nicht (`Invalid file descriptor to ICU data received` — `/proc/self/exe` zeigte auf den falschen Pfad wegen des eigenen Loader-Aufrufs).

Der vierte Fix behob das ICU-Problem nachweislich (lokal per `strace` verifiziert), aber der reale Boot-Test zeigte danach immer noch kein laufendes Chromium — vermutlich der beim vierten Fix bereits vermutete `chrome_crashpad_handler`-Folgefehler, aber nicht mehr im Detail untersucht, weil zu diesem Zeitpunkt das Muster selbst zur Entscheidungsgrundlage wurde: vier verschiedene, jeweils erst durch einen echten Boot-Test sichtbare Fehlerklassen in Folge sind kein Zufall, sondern strukturell — ein komplettes, fremdes Chromium-Paket samt ~350 transitiven Abhängigkeiten in eine laufende, andere Live-Umgebung zu verpflanzen, kämpft gegen die Art, wie Chromium gebaut und paketiert ist.

## Entscheidung

Zurück zu Epiphany im Application-Mode (`epiphany --application-mode --profile=/home/liveuser/.local/share/tuxflotte-kiosk`, wie ursprünglich in ADR-0004 beschrieben), trotz sichtbarer Adressleiste und Fenstermenü.

Das ist explizit kein Kompromiss unter Zeitdruck, sondern eine bewusste Neubewertung des ursprünglichen Ablehnungsgrundes: die sichtbare Adressleiste ist in der Praxis kaum relevant, weil

- der angezeigte Inhalt zentral vom Provisioning Server bereitgestellt wird, nicht hartkodiert auf der ISO liegt — es gibt keine sensiblen, auf dem Medium gespeicherten Inhalte, die ein Benutzer über die Adressleiste erreichen könnte,
- die Live-Umgebung ohnehin eine Wegwerf-Sitzung ohne persistente Nutzerdaten ist,
- ein Benutzer, der während der Installation z.B. Nachrichten liest, kein Sicherheitsproblem darstellt, nur ein kosmetisches.

Als möglicher künftiger Baustein (nicht jetzt umgesetzt): ein Watchdog-Prozess, der die Prozessliste beobachtet und bei geschlossenem Browser einen Reboot auslöst — würde ein versehentliches oder absichtliches Verlassen des Kiosk-Kontexts abfangen, unabhängig von der Adressleiste.

Die kosmetische Frage (Epiphany doch noch vollständig chromelos bekommen, z.B. per GTK-CSS-Override der Header-Bar-Widgets) ist explizit zurückgestellt, keine offene Anforderung für die aktuelle Version.

## Konsequenzen

`scripts/build.sh`: `install_chromium()` und ihr Aufruf entfernt, `check_dependencies()` verlangt wieder nur `xorriso`, kein Root/`dnf`/Internetzugriff mehr nötig für den Build. `tuxflotte-installer/build-deps/` (Fedora-GPG-Key) entfernt, da nicht mehr referenziert.

`tuxflotte-installer.desktop`: wieder `epiphany --application-mode --profile=...` wie vor ADR-0005.

ADR-0005 bleibt als historischer Datensatz stehen (git-loses Repo — das ist die einzige Quelle für die dort dokumentierten, tatsächlich funktionierenden Techniken: Isolation unter `/opt`, Loader-Relokation für `/proc/self/exe`, SquashFS-Verpackung), gilt aber als überholt/verworfen.

Weitere Installer-ISO-Optimierung (inklusive einer möglichen erneuten Chromium-Bewertung, oder ob z.B. eine Ubuntu-basierte Live-ISO denselben EROFS-Bug hat) wird explizit auf eine spätere, dedizierte Überarbeitung der ISO verschoben — nicht Teil der aktuellen Arbeit. Priorität verschiebt sich zurück auf die eigentliche Provisionierungslogik (Runtime Blueprint u.a.).

Noch offen, unverändert seit ADR-0004: wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand lesen, Aktionen auslösen).