platform-docs/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md

# ADR-0023: `priority=critical` fürs wirklich unbeaufsichtigte Mint-Install

**Status:** Beschlossen
**Datum:** 28.08.2026

## Kontext

Beim ersten echten Self-Service-Flow-Test auf physischer Hardware (Notebook,
Organisation "Liebherr", 28.08.2026) zeigte die Installation trotz
"Tuxflotte Auto-Install"-Bootmenüeintrag (`automatic-ubiquity noprompt` im
Kernel-Append, korrekter, vollständig aufgelöster Preseed mit allen
nötigen Werten — Netzwerk, Zeitzone, Partitionierung, Benutzer, Codecs)
**jede** Ubiquity-Seite interaktiv an: Zeitzone-Bestätigung,
Multimedia-Codecs-Frage, "Vorhandene Installation überschreiben?" und
Benutzeranlage.

Ausführliche Live-Fehlersuche (siehe [[project_e2e_flow_dogfooding_2026-08-28]]
für den vollständigen Verlauf) hat mehrere naheliegende Verdächtige
geprüft und ausgeschlossen, bevor die eigentliche Ursache gefunden wurde:
- Falsch gewählter Bootmenüeintrag — ausgeschlossen (User hat "Tuxflotte
  Auto-Install" korrekt gewählt, bestätigt durch Bildschirm: kein
  Cinnamon-Desktop sichtbar, nur Ubiquitys eigenes Vollbildfenster — Abbruch
  legt den normalen Desktop darunter frei, das automatische Ubiquity läuft
  also tatsächlich).
- Fehlende/kaputte WLAN-Zugangsdaten im Preseed — ausgeschlossen (`/opt/
  tuxflotte/config/installer.conf` enthielt alle vier erwarteten Zeilen
  korrekt; dasselbe Verhalten trat auch mit funktionierendem Ethernet auf).
- Dateiberechtigungen (`installer.conf`, `sudoers.d/90-tuxflotte`) —
  ausgeschlossen, per `xorriso -lsdl` an der echten gebauten ISO
  gegengeprüft, beide unauffällig (644 bzw. das für sudoers.d korrekte 440
  root:root).
- Fehlende Codec-Preseed-Zeile — ausgeschlossen, `ubiquity ubiquity/
  use_nonfree boolean true` war bereits korrekt gesetzt (die dokumentierte
  Lösung für ein bekanntes Mint-21-Problem, siehe
  https://github.com/linuxmint/mint21-beta/issues/34).

**Tatsächliche Ursache:** `automatic-ubiquity` allein bewirkt laut Ubiquity-
Dokumentation nur, dass Seiten übersprungen werden, deren Fragen *alle*
bereits beantwortet ("seen") sind — reicht in der Praxis oft nicht aus, um
wirklich jede Seite zu unterdrücken. Der fehlende Baustein ist die
Debconf-Priorität: ohne `priority=critical` zeigt der Installer weiterhin
Seiten an, auch wenn die zugehörigen Fragen vorbelegt sind. Durch mehrere
unabhängige Quellen bestätigt (siehe Recherche im Chat).

## Entscheidung

`priority=critical` zum Kernel-Append des "Tuxflotte Auto-Install"-
Menüeintrags ergänzt — in `grub/mint-boot-grub.cfg` und `grub/mint-
isolinux-live.cfg`, jeweils nur bei diesem einen Eintrag (die übrigen
Menüpunkte wie "Start Linux Mint"/"OEM install" bleiben bewusst
unverändert interaktiv). Beide Dateien werden sowohl vom echten
Kunden-ISO-Bau (`scripts/build_customer_iso.sh`) als auch vom lokalen/
QEMU-Testpfad (`scripts/build.sh`) verwendet — der Fix deckt also beide
Wege ab, ohne eine zweite Stelle anfassen zu müssen.

## Konsequenzen

Reine Boot-Parameter-Änderung, kein Preseed-/Server-/Agent-Code betroffen.
Noch **nicht live verifiziert** — die nächste ISO, die für "Liebherr" (oder
jede andere Organisation) gebaut wird, enthält den Fix automatisch, da
`build_customer_iso.sh` die Dateien bei jedem Bau frisch kopiert. Die
eigentliche Verifikation folgt beim nächsten Installationsversuch des
Users.

Offen, falls `priority=critical` allein nicht ausreicht: die
Zusammenfassungsseite (`ubiquity ubiquity/summary note`) müsste laut
Recherche ggf. auf einen leeren Wert gesetzt werden, um ebenfalls
übersprungen zu werden — nicht vorab geändert, da nicht durch eigene
Beobachtung bestätigt, nur in der Recherche als möglicher Zusatzpunkt
aufgetaucht.

## Nachtrag (28.08.2026): `priority=critical` war notwendig, aber nicht hinreichend — echte Ursache tiefer

Live-Verifikation in der QEMU-Test-VM (`tuxflotte-mint-autoinstall-test`,
siehe [[project_e2e_flow_dogfooding_2026-08-28]]) hat den in dieser ADR
angenommenen Rahmen korrigiert:

1. **Der "Tuxflotte Auto-Install"-Bootmenüeintrag selbst ist strukturell
   kaputt und war nie der richtige Pfad.** Er referenziert
   `file=/cdrom/preseed/tuxflotte.seed` — dieses Verzeichnis existiert auf
   keiner gebauten ISO (`ls /cdrom/` bestätigt: kein `preseed/`-Ordner).
   `build_customer_iso.sh` bäckt bewusst keinen Preseed auf die ISO (siehe
   eigener Kommentar dort) — Hostname/Geräte-ID/Partitionierung werden
   erst live aufgelöst.
2. **Der tatsächlich funktionierende Mechanismus existiert bereits seit
   06.08.2026 (Commit `d6a0146`): `backend_launch()` in
   `backends/mint/backend.sh`.** Er baut zur Laufzeit einen echten,
   vollständig aufgelösten Preseed, hängt ihn als zusätzlichen
   cpio-Layer an `/cdrom/casper/initrd.lz` an und bootet per `kexec` neu
   mit `automatic-ubiquity noprompt file=/preseed.cfg …`. Erreicht wird
   dieser Pfad aber nur über den **"Start Linux Mint"-Eintrag** (bzw.
   jeden Nicht-`automatic-ubiquity`-Eintrag) → `start-kiosk.sh` erkennt
   `TUXFLOTTE_AUTO_MODE=true` → `installer.sh` → `40_backend.sh` →
   `backend_launch()`. Live bestätigt: `/sbin/init`-Cmdline im zweiten
   Boot lautet `automatic-ubiquity noprompt splash`, `ubiquity --automatic
   --only` und `debconf-communicate -fnoninteractive` laufen tatsächlich.
   Der Nutzer hatte diesen Mechanismus korrekt in Erinnerung, meine
   eigene Aussage in einer früheren Session, `backend_launch()` sei ein
   Stub, war falsch (nicht ausreichend im Git-Log/in den ADRs
   nachgeprüft).
3. **Trotz vollständig aufgelöstem Preseed und korrekt gesetztem
   `priority=critical` bleibt Ubiquitys GTK-"Automatic"-Frontend auf
   diesem Mint-22.3-Ubiquity-Build an mehreren Seiten hängen und wartet
   auf einen manuellen Klick.** Live beobachtet: Multimedia-Codecs-Seite
   blieb >60s ohne jede neue Zeile in `/var/log/installer/debug`
   (`widget found for ubiquity/use_nonfree` war die letzte Zeile) —
   erst ein per QMP `input-send-event` simulierter Mausklick auf
   "Continue" brachte Fortschritt. Gleiches Muster danach bei
   "Installation type" und beim "Änderungen auf Speichergerät
   schreiben?"-Bestätigungsdialog — jede Seite pausiert bis zum Klick,
   obwohl die zugrunde liegenden Debconf-Werte laut Preseed bereits
   beantwortet sind. Das deckt sich exakt mit dem realen Befund auf der
   physischen Hardware (Zeitzone/Codecs/Überschreiben/Benutzeranlage
   alle interaktiv) — es lag nie an einem fehlenden Preseed-Wert oder an
   `priority=critical`, sondern daran, dass Ubiquitys automatischer
   GTK-Modus auf diesem Fork Werte vorbelegt, aber die
   Seitennavigation selbst nicht automatisch durchläuft.

**Korrigierter Stand:** `priority=critical` bleibt eine sinnvolle, nicht
schädliche Ergänzung, löst das eigentliche Problem aber nicht. Die
offene Frage — GUI-Auto-Klick-Mechanismus (z. B. `xdotool`, von
`installer.sh` nach dem kexec-Sprung gestartet) vs. Ubiquity im
Backend-/Textmodus ohne GTK-Frontend ansteuern vs. bewusster Verzicht auf
volle Klick-Freiheit — ist mit dem User noch zu klären, siehe
[[project_e2e_flow_dogfooding_2026-08-28]] Fund 8.

## Zweiter Nachtrag (28.08.2026): Ursache endgültig gefunden und behoben — zwei unabhängige Bugs

Der Nutzer erinnerte sich korrekt, dass die kexec-Automatisierung schon
einmal (06.08., Commit `d6a0146`) bis zum Login-Bildschirm durchgelaufen
war. Live-Nachstellung in der QEMU-VM (frische Disk, sauberer Boot über
"Start Linux Mint") deckte zwei komplett unabhängige, bis dahin nie
bemerkte Bugs auf, die zusammen jede automatisierte Installation seit
langem verhindert haben:

**1. `start-kiosk.sh` hatte `/home/liveuser` hartkodiert** (`mkdir -p
/home/liveuser/...` und der Epiphany-Profilpfad). Der tatsächliche
Live-Benutzername auf dieser ISO ist überall `mint` (siehe
`grub/mint-*.cfg`, `username=mint`). `/home/liveuser` existiert nicht
und kann vom Live-User nicht angelegt werden (`/home` ist nicht
schreibbar) — mit `set -euo pipefail` brach das Skript dort sofort mit
"Permission denied" ab, **noch bevor** die `TUXFLOTTE_AUTO_MODE`-Prüfung
überhaupt erreicht wurde. `installer.sh` lief dadurch nie los, `NoDisplay=true`
im Autostart-Eintrag verschluckte den Fehler komplett lautlos — nach
außen sah es wie ein ganz normaler, nicht-automatisierter Live-Desktop
aus. **Fix:** `${HOME}` statt hartkodiertem Pfad.

**2. `backend_launch()`s kexec-Sprung nutzte nur `automatic-ubiquity`.**
Das lässt Casper weiterhin Ubiquitys GTK-Oberfläche starten
(`ubiquity-dm`), die zwar alle Preseed-Werte korrekt vorbelegt, aber pro
Seite trotzdem auf einen Klick wartet — live beobachtet: die
Multimedia-Codecs-Seite blieb ohne Klick über 60 Sekunden unverändert
stehen (kein neuer Eintrag in `/var/log/installer/debug`), ein per QMP
simulierter Mausklick brachte erst Fortschritt, dasselbe Muster
wiederholte sich bei "Installation type" und beim
"Änderungen schreiben?"-Bestätigungsdialog. Das erklärt exakt das auf
echter Hardware beobachtete Verhalten (Zeitzone/Codecs/Überschreiben/
Benutzeranlage alle interaktiv trotz "automatischem" Modus) — nie ein
fehlender Preseed-Wert, sondern eine grundsätzliche Eigenschaft von
Ubiquitys GTK-Automatic-Modus auf diesem Codestand.

**Fix:** Zusätzliches Boot-Keyword `noninteractive` im kexec-Append
(siehe `/usr/share/ubiquity/start-ubiquity-dm`: bei diesem Keyword ruft
Casper direkt `ubiquity noninteractive` auf, statt die GTK-Oberfläche zu
starten). Das ist Ubiquitys eigenes, mitgeliefertes Headless-Frontend
(`ubiquity/frontend/noninteractive.py`) — verarbeitet jede Seite mit
`auto_process=True` rein über Debconf, ohne je ein Fenster zu zeichnen;
`question_dialog()` ist absichtlich nicht implementiert (wirft
`NotImplementedError`) für alles, was sich nicht aus dem Preseed
beantworten lässt — sauberes Scheitern statt stillem Hängenbleiben.

**Live-Verifikation (QEMU, frische 40-GB-Disk):**
- Zweiter Boot nach kexec hat `noninteractive` korrekt im
  `/proc/cmdline`.
- `pgrep -a ubiquity` zeigt keinen laufenden GTK-`ubiquity-dm`-Prozess.
- `/var/log/installer/debug` bestätigt den Frontend-Wechsel eindeutig
  per Exception-Traceback: `ubiquity.frontend.noninteractive.Wizard
  does not implement question_dialog`.
- **Verbleibende, jetzt exakt lokalisierte Lücke:** `ubi-partman.py`
  (Zeile 3484) stellt beim Partitionieren eine Frage, die im aktuellen
  Preseed noch nicht beantwortet ist — welche genau, ist noch offen
  (nächster Schritt). Das ist ein erheblicher Fortschritt gegenüber
  vorher: statt eines unklaren, seitenübergreifenden Hängenbleibens gibt
  es jetzt einen einzigen, exakt benannten fehlenden Preseed-Wert.

Beide Fixes committed und gepusht (`backends/mint/backend.sh`,
`live-updates/opt/tuxflotte/kiosk/start-kiosk.sh`,
`live-updates/etc/sudoers.d/90-tuxflotte`), siehe
[[project_e2e_flow_dogfooding_2026-08-28]] für den vollständigen
Untersuchungsverlauf.

## Nachtrag (29.08.2026): `noninteractive` verworfen, Umstieg auf
## `automatic-ubiquity` + eigener Autoklicker, mehrere echte Bugs gefunden

Die "verbleibende Lücke" oben (eine unbeantwortete Preseed-Frage in
`ubi-partman.py`) erwies sich als der erste von mehreren Funden in einer
langen, sehr tief gehenden Sitzung. Kurzfassung des Ergebnisses vorab:
**`noninteractive` wurde komplett verworfen**, `automatic-ubiquity`
(echte GTK-Oberfläche) plus ein eigener Autoklicker sind jetzt der
Ansatz. Drei reale, unabhängige Bugs wurden gefunden und behoben. Ein
letzter Schritt (der Klick auf "Jetzt installieren" auf der
Partitionierungs-Übersichtsseite) ist noch nicht zuverlässig
automatisiert - siehe "Offen" am Ende.

### `noninteractive` selbst ist strukturell nicht tragfähig

Iteratives Beantworten einzelner fehlender Preseed-Werte (über 30 Stück,
per `config.dat`/`templates.dat`-Abgleich auf dem laufenden Live-System
diagnostiziert) brachte `ubi-partman.py` immer weiter, endete aber
zuverlässig in einer echten Endlosschleife im `choose_partition`-Zustand
(über 100.000 Debconf-Protokollzeilen in wenigen Sekunden, kein
Fortschritt). Ursache, per Quelltextanalyse gefunden: `choose_partition`
ist die Frage des MANUELLEN Partitionierers; deren Bearbeitung in
`ubi-partman.py` baut einen internen Cache auf und wartet danach auf
einen echten GTK-Button-Klick (`ok_handler()`), der über
`PageNoninteractive` nie kommt - `PageNoninteractive.get_autopartition_choice()`
und verwandte Methoden sind nur Stubs (`pass`/`None`). Das ist keine
fehlende Preseed-Zeile, sondern eine strukturelle Lücke im mitgelieferten
Headless-Frontend selbst.

**Entscheidung:** zurück zu `automatic-ubiquity` (echte GTK-Oberfläche,
`PageGtk` - der von Ubiquity selbst produktiv genutzte, echte
Code-Pfad), dafür ein eigener Autoklicker
(`live-updates/opt/tuxflotte/scripts/autoclicker.sh` + systemd-Service),
ausgelöst durch das eigene Boot-Keyword `tuxflotte-autoclick`.

### Bug 1: `jq` fehlt beim automatisierten Start über den Kiosk (real blockierend)

Der reale Self-Service-Auslöser (`start-kiosk.sh` im Auto-Modus:
`exec sudo installer.sh`, kein Terminal, keine sichtbare Ausgabe) blieb
sofort im allerersten Modul (`10_hardware.sh`) mit "Benötigtes Programm
nicht gefunden: jq" hängen - unsichtbar, nur in `~/.xsession-errors`
sichtbar, nicht in `journalctl` (kein systemd-Unit). Alle bisherigen
Testläufe in dieser Untersuchung sind daran nie gescheitert, weil `jq`
vor jedem manuellen `installer.sh`-Aufruf von Hand nachinstalliert wurde
(bekannte, bisher bewusst zurückgestellte Lücke, siehe
`backend_init()`-Kommentar in `backends/mint/backend.sh`) - der reale
Kiosk-Auslöser hat diesen manuellen Schritt naturgemäß nie bekommen.
`backend_init()` installiert `jq` zwar nach, aber erst in Modul 40
(`40_backend.sh`) - viel zu spät für Modul 10.

**Fix:** neues Modul `scripts/modules/00_preflight.sh` (lief bisher leer),
installiert `jq` als allererstes, vor jedem anderen Modul. Live über den
echten Kiosk-Auslöser (nicht manuell) verifiziert: `installer.sh` lief
danach vollständig automatisch bis zum `kexec`-Sprung durch.

### Bug 2: Ubiquity-GTK-Absturz in `ubi-prepare.py` (echter Ubiquity-Bug)

Mit `automatic-ubiquity` stürzte der Installer auf der "Vorbereiten"-Seite
reproduzierbar ab: `TypeError: Argument 1 does not allow None as a value`,
in `ubi-prepare.py::enable_download_updates()`,
`self.label_download_updates.set_label(self.controller.get_string(template))`.
Das Argument, nicht das Widget, ist None: `get_string('ubiquity/text/label_download_updates_na')`
liefert keinen Wert (fehlende Übersetzung/Vorlage für diesen Zustand),
GTK akzeptiert dafür kein `None`. Preseeden von
`ubiquity/download_updates` half nicht - der auslösende Callback
(`plugin_set_online_state`, an einen NetworkManager-Online-Status-Wechsel
gebunden) feuert unabhängig vom Preseed-Wert.

**Fix:** gezielter Sed-Patch statt Ersatz der kompletten
Drittanbieter-Datei, eingehängt im bestehenden
`initrd-hooks/casper-bottom/99casperboot`-Hook (läuft bei jedem
Casper-Boot, auch nach dem Kexec-Sprung):
```sh
sed -i "s/self\.controller\.get_string(template))/self.controller.get_string(template) or '')/" \
    /root/usr/lib/ubiquity/plugins/ubi-prepare.py
```
Live verifiziert: derselbe Ablauf, der vorher exakt an dieser Stelle
abstürzte, lief danach sauber weiter bis zur Partitionierungsseite.

### Bug 3: `partman/choose_partition select finish` erzwingt denselben Endlosschleifen-Zustandsautomaten wie bei `noninteractive` - auch im GTK-Modus

Nach Fix 1+2 lief die Installation weiter, hing aber erneut in derselben
`choose_partition`-Endlosschleife wie beim verworfenen
`noninteractive`-Versuch (>100.000 Debconf-Zeilen in Sekunden) - diesmal
mit `automatic-ubiquity`. Ursache identisch zur strukturellen Analyse
oben: das direkte Preseeden von `partman/choose_partition select finish`
zwingt `ubi-partman.py` in den manuellen Partitionierer-Zustandsautomaten,
unabhängig vom Frontend - der ist für einen echten, interaktiv
aufgebauten Seitenwechsel gedacht, nicht für ein direkt vorausgefülltes
Ergebnis ohne echten Seitenaufbau.

**Fix:** die Zeile `d-i partman/choose_partition select finish` ersatzlos
aus `preseed.tpl` entfernt. `partman-auto/method` + `expert_recipe` +
`choose_recipe` (bereits vorhanden) genügen, um die geführte
Partitionierung auf dem dafür vorgesehenen Weg laufen zu lassen. Live
verifiziert: Endlosschleife verschwunden (Debug-Log-Länge sank von
>100.000 auf ~1.700 Zeilen für denselben Ablaufabschnitt), Installer
zeigt danach korrekt die echte Partitionierungs-Übersichtsseite mit dem
tatsächlich konfigurierten Layout (ESP + 42-GB-ext4-Root gemäß Rezept).

### Nebenfund: GRUB/isolinux-Standardeintrag "von lokaler Festplatte
### booten" ist ABSICHTLICH so, kein Bug

Während der Fehlersuche wirkte ein per QEMU/SeaBIOS beobachtetes
Boot-Hängenbleiben zunächst wie ein Infrastrukturproblem (ausführlich
mit Bisektion über mehrere xorriso-Neubauten eingegrenzt). Tatsächliche
Ursache: das ISO bootet per Voreinstellung "von lokaler Festplatte" (auf
der frischen Test-Disk naturgemäß leer/nicht bootfähig) - das ist eine
bewusste, bereits am 01.08.2026 getroffene Sicherheitsentscheidung
(siehe ADR-0009, Abschnitt "Bootmenü als eigentlicher Sicherheits-Gate"):
die destruktive Installation soll nur bei aktiver Menüauswahl starten,
nie automatisch beim bloßen Verstreichen des Countdowns. Kein Fix nötig
- für Tests (und für Kunden) muss der Eintrag "Start Linux Mint" (bzw.
in Produktion später ein reparierter "Tuxflotte Auto-Install"-Eintrag)
aktiv ausgewählt werden.

### Offen: automatisierter Klick auf "Jetzt installieren" noch nicht
### zuverlässig

Nach Fix 3 erreicht der Installer real die Partitionierungs-Übersichts-
seite korrekt und wartet dort auf einen Klick auf "Jetzt installieren".
`autoclicker.sh` (Enter-Taste an das Hauptfenster) hat auf dieser
speziellen Seite keinen Effekt - Enter aktiviert dort einen
Ausklapp-Pfeil eines Status-Panels ("Konfiguration der Installation wird
überprüft ..."), nicht den Installieren-Button. Mausklick-Versuche per
`xdotool`/QMP auf berechnete Fensterkoordinaten scheiterten an
unzuverlässiger Fenstererkennung (mehrere überlappende X11-Fenster
ähnlicher Größe durch Metacity-Fensterdekoration, "größtes sichtbares
Fenster"-Heuristik traf wiederholt das falsche Fenster) - bewusst NICHT
in den produktiven Autoklicker übernommen, um kein Risiko fehlgeleiteter
Klicks (z. B. versehentlich eine "Formatieren?"-Checkbox) einzugehen.
Zusätzlich wurde dabei ein eigener, unabhängiger Bug in der
Fenstersuche gefunden und behoben: `autoclicker.sh` suchte bisher nach
einem Fenster namens "ubiquity" - der tatsächliche Fenstertitel ("Installation
(as superuser)") enthält dieses Wort nie, die Suche fand also nie
etwas. Das ist jetzt korrigiert (Suche nach jedem betitelten sichtbaren
Fenster statt nach dem Namen "ubiquity"), der eigentliche Klick-Schritt
bleibt aber offen.

**Nächster Schritt, nicht mehr in dieser Sitzung verfolgt:** vermutlich
robusteste Lösung wäre AT-SPI (Accessibility-API) statt Pixel-/Fenster-
Heuristik - findet Buttons über ihre Rolle ("Push Button") und ihren
(übersetzten) Namen, unabhängig von X11-Fensterüberlappung. Nicht
recherchiert, da Zeitrahmen dieser Sitzung erschöpft.