TacidOS
Developers
Documentation

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

Status
Accepted
Date
2026-09-03

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 version prints 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.