Forge-less dev VM: first managed Pi provider does not reach the VM after rebuild #134

New issue

Closed

opened 2026-10-06 05:10:36 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-06 05:10:36 +01:00

On a deployment forked from the public template with no forge (dev VM forgeAccess = false, every repo host-provided), the first managed Pi provider does not reach the VM. Steps, all on the hypervisor:

pi-provider add nullsink --credential nullsink --url https://nullsink.is/v1 --target allod-dev --model glm-5-3-flash after mkdir -p secrets/secrets/pi-credentials (allod/nexus#80). It writes pi-providers.json in the profiles clone, pi-credentials.json and secrets/pi-credentials/nullsink/default.age in the secrets clone.
Commit both clones; nix flake update --refresh profiles secrets in the deploy clone, whose three data inputs are git+file:// URLs at those clones; commit the lock.
rebuild-vm allod-dev, which switches the VM and runs verify-vm.

Inside the VM afterwards, pi reports no models available and pi auth check --provider nullsink says not_ready. Observed on an earlier attempt, before the lock was refreshed: no ~/.pi/agent/models.json (the operator had removed a hand-written one), no /run/agenix directory at all, and the home-manager activation journal shows Activating piProviderLifecycle with no error line after it. The lock at that point still pinned the pre-add secrets commit, which explains that attempt; the symptom persists after the refresh, which is the open question.

To establish, in the VM: whether /run/agenix/pi-provider-token/nullsink/default exists, what ~/.local/state/allod/pi-provider-ownership.json and ~/.config/pi/credentials hold, what the reconciler logged in home-manager-<user>.service for this activation, and whether the VM's composed configuration declares the age.secrets entry at all (nix eval of the VM's config.age.secrets from the deploy clone on the host). On the host: that flake.lock pins the secrets commit that carries the ciphertext, and that nix eval <deploy>#nixosConfigurations.allod-dev.config.home-manager.users.<user>... sees the provider.

Found on the public install walk, running the managed provider path forge-less for the first time.

On a deployment forked from the public template with no forge (dev VM `forgeAccess = false`, every repo host-provided), the first managed Pi provider does not reach the VM. Steps, all on the hypervisor: 1. `pi-provider add nullsink --credential nullsink --url https://nullsink.is/v1 --target allod-dev --model glm-5-3-flash` after `mkdir -p secrets/secrets/pi-credentials` (allod/nexus#80). It writes `pi-providers.json` in the profiles clone, `pi-credentials.json` and `secrets/pi-credentials/nullsink/default.age` in the secrets clone. 2. Commit both clones; `nix flake update --refresh profiles secrets` in the deploy clone, whose three data inputs are `git+file://` URLs at those clones; commit the lock. 3. `rebuild-vm allod-dev`, which switches the VM and runs `verify-vm`. Inside the VM afterwards, `pi` reports no models available and `pi auth check --provider nullsink` says `not_ready`. Observed on an earlier attempt, before the lock was refreshed: no `~/.pi/agent/models.json` (the operator had removed a hand-written one), no `/run/agenix` directory at all, and the home-manager activation journal shows `Activating piProviderLifecycle` with no error line after it. The lock at that point still pinned the pre-add secrets commit, which explains that attempt; the symptom persists after the refresh, which is the open question. To establish, in the VM: whether `/run/agenix/pi-provider-token/nullsink/default` exists, what `~/.local/state/allod/pi-provider-ownership.json` and `~/.config/pi/credentials` hold, what the reconciler logged in `home-manager-<user>.service` for this activation, and whether the VM's composed configuration declares the `age.secrets` entry at all (`nix eval` of the VM's `config.age.secrets` from the deploy clone on the host). On the host: that `flake.lock` pins the secrets commit that carries the ciphertext, and that `nix eval <deploy>#nixosConfigurations.allod-dev.config.home-manager.users.<user>...` sees the provider. Found on the public install walk, running the managed provider path forge-less for the first time.

vnprc-agent commented

2026-10-06 05:28:32 +01:00

Author

Cause found by an agent run inside the VM: the profiles clone was never committed after pi-provider add, and nix flake update writes nothing while a git+file input is dirty yet exits 0, so the VM was rebuilt with no provider declared. After committing both clones and re-locking with --refresh, the rebuild delivered the credential: pi auth check ready, a request answered, no key file in the VM. Not a framework defect. The two silent no-ops are allod/nexus#82 (the tool prints the commit and re-lock lines and the check) and allod/deploy#9 (the script verifies its re-lock).

Cause found by an agent run inside the VM: the profiles clone was never committed after `pi-provider add`, and `nix flake update` writes nothing while a `git+file` input is dirty yet exits 0, so the VM was rebuilt with no provider declared. After committing both clones and re-locking with `--refresh`, the rebuild delivered the credential: `pi auth check` ready, a request answered, no key file in the VM. Not a framework defect. The two silent no-ops are allod/nexus#82 (the tool prints the commit and re-lock lines and the check) and allod/deploy#9 (the script verifies its re-lock).

vnprc-agent closed this issue

2026-10-06 05:28:32 +01:00