Decision 0022
Netinstall and offline ISOs; the installer is Tacid in genesis mode
Architecture decision record 0022: Netinstall and offline ISOs; the installer is Tacid in genesis mode
Context
“We have an ISO that you can use to install, then the system is self-improving.” The ISO must be small enough to download and complete enough to work with no network; those two do not coexist in one file (review).
The three plans
- Grok: a TUI installer with five questions; the core ISO under 800 MB without weights; models as a second artifact; USB model packs.
- Fable:
mkIso; a TUI installer;nixos-anywhere; “Tacid on top of your existing NixOS”. - Codex: build the installer late; a ten-step branded flow; GPU detection; AI setup; first boot that feels finished.
Decision
Two artifacts: netinstall (≤ ~1 GB: kernel, daemons, TUI, no graphical closure, no weights)
and offline (several GB: a graphical machine already built, in the store on the medium, so an
install with no network copies rather than compiles). The offline image was also to carry the
tiny model so that the first boot of a machine with no network is not mute; that is deferred
until there is a verified hash for one in models/registry.toml, and the section below says so
rather than this line quietly claiming it. USB model packs for airgapped sites. x86_64 only: the
medium carries a built machine, and a machine is built for an architecture — an aarch64 offline
image needs an aarch64 reference system to carry, which is a build the project does not yet run. The installer is not separate code: the stem, the
keeper and tacidd run in genesis mode on the live system, driven by the TUI over the console
or a serial line; disk operations are typed stem operations on a previewed disko plan; the output
is the first genome and generation. Flow: keyboard and language, network (optional), disk, encryption
(TPM2 + PIN, recovery key), owner key and user, hardware profile with the NVIDIA choice, autonomy
level, mind (local profile sized to hardware; optional cloud key into the keeper), review, install.
Secure Boot enrollment is a post-install command. First boot: the agent introduces itself,
verifies hardware against facts, offers models. Also nixos-anywhere and
inputs.tacidos.nixosModules.default on an existing NixOS. The ISO lands in Phase 3, after the
spine and the senses and before the graphical shell, because a self-updating TUI machine is a
complete product.
Consequences
- No special-case installer code to secure; genesis is a transaction.
tacid versionprints full provenance from the first boot.
Alternatives rejected
- One ISO: either too large to download or mute offline.
- Building the installer first (against Codex’s advice, which stands): the spine comes first.
What evaluating both images found
The offline image was the netinstall image under a second name. Not approximately: the same
system.build.toplevel derivation, byte for byte. Its three settings — redistributable firmware,
iwd, no NetworkManager — were all already made, two by installer/live.nix and one by the
installation profile every live medium imports, so the file read as though it did something and
did nothing. Only the name on the ISO and the squashfs compression level differed, and a person
who downloaded tacid-offline.iso for a machine with no network would have got exactly the medium
they were told not to use.
Nothing caught it because nothing looked. Continuous integration evaluated the flake’s packages
and checks and built the reference machine; the images were in nixosConfigurations and no job
named them. The job now forces every output on both architectures to a derivation — and for a
live image it takes the medium rather than the system, because the medium is the artifact and
because taking the system is precisely what said these two were the same thing.
The image now carries what makes it offline: isoImage.storeContents with the reference
workstation’s toplevel, so the store on the medium holds a built graphical machine. An install
with no network copies paths instead of compiling Mesa on a laptop. It is not the machine that
gets installed — the installer writes body/ for the hardware in front of it, and that system is
its own — but everything underneath is shared, and what is shared is nearly all of it.
The tiny model this image was also meant to carry still is not on it: that waits on a verified
hash in models/registry.toml, and carrying an unchecked mind would be a worse answer than the
wait. The medium is evaluated in continuous integration and has not been built; Phase 3 keeps the
acceptance open until an offline install runs from one that has.