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>
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>
After three independent, structurally different dead ends on the same
test hardware (missing anaconda dracut module, missing wpa_supplicant,
missing iwlwifi, an unexplained DVD hang that persisted even with
Ethernet plugged in), the user decided to move on from Fedora rather
than keep debugging. Not a verdict against Fedora as a backend in
general -- specific to this test hardware and these official media.
The architecture worked out in this ADR (personalized ISO, no network
directives during install, Provisioning Agent handles WLAN/handshake
on first boot) carries over unchanged to Mint/Ubuntu; only the
installer stack changes (Subiquity/autoinstall or Ubiquity/preseed
instead of Anaconda/kickstart).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Real hardware test (Intel AX210) shows the tested Fedora Everything
netinstall initrd ships no iwlwifi driver at all -- three kickstart
variants all hung identically at dracut-initqueue regardless of syntax,
confirming the cause was never the kickstart itself. Documents the
kexec test series (ADR-0009), the DB-driven kickstart success on
netinstall, and the resulting architecture: a personalized installer
ISO per workspace/backend/media-variant with the kickstart baked in,
no live-session/kexec transition, WLAN and blueprint application moved
to the Provisioning Agent's first boot on the fully installed target
system instead of the constrained installer environment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Instead of customers flashing a different physical stick per workspace/
distro combination, one slim generic bootstrap medium (no live desktop
needed) stages the server-built personalized distro ISO into a small
partition on the target disk and boots it directly via GRUB loopback/
iso-scan (the same pattern Ventoy uses in production). The staging
partition is deliberately ephemeral - the real install's own
partitioning step wipes it along with the rest of the disk, keeping
Tuxflotte's own disk-touching code to a throwaway staging area only,
clearly inside the boundary already drawn against reimplementing the
actual install logic.
Also records the assessment that this is a genuine architectural
simplification, not just an Anaconda-specific workaround: it removes
the entire class of live-desktop/EROFS friction from recent days and
fits the project's own "orchestrate native installers" philosophy
better than the live-kiosk approach did.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the vague "separate netinstall media" fallback with a
concrete design: move the workspace/backend decision to the
self-service portal, before boot, and bake the finished kickstart/
autoinstall/preseed config into a personalized, distro-specific,
much smaller installer ISO at build time. Sidesteps the live-session
vs. native-installer-automation tension entirely, and the open
early-boot networking question from the two-stage-reboot plan, since
no runtime config fetch is needed. Consistent with backend_postinstall()
already being scoped to the installed system's first boot, not the
install phase.
Names the real cost honestly: demotes the interactive kiosk mode to
an optional secondary path, and requires real per-distro ISO-build
infrastructure server-side.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Further research showed the live-session-invocation limitation isn't
Fedora-specific: Ubuntu/Subiquity autoinstall and Ubiquity/preseed are
also strictly kernel-boot-parameter-triggered, and Calamares has no
unattended mode at all regardless of timing. Rather than switching
distros, the live session can instead set the right boot parameter
for a second boot and reboot into the installer's normal automated
mode - potentially avoiding a Fedora/Anaconda departure entirely.
Records the agreed test order: confirm Mint's actual installer,
test Fedora+kickstart-via-reboot first (lowest cost), then Mint/Ubuntu
with the same pattern, with the original ADR-0009 ultima ratio last.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Real test on Fedora 44 / Anaconda 44.30-2.fc44 (bypassing the liveinst
wrapper, which explicitly rejects kickstart on live media) confirmed
the documented restriction firsthand rather than just by reading
about it: --liveinst --kickstart in text mode silently drops rootpw/
user directives (require full manual re-entry, no error), and cmdline
mode exits cleanly with CmdlineError naming Installation Destination,
Root password, and User creation as unfinished despite being fully
specified in the kickstart.
Reimplementing install logic to bypass Anaconda entirely was
considered and explicitly rejected. Next step is re-evaluating
Ubuntu/Debian-based installer media instead of Anaconda's live mode;
switching Fedora to the officially supported inst.ks=/liveimg pattern
(separate netinstall media) remains a last resort.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
