diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md
index 0f66a4f..c02def1 100644
--- a/adr/0009-anaconda-live-kickstart-verworfen.md
+++ b/adr/0009-anaconda-live-kickstart-verworfen.md
@@ -106,6 +106,19 @@ Da auch Versuch 3 identisch hängt, obwohl er gar kein WLAN mehr in der Dracut-v
 2. Ein anderes Fedora-Installationsmedium mit breiterer Treiberabdeckung testen (z.B. eine reguläre Fedora-Workstation-Netinstall/DVD-Variante, die ggf. großzügiger bestückt ist).
 3. Klären, welche WLAN-Chips die tatsächliche Pilotschul-Hardware mitbringt, bevor weiter am Treiberumfang gearbeitet wird — falls diese Hardware ohnehin andere Chips hat, wäre dieser konkrete Fund für die Praxis nicht blockierend.
 
+## Update (30.07.2026): Fedora-Server-DVD ebenfalls real getestet — hängt aus ungeklärtem Grund, unabhängig von Netzwerk
+
+Fedora-Server-**DVD** (nicht Netinstall, echtes Offline-Medium, siehe Präzisierung oben) real auf derselben Notebook-Hardware getestet, mit einem Kickstart ganz ohne `network`-Zeile (Hostname stattdessen per `hostnamectl` in `%post`, siehe „Wie kommen WLAN-Zugangsdaten ins installierte System"-Diskussion). Ergebnis: hängt an exakt derselben Stelle (`dracut-initqueue.service`, unbegrenzter Timer) wie die Netinstall-Versuche zuvor.
+
+Getestete Eingrenzungsschritte, in dieser Reihenfolge:
+1. `network --hostname=...` (kein WLAN) in der Kickstart-Datei → hängt.
+2. Gar keine `network`-Zeile mehr → hängt identisch.
+3. Notebook mit **gestecktem Ethernet-Kabel** neu gebootet → hängt weiterhin identisch.
+
+Schritt 3 ist der wichtigste Befund: Eine funktionierende Kabelverbindung sollte, falls die Ursache tatsächlich „wartet auf Netzwerk, findet aber nur ein WLAN ohne Treiber" wäre, das Problem auflösen. Da das nicht der Fall ist, ist die Ursache an dieser Stelle **nicht mehr eindeutig auf die bereits gefundene fehlende `iwlwifi`-Lücke zurückzuführen** — es könnte sich um eine andere, noch nicht diagnostizierte Ursache handeln (z. B. Stage2-Geräteerkennung für dieses konkrete Medium, oder etwas völlig anderes). Eine `rd.break=initqueue`-Sitzung mit vollem `journalctl`-Log wurde vorbereitet, aber die Untersuchung an dieser Stelle bewusst abgebrochen (Nutzer-Entscheidung, 30.07.2026) — nicht mangels Möglichkeit, sondern weil der Aufwand für Fedora an diesem Punkt als nicht mehr verhältnismäßig eingeschätzt wurde.
+
+**Konsequenz:** Fedora als Backend für die automatisierte Ersteinrichtung ist auf dieser konkreten Testhardware bislang in keiner geprüften Variante (Live+kexec, Netinstall, DVD) vollständig unbeaufsichtigt ans Ziel gekommen — bei klar unterschiedlichen, jeweils eigenständigen Ursachen (fehlendes Anaconda-Modul, fehlender `wpa_supplicant`, fehlender `iwlwifi`-Treiber, zuletzt ein noch ungeklärter Hänger auch mit Kabel). Naheliegender nächster Schritt, nicht mehr an dieser Stelle verfolgt: Ubuntu/Mint mit demselben Testaufbau (personalisierte ISO, Kickstart/Autoinstall auf dem Medium) probieren — andere Installer-Software (Subiquity/Ubiquity statt Anaconda), möglicherweise andere Treiberauswahl im jeweiligen Installer-Initrd.
+
 ## Ultima Ratio (konkretisiert 23.07.2026): personalisierte, vorentschiedene Installer-ISO
 
 Falls sich zeigt, dass sich der native Installer generell nicht zuverlässig aus einer Live-Sitzung heraus (auch nicht per Reboot mit dynamisch nachgeladener Konfiguration) automatisieren lässt, verschiebt dieser Weg die Workspace-/Backend-Entscheidung komplett **vor** den Boot-Vorgang, auf die zentrale Plattform: