Adopt nixos-facter so host hardware facts are generated data, not a hand-written module #13

New issue

Open

opened 2026-07-28 00:58:14 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-28 00:58:14 +01:00

A machine's non-disk hardware facts currently arrive as a hand-maintained Nix module in the inventory data repo, so standing up a new host means running nixos-generate-config, stripping the filesystem entries by hand, and pasting the remainder into hosts/<name>/hardware.nix. Adopting nixos-facter turns that into generated data, which is what the inventory repo is for.

Primary goals:

Hardware facts become data, not code — a facter.json report under inventory/hosts/<name>/ instead of a hand-edited Nix module, matching the repo's role as the machine-facts owner.
Remove a manual step from host onboarding — nixos-anywhere --generate-hardware-config nixos-facter writes the report during install, so there is no generate-strip-paste round trip.
Follow the disko precedent exactly — module import in the framework, data in inventory, no new dependency in the data repo.
Keep it additive — nothing about the disk layout, the install invocation, or identity genesis changes.

Current state

mkHypervisor imports machines.${name}.hardware (flake.nix:250), which resolves to a hand-written module in the consumer's inventory. That module carries boot.initrd.availableKernelModules, boot.kernelModules, nixpkgs.hostPlatform, and CPU microcode/firmware settings. Since disko now owns disk topology, filesystem entries no longer belong there — but the file is still authored by hand from nixos-generate-config output with the filesystem parts deleted.

nixos-facter is not present anywhere in the stack: no input in archetypes, vm, nexus, or any data repo, and no hardware.facter.reportPath anywhere. So nixos-anywhere's --generate-hardware-config nixos-facter cannot currently be used against a host built by this framework.

Proposed shape

Structurally identical to the disko wiring in issue #12:

archetypes/flake.nix gains a nixos-facter-modules input and adds the module to mkHypervisor's list, alongside disko.nixosModules.disko.
The consumer's inventory carries hosts/<name>/facter.json plus hardware.facter.reportPath in the hardware module.
Hand-written boot.initrd.availableKernelModules and friends fall away for machines that adopt it.

Adoption should be per-machine rather than a flag day: a machine with a working hand-written module keeps it until someone has a reason to regenerate.

Why this is not urgent

The value is concentrated in machines whose hardware is not already known. For a host that is a hardware clone of an existing one, the existing machine's module list is empirically known-good — it boots — which is stronger evidence than fresh detection. Adopting facter during a first bare-metal validation would mean testing detection output at the same time as the disk layout and the install mechanism, with no way to attribute a failure.

Scope

In scope: the framework input and module wiring, the inventory-side data convention, and documenting the per-machine adoption path.

Out of scope: migrating existing machines, and any change to disk topology — that is disko's, and the two are independent.

A machine's non-disk hardware facts currently arrive as a hand-maintained Nix module in the inventory data repo, so standing up a new host means running `nixos-generate-config`, stripping the filesystem entries by hand, and pasting the remainder into `hosts/<name>/hardware.nix`. Adopting `nixos-facter` turns that into generated data, which is what the inventory repo is for. Primary goals: - **Hardware facts become data, not code** — a `facter.json` report under `inventory/hosts/<name>/` instead of a hand-edited Nix module, matching the repo's role as the machine-facts owner. - **Remove a manual step from host onboarding** — `nixos-anywhere --generate-hardware-config nixos-facter` writes the report during install, so there is no generate-strip-paste round trip. - **Follow the disko precedent exactly** — module import in the framework, data in inventory, no new dependency in the data repo. - **Keep it additive** — nothing about the disk layout, the install invocation, or identity genesis changes. ### Current state `mkHypervisor` imports `machines.${name}.hardware` (`flake.nix:250`), which resolves to a hand-written module in the consumer's inventory. That module carries `boot.initrd.availableKernelModules`, `boot.kernelModules`, `nixpkgs.hostPlatform`, and CPU microcode/firmware settings. Since disko now owns disk topology, filesystem entries no longer belong there — but the file is still authored by hand from `nixos-generate-config` output with the filesystem parts deleted. `nixos-facter` is not present anywhere in the stack: no input in `archetypes`, `vm`, `nexus`, or any data repo, and no `hardware.facter.reportPath` anywhere. So `nixos-anywhere`'s `--generate-hardware-config nixos-facter` cannot currently be used against a host built by this framework. ### Proposed shape Structurally identical to the disko wiring in issue #12: - `archetypes/flake.nix` gains a `nixos-facter-modules` input and adds the module to `mkHypervisor`'s list, alongside `disko.nixosModules.disko`. - The consumer's inventory carries `hosts/<name>/facter.json` plus `hardware.facter.reportPath` in the hardware module. - Hand-written `boot.initrd.availableKernelModules` and friends fall away for machines that adopt it. Adoption should be per-machine rather than a flag day: a machine with a working hand-written module keeps it until someone has a reason to regenerate. ### Why this is not urgent The value is concentrated in machines whose hardware is not already known. For a host that is a hardware clone of an existing one, the existing machine's module list is empirically known-good — it boots — which is stronger evidence than fresh detection. Adopting facter during a first bare-metal validation would mean testing detection output at the same time as the disk layout and the install mechanism, with no way to attribute a failure. ### Scope In scope: the framework input and module wiring, the inventory-side data convention, and documenting the per-machine adoption path. Out of scope: migrating existing machines, and any change to disk topology — that is disko's, and the two are independent.