admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Fedora Server DVD also stalls at dracut-initqueue, cause unclear

Browse Source 
Tested with no network line in the kickstart at all, then again with an
Ethernet cable plugged in -- still hangs identically, which rules out
the already-found missing iwlwifi driver as the sole explanation this
time. Investigation stopped here by user decision, not for lack of a
next diagnostic step (an rd.break=initqueue session was staged and
ready). Fedora has now failed in three independent, structurally
different ways (live+kexec, netinstall, DVD) on this test hardware --
Ubuntu/Mint with the same personalized-ISO test setup is the obvious
next candidate, not pursued in this session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Stallinger 2026-07-30 16:07:31 +02:00
parent 72e6fa7c2a
commit c35be45df8
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
adr/0009-anaconda-live-kickstart-verworfen.md
View File

@ -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: