platform-docs/adr/0005-kiosk-ui-chromium.md

# ADR-0005: Chromium statt Epiphany für den Kiosk-Modus

**Status:** Verworfen durch ADR-0006 (21.07.2026) — vier reale Boot-Fehlschläge in Folge, siehe dort. Bleibt als historischer Datensatz stehen: die hier dokumentierten Techniken (Isolation unter `/opt`, Loader-Relokation, SquashFS-Verpackung) funktionierten einzeln nachweislich, nur in Summe erwies sich der Ansatz als zu fragil.
**Datum:** 20.07.2026

## Kontext

ADR-0004 wählte Epiphany im Application-Mode (`--application-mode`) für die Kiosk-Oberfläche, unter anderem mit der Begründung, dieser Modus liefere "ein chromeloses Fenster ohne Adressleiste, Tabs oder Menüs".

Der tatsächliche Test auf dem Live-System widerlegt das für den hier vorgesehenen Einsatzzweck: Epiphany im Application-Mode benötigt explizite Session-/Profildaten (den `--profile=<Verzeichnis>`-Aufbau, wie ihn die bisherige `tuxflotte-installer.desktop` verwendet hat) und liefert trotzdem ein Fenster mit sichtbarer Adresszeile und Fenstermenü — keinen echten Kiosk-Modus. Für eine gebrandete, eingabefreie Provisionierungsoberfläche ist das ungeeignet.

## Entscheidung

Statt Epiphany wird Chromium im echten Kiosk-Modus (`--kiosk`) verwendet.

Chromiums `--kiosk`-Flag liefert ein vollständig chromeloses Fenster ohne Adressleiste und Menü, ohne dass vorab ein Profil oder eine Session angelegt werden muss — das Flag reicht für sich allein.

Chromium ist auf dem verwendeten Fedora-Cinnamon-Live-Image nicht vorhanden (siehe ADR-0004) und muss daher zur Build-Zeit ins Live-Payload aufgenommen werden.

Ursprünglich war geplant, das dadurch wachsende ISO im Gegenzug durch Entfernen großer, nicht benötigter Pakete (z.B. LibreOffice) auszugleichen. Das ist inzwischen verworfen (21.07.2026): Das würde eine Änderung an `/LiveOS/squashfs.img` selbst erfordern, und genau das ist der Bereich, der laut dem in `13-live-provisioning-boot.md` dokumentierten `erofs-utils`-Bug nachweislich destruktiv fehlschlägt. Stattdessen wird die durch Chromium entstehende Größe bewusst in Kauf genommen — siehe Konsequenzen.

## Konsequenzen

ADR-0004 wird in diesem einen Punkt korrigiert: der Browser für den Kiosk ist Chromium statt Epiphany. Die übrigen Entscheidungen aus ADR-0004 — Web-App statt native GTK-Anwendung, fachliche Logik bleibt in den bestehenden Bash-Modulen, die Web-Oberfläche ist ausschließlich Präsentationsschicht — bleiben unverändert gültig.

Umgesetzt (21.07.2026), in zwei Anläufen:

**Erster Anlauf (verworfen):** `dnf --installroot` in ein Wegwerf-Verzeichnis, danach `usr/` und `etc/chromium/` ins reale `updates/`-Payload kopiert (also in das echte `/usr` des Live-Systems gemergt). Das vermied zwar das `/etc/passwd`-Problem des allerersten Versuchs, übersah aber, dass `usr/` selbst alle ~350 transitiven Basis-Pakete enthält — `systemd`, `bash`, `glibc`, `coreutils`, `dbus`, `pam`, `util-linux`. Der reale Testboot in Proxmox endete in einem Kernel Panic ("Attempted to kill init! exitcode=0x00007f00", dekodiert als Exit-Status 127) — die frisch heruntergeladenen Versionen dieser Kerndateien haben die des Live-Systems überschrieben und PID 1 zerschossen.

**Zweiter Anlauf (aktuell):** Vollständige Isolation statt Blockliste. Chromium landet nicht mehr in `/usr`, sondern komplett unter `/opt/tuxflotte/chromium/usr` — ein Pfad, der mit nichts auf dem Live-System kollidieren kann. Gestartet wird über `launch.sh`, das den mitgelieferten eigenen Loader (`ld-linux-x86-64.so.2 --library-path ...`) explizit aufruft, statt sich auf den Loader des Live-Systems zu verlassen (ein einfacher `exec` mit nur `LD_LIBRARY_PATH` gesetzt schlägt mit `undefined symbol ... GLIBC_PRIVATE` fehl, sobald Loader und libc aus unterschiedlichen Builds stammen — lokal reproduziert und verifiziert). Der Such-Suchpfad für Bibliotheken wird beim Start dynamisch durch Scannen aller Unterverzeichnisse unter `lib64`/`lib` ermittelt (nicht hartkodiert), weil Chromium auch private Paket-Unterverzeichnisse braucht (gefunden: `usr/lib64/samba/`) — lokal gegen die echte installierte Chromium-Binary getestet (`chromium-browser --version` liefert korrekt `Chromium 146.0.7680.164`).

**Dritter Anlauf (aktuell): Auslieferung als SquashFS-Image statt loser Dateien.** Der zweite Anlauf löste die Sicherheits-/Korrektheitsprobleme, aber nicht die Performance: Der Dracut-Hook kopiert `/updates` vor dem Pivot Datei für Datei, und ~350 Pakete bedeuten hunderttausende kleine Dateien — auf echter Hardware dauerte allein dieser Kopiervorgang mehrere Minuten, obwohl die Gesamtgröße (~1,2 GB) dafür nicht groß genug wäre (dateianzahl-, nicht größengebunden). Zusätzlich verschärfte das erneut das RAM-Thema (bei 2 GB VM-RAM ~80% Auslastung während des Kopierens). Fix: `usr/` wird zur Build-Zeit mit `mksquashfs` (Standard-Tool, mit dem `erofs-utils`-Bug nicht verwandt) zu einer einzelnen komprimierten Datei gepackt (lokal getestet: 434 MB statt 1,2 GB, Setuid-Bit auf `chrome-sandbox` bleibt erhalten). `launch.sh` mountet diese Datei beim ersten Start per Loop-Mount nach `/opt/tuxflotte/chromium/usr` (nahezu verzögerungsfrei, keine RAM-Duplizierung, Daten bleiben komprimiert auf dem Medium und werden bei Bedarf eingelesen) — das räumt das RAM-Thema strukturell aus, nicht nur durch mehr RAM in der Test-VM.

**Vierter Anlauf (aktuell): `/proc/self/exe`-Fix für die ICU-Ressourcenauflösung.** Der reale Testboot nach Anlauf 3 startete zwar (schnell, dank SquashFS), aber Chromium erschien nicht (`ps aux | grep chromium` fand nichts). `launch.sh` manuell ausgeführt lieferte `Invalid file descriptor to ICU data received`. Per `strace` lokal reproduziert und ursächlich geklärt: Chromium bestimmt sein eigenes Ressourcenverzeichnis über `dirname(readlink(/proc/self/exe))`. Weil `launch.sh` den Loader aus `usr/lib64/ld-linux-x86-64.so.2` direkt aufruft, zeigt `/proc/self/exe` auf den Loader selbst (in `usr/lib64/`), nicht auf `chromium-browser` (eine Ebene tiefer in `usr/lib64/chromium-browser/`) — Chromium sucht `icudtl.dat` deshalb am falschen Ort. Fix: eine Kopie des Loaders wird zur Build-Zeit direkt neben `chromium-browser` gelegt (`usr/lib64/chromium-browser/ld-linux-x86-64.so.2`) und von dort aus gestartet — `/proc/self/exe` zeigt dann korrekt ins richtige Verzeichnis. Lokal verifiziert: der ICU-Fehler verschwindet vollständig.

Beim Weitertesten (lokal, ohne echten Fedora-Live-Boot) trat danach ein zweiter Fehler auf: `chrome_crashpad_handler` (Absturzbericht-Hilfsprozess, von Chromium selbst per `execve()` mit eigenem, nicht von uns kontrolliertem Pfad gestartet) scheiterte an fehlenden `GLIBC_2.38`/`GLIBC_2.39`-Symbolen im System-Loader. Sehr wahrscheinlich ein Artefakt der lokalen Testumgebung (Debian Bookworm, glibc von 2022) und kein Problem auf dem eigentlichen Zielsystem (Fedora Cinnamon Live 44, deutlich näher an der `dnf`-heruntergeladenen Version) — aber ohne echten Boot nicht abschließend auszuschließen. Als nächster Schritt bei erneutem Scheitern: `chrome_crashpad_handler` per denselben Loader-Trick abfangen, oder Absturzberichterstattung ganz deaktivieren.

Details siehe `13-live-provisioning-boot.md`, Abschnitt „Autostart von installer.sh". Akzeptierter Nebeneffekt unverändert: `dnf` löst den vollen Abhängigkeitsbaum auf (351 Pakete), nicht nur Chromium plus tatsächlich fehlende Bibliotheken — eine gezielte Verschlankung ist mangels Lesezugriff auf die `squashfs.img` nicht verifizierbar.

Neue Build-Voraussetzung: `build.sh` braucht jetzt Root-Rechte (`dnf --installroot` verlangt das) sowie Internetzugriff zu Fedora-Repos. Bewusster Sicherheits-Trade-off: `chrome-sandbox` (Setuid-Root-Helfer) wird zwar unverändert mitkopiert, aber ob er von dem neuen, isolierten Pfad aus funktioniert, ist ungeprüft — `launch.sh` startet vorerst mit `--no-sandbox`, vertretbar für eine Wegwerf-Live-Session ohne sensible Daten, aber keine Nebensächlichkeit. Noch nicht per echtem grafischem Live-Boot verifiziert.

Die in ADR-0004 offen gelassene Frage, wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand lesen, Aktionen auslösen), bleibt unverändert offen und ist von der Browserwahl unabhängig.