From d8626aa4e9a52050287975130d40d17f5bc5a8f2 Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Sat, 29 Aug 2026 16:15:42 +0200 Subject: [PATCH] docs: ADR-0023-Nachtrag - AT-SPI-Autoklicker fertig+verifiziert, neuer partman-rebuild-cache-Blocker gefunden Co-Authored-By: Claude Sonnet 5 --- ...ity-priority-critical-fuer-echte-stille.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md b/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md index 5c08a88..717c24d 100644 --- a/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md +++ b/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md @@ -333,3 +333,99 @@ 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. + +## Nachtrag (29.08.2026): AT-SPI-Autoklicker gebaut, live verifiziert - +## neuer, tieferer Blocker in ubi-partman.py selbst gefunden + +**AT-SPI-Umbau, Status: fertig und live verifiziert.** `autoclicker.sh` +klickt jetzt über die Linux-Barrierefreiheits-API (`python3-pyatspi`) +statt über Bildschirmkoordinaten/Enter-Taste: + +- `live-updates/usr/share/ubiquity/tuxflotte-atspi-env.sh` (neu, per + Ein-Zeilen-Sed-Patch in `start-ubiquity-dm` eingebunden, *vor* dem + GTK-Start von Ubiquity, da die Bruecke sich nachtraeglich nicht mehr + laden laesst): aktiviert `GTK_MODULES=gail:atk-bridge`, startet bei + Bedarf einen Session-Bus (`dbus-launch`) und `at-spi-bus-launcher`. +- `live-updates/opt/tuxflotte/scripts/atspi_click.py` (neu): findet den + zu klickenden Button ueber Rolle (`PUSH_BUTTON`) im Accessibility-Baum. + **Wichtig, real beim Testen entdeckt:** trotz festem + `debian-installer/language=de` ist nicht jede Seite deutsch beschriftet + - die Mint-eigene "Multimedia-Codecs"-Seite zeigt reale englische + Buttons ("Quit"/"Back"/"Continue"), vermutlich derselbe fehlende + .mo-Uebersetzungskatalog wie beim schon gepatchten + ubi-prepare.py-None-Bug (siehe oben). Eine anfaengliche reine deutsche + Werteliste blieb dort haengen. Umgestellt auf eine sprachunabhaengige + Strategie: bekannte rueckwaerts-/abbrechende Beschriftungen (zweisprachig) + werden ausgeschlossen, von den verbleibenden Kandidaten wird bevorzugt + wer eine bekannte vorwaerts-Beschriftung traegt, sonst der einzige + uebrige Kandidat (Sole-Survivor-Regel); bei echter Mehrdeutigkeit wird + bewusst NICHT geklickt. +- **Live-Beleg, dass AT-SPI selbst zuverlaessig funktioniert:** Log zeigt + 103 aufeinanderfolgende, korrekt erkannte Klicks auf "Jetzt + installieren" im 2-Sekunden-Takt, ueber mehrere Minuten, ohne einen + einzigen Fehlklick. Die Fenstergeometrie-/Dekorationsprobleme, an denen + der xdotool-Ansatz scheiterte, treten mit AT-SPI nicht mehr auf. + +**Nebenfund beim Testen, live gefixt:** der Kexec-Append in +`backend_launch()` setzte anders als der Grub-Eintrag des ersten Boots +kein `username=`/`hostname=` - dadurch verlangte der Live-Nutzer beim +zweiten (Kexec-)Boot ein echtes, unbekanntes Passwort statt des sonst +leeren Live-Session-Passworts (fuer den GTK-Assistenten selbst +folgenlos, erschwerte aber die Fehlersuche via Konsole unnoetig). Fix: +`username=mint hostname=mint` ergaenzt, Konsistenz zum ersten Boot +wiederhergestellt. + +### Neuer, tieferer Blocker (noch offen): `ubiquity/partman-rebuild-cache` +### fuehrt nach erfolgreichem Klick zurueck in die Partitionierung + +Mit funktionierendem AT-SPI-Klick wurde ein neues, von der Klick-Technik +unabhaengiges Problem sichtbar: der Klick auf "Jetzt installieren" auf der +manuellen Partitionierungsseite ("Etwas Anderes" - Ubiquity zeigt diese +Seite fuer jedes nicht eingebaute/custom `expert_recipe`, korrektes +Verhalten) wird tatsaechlich ausgefuehrt und fuehrt laut +`/var/log/installer/debug` nachweislich in den Erfolgspfad +(`grub-installer/bootdev seen` wurde erreicht - das passiert laut +Quelltext direkt nach `self.finish_partitioning = True; self.succeeded = +True; self.exit_ui_loops()`), aber kurz danach springt der Installer +zurueck in dieselbe Partitionierungsseite, und der Autoklicker beginnt +von vorn - ueber 100 Zyklen beobachtet, ohne jemals durchzukommen. + +Quelltext-Analyse (`/usr/lib/ubiquity/plugins/ubi-partman.py` auf dem +Live-Medium, per Konsole gelesen) zeigt die Ursache strukturell: + +```python +def rebuild_cache(self): + assert self.current_question == 'partman/choose_partition' + self.building_cache = True +``` + +aufgerufen, wann immer Debconf die Frage `ubiquity/partman-rebuild-cache` +stellt (Zeile ~2195: `if question == 'ubiquity/partman-rebuild-cache':`). +Diese Frage kommt von partmans eigenen Shell-Skripten (nicht von +ubi-partman.py selbst), noch nicht bis zur Quelle zurueckverfolgt, ob +partman sie hier zu Recht/wiederholt stellt oder ob unser eigenes +`expert_recipe` (insb. das `$reusemethod{ }`-Flag auf der ESP-Stanza, +siehe `_tuxflotte_render_partman_recipe()` - laut Code-Kommentar dort +bewusst aus der eingebauten "atomic"-Recipe uebernommen, weil ohne dieses +Flag die ESP frueher nicht als gueltig erkannt wurde) eine partman-interne +Neubewertung immer wieder auf "muss neu validiert werden" kippen laesst. + +**Wichtig fuer die weitere Suche:** dieser Loop ist strukturell derselbe +wie der oben (Fix 3) bereits dokumentierte `choose_partition`/ +`building_cache`-Loop, tritt hier aber nachweislich auch bei einem +tatsaechlichen, korrekten GTK-Klick auf (nicht nur bei direktem +Preseeden einer Debconf-Antwort ohne echten Seitenaufbau) - die Ursache +liegt also tiefer in partmans eigener Zustandsverwaltung bzw. in unserem +Rezept, nicht (nur) im Preseed-Mechanismus. + +**Status:** AT-SPI-Klick-Mechanismus als Aufgabe abgeschlossen und +verifiziert - die verbleibende Blockade ist ein eigenstaendiges, +partman-internes Problem, keine Klick-Zuverlaessigkeitsfrage mehr. +Naechste sinnvolle Schritte (nicht mehr in dieser Sitzung verfolgt): +(a) die partman-Shell-Skripte (nicht nur ubi-partman.py) daraufhin +durchsuchen, was `ubiquity/partman-rebuild-cache` stellt und ob es an +`$reusemethod{ }` auf einer frischen/leeren Platte haengt, oder (b) +pruefen, ob eine der eingebauten Recipes (z. B. "atomic" direkt statt +eines eigenen `expert_recipe`) fuer unsere Anforderungen ausreicht und +damit die manuelle "Etwas Anderes"-Seite (und ihre rebuild-cache- +Interaktion) ganz umgeht.