docs: base64-encode success_command to fix a silent debconf preseed failure

A long, multi-line, heavily-quoted ubiquity/success_command preseed
value produced no log output at all -- not even its first echo --
despite the same bash script running cleanly standalone (bash -n and
actual execution both clean). Root cause traced to debconf's preseed
line-continuation handling, not the script itself. Fix: base64-encode
the whole script and reduce success_command to a single short line
with no special characters (`in-target bash -c 'echo <b64> | base64
-d | bash'`). With that, WLAN connects via nmcli during install, curl
reaches anode, and the .nmconnection file lands correctly on the
target disk (verified pre-reboot via ubiquity/reboot boolean false).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Stallinger 2026-07-31 16:26:15 +02:00
parent 3721343ee2
commit 2c9223b452

View File

@ -172,3 +172,13 @@ Schritt 1 aus dem ursprünglichen Prüfplan ist geklärt: Linux Mint (Cinnamon)
**Beobachtung mit Konsequenz:** Nach dem Neustart ins fertig installierte System war die WLAN-Verbindung nicht mehr vorhanden, der Nutzer musste sich erneut verbinden. Wahrscheinliche Ursache: `in-target` chrootet zwar die Dateisystem-Sicht des Kommandos, aber `nmcli` sprach dabei vermutlich weiterhin mit dem laufenden NetworkManager-Dienst der **Live-Sitzung** (über den gemeinsam gemounteten `/run`), nicht mit einer Instanz, die für das Zielsystem persistent schreibt — das Verbindungsprofil landete dadurch im flüchtigen Live-Medium, nicht auf der installierten Platte. Für Persistenz muss die `.nmconnection`-Datei zusätzlich **direkt als Dateioperation** ins gechrootete `/etc/NetworkManager/system-connections/` geschrieben werden (dieselbe Technik, die für Fedora schon durchdacht, aber nie real getestet wurde) — reines `nmcli connect` reicht für die Installation selbst (bewiesen), aber nicht für Persistenz über den Reboot hinaus.
**Einordnung:** Das eröffnet für das Mint-Backend eine echte Alternative zum bisher erarbeiteten Modell (alles auf den Provisioning Agent nach dem ersten Boot verschieben) — Installationsvorgaben könnten dynamisch zur Installationszeit von `anode` geholt werden, statt vollständig vorab in die personalisierte ISO eingebacken zu sein. Ob das tatsächlich so umgesetzt wird, ist noch nicht entschieden, nur als real funktionierende Möglichkeit bestätigt.
### Nachtrag (31.07.2026): Persistenz-Fix real getestet — mit einer wichtigen Nebenerkenntnis zu Debconf-Preseed selbst
Der direkte Dateischreib-Ansatz aus dem Absatz oben wurde als eigener, mehrzeiliger `ubiquity/success_command`-Preseed-Wert getestet (Aufbau, Berechtigungen setzen, `.nmconnection`-Inhalt per `printf` schreiben) — Ergebnis: **kein Log, keine Datei**, obwohl derselbe Bash-Code lokal fehlerfrei lief (`bash -n`/tatsächliche Ausführung geprüft). Der komplette `success_command`-Aufruf wurde also offenbar nie ausgeführt, nicht einmal die erste `echo`-Zeile — ein reiner Bash-Syntaxfehler war damit ausgeschlossen, die Ursache lag also vermutlich an Debconfs Preseed-Zeilenverkettung selbst (viele verschachtelte Anführungszeichen/eckige Klammern über mehrere per `\` fortgesetzte Zeilen hinweg), nicht am Skriptinhalt.
**Fix:** Das komplette Skript Base64-kodiert, `success_command` reduziert auf eine einzige, kurze Zeile ohne jegliche Sonderzeichen: `in-target bash -c 'echo <base64> | base64 -d | bash'`. Damit lief alles fehlerfrei durch — WLAN verbindet sich per `nmcli` während der Installation, `curl` erreicht `anode`, und die `.nmconnection`-Datei landet korrekt (`600`, `root:root`, richtiger Inhalt) auf der Zielplatte unter `/target/etc/NetworkManager/system-connections/` (verifiziert vor dem Reboot, da `ubiquity/reboot boolean false` gesetzt wurde, um genau das zu prüfen, bevor die Live-Sitzung verschwindet).
**Für spätere `success_command`/`late_command`-Preseed-Werte festhalten:** lange, mehrzeilige, stark verschachtelte Preseed-Werte sind riskant und scheitern ohne hilfreiche Fehlermeldung — Base64-Kodierung des eigentlichen Skripts ist der robustere, empfohlene Weg, nicht nur ein Notbehelf für diesen einen Fall.
Ob die WLAN-Verbindung nach einem echten Reboot ins fertig installierte System jetzt automatisch (ohne erneute Passworteingabe) steht, ist der letzte noch ausstehende Prüfschritt.