Fetch the provisioning agent from git.tuxflotte.de, register it via
POST /api/v1/agent/bootstrap using the device id from the activation
response, write /etc/tuxflotte/agent.credentials, and enable the
tuxflotte-agent systemd service so it starts on first boot. Verified
end to end against a QEMU test VM and the real anode API.
The device id is now threaded through backend_generate_config() and
substituted into the kickstart template like the existing hostname
and blueprint values. %post drops the implicit chroot-wide set -e in
favor of per-step error handling, since localectl calls in this
section are known to fail best-effort without a running D-Bus.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same offline-install idea as wlan-netinst-test.cfg but on a genuine
DVD/Everything-style medium instead of netinstall, to sidestep the
network dependency during %packages. Ended up hanging at
dracut-initqueue for a reason that turned out to be independent of the
network line entirely (confirmed by testing with no network directive
at all, then with a physical Ethernet cable plugged in) -- see the
30.07.2026 ADR-0009 update for the full account.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Not part of the backend lifecycle (40_backend.sh) -- run by hand during
the live/netinstall boot flow investigation documented in ADR-0009.
kexec-reboot-test.sh/.cfg: tests whether inst.ks= can trigger Anaconda
via kexec from within the running Fedora Cinnamon live session, without
a real firmware reboot. Conclusively fails: the live initrd has no
anaconda dracut module at all.
wlan-netinst-test.cfg: the kickstart used to validate inst.ks=cdrom:/ks.cfg
on a real Fedora netinstall ISO, including the failed WLAN activation
attempts (network --wpakey=, then %pre nmcli) that exposed the missing
iwlwifi driver in that image's initrd.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
These are run as standalone subprocesses via run_module()/source, which
requires the execute bit. Missing since their initial creation - only
noticed because manually chmod'd copies were used for testing on anode,
never the checked-in files. Would have failed on a fresh checkout.
30_runtime_blueprint.sh calls POST /templates/{id}/resolve with the
device_id from the server handshake and the template_id from the
Bereitstellungsvorlage selection, storing the resulting Runtime
Blueprint under /run/tuxflotte/runtime/.
40_backend.sh dispatches to backends/${backend_id}/backend.sh based on
the resolved backend_id and drives the backend_init/validate/
generate_config/launch/postinstall lifecycle from 06-backend-api.md.
backends/fedora/backend.sh implements that lifecycle for Fedora:
backend_generate_config() renders kickstart.tpl via envsubst using the
Runtime Blueprint's installation_directives and the device hostname,
embedding the resolved Merkmal blueprints as JSON for the (not yet
implemented) Provisioning Agent to apply later. Replaces the old
git-clone-based %post bootstrap. backend_launch()/backend_postinstall()
are Phase 1 stubs pending the live-ISO boot integration (see
platform-docs ADR-0003).
