From 3721343ee2a47597b2f33cd9aa6e9407baf053e0 Mon Sep 17 00:00:00 2001
From: Thomas Stallinger <stallinger@gmx.de>
Date: Fri, 31 Jul 2026 15:16:39 +0200
Subject: [PATCH] =?UTF-8?q?docs:=20Mint/Ubiquity=20confirmed=20working=20?=
 =?UTF-8?q?=E2=80=94=20real=20WLAN=20and=20live=20anode=20contact=20during?=
 =?UTF-8?q?=20install?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

First real success in this whole investigation: Ubiquity's automatic
mode still boots via boot=casper, the same live environment as the
normal interactive session, so it doesn't share Fedora's
installer-vs-live driver split. No hidden second FAT/ESP grub.cfg copy
either, unlike Fedora. Real test on the same notebook (Intel AX210)
connected WLAN via nmcli in ubiquity/success_command and got a genuine
response from anode's /health endpoint during installation.

One follow-up finding: the WLAN connection didn't survive the reboot
into the installed system, likely because nmcli talked to the live
session's own NetworkManager instance (shared /run under chroot)
rather than writing a profile that persists on the target disk --
needs an explicit file write into the chrooted
/etc/NetworkManager/system-connections/ instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 adr/0009-anaconda-live-kickstart-verworfen.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md
index c3a3a7b..ced4502 100644
--- a/adr/0009-anaconda-live-kickstart-verworfen.md
+++ b/adr/0009-anaconda-live-kickstart-verworfen.md
@@ -160,3 +160,15 @@ Das ist keine Entscheidung gegen Fedora als Backend grundsätzlich — die Fedor
 **Für die Fortsetzung mit Mint/Ubuntu gilt dasselbe, in diesem ADR erarbeitete Architekturmodell** (personalisierte ISO pro Workspace/Backend/Medienvariante, Kickstart/Autoinstall bereits eingebacken, `network`-Direktiven im Installationsschritt selbst vermeiden, Provisioning Agent übernimmt WLAN/Handshake/Blueprint-Anwendung beim ersten Boot des fertig installierten Systems) — nur mit Ubuntus/Mints eigenem Installer-Stack (Subiquity/Autoinstall oder Ubiquity/Preseed, siehe Prüfplan weiter oben, Schritt 1 „welchen Installer bringt Mint mit" ist damit jetzt wieder relevant und weiterhin ungeklärt) statt Anaconda/Kickstart.
 
 **Nächster Schritt:** dasselbe empirische Vorgehen wie hier für Fedora — realer Test auf derselben Notebook-Hardware, sobald der Nutzer bereit ist weiterzumachen. Nicht proaktiv fortsetzen, ohne dass der Nutzer das wieder aufgreift.
+
+## Update (31.07.2026): Mint/Ubiquity real getestet — WLAN und Live-Kontakt zu anode funktionieren während der Installation
+
+Schritt 1 aus dem ursprünglichen Prüfplan ist geklärt: Linux Mint (Cinnamon) nutzt **Ubiquity** (nicht Subiquity, das ist Ubuntu-Server-spezifisch), mit klassischem Debian-Installer-Preseed-Format (`d-i <template> <type> <wert>`). Automatisierter Modus über den Kernel-Parameter `automatic-ubiquity` zusammen mit `file=/cdrom/preseed/<datei>.seed` (Preseed-Datei direkt auf dem Medium, analog zu Fedoras `inst.ks=cdrom:/ks.cfg`).
+
+**Struktureller Unterschied zu Fedora, der sich als entscheidend herausstellte:** Ubiquitys automatisierter Modus bootet weiterhin über `boot=casper` — dasselbe Live-Environment wie die normale interaktive Live-Sitzung, kein separates, abgespecktes Installer-Environment wie Anacondas Netinstall/DVD-Stage2. Damit entfällt die Fedora-typische Treiberlücke von vornherein: Das Boot-Medium (`linuxmint-22.3-cinnamon-64bit.iso`) hat außerdem keine versteckte zweite FAT-ESP-Partition mit eigenem `grub.cfg` — `/boot/grub/grub.cfg` im ISO9660-Baum ist die einzige, tatsächlich gelesene Konfigurationsdatei, kein Analogon zu Fedoras `BOOT.conf`-Falle.
+
+**Realer Test:** Preseed-Datei mit `ubiquity/success_command` (läuft `in-target`/chrooted, nach Paketinstallation, vor Neustart) — der Befehl führt `nmcli device wifi connect stallinux password ...` aus und ruft danach `https://anode.tuxflotte.de/health` per `curl` auf. Ergebnis: WLAN verbindet sich erfolgreich (`wlp9s0` → `connected`, echter Intel-AX210-Chip auf derselben Testhardware, die bei Fedora gar kein Interface fand), und `curl` liefert eine echte Antwort vom Provisioning-Server zurück (`{"status":"ok","service":"provisioning-server","version":"0.1.0"}`). Damit ist zum ersten Mal in dieser gesamten Untersuchung ein **echter, funktionierender Live-Kontakt zur Plattform während der Installation** demonstriert — nicht nur eine post-install Möglichkeit.
+
+**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.