Repository navigation
nix flake check aborts at nixosConfigurations.client, so the checks output is never reached #455
Description
nix flake check --no-build does not reach the checks output on this repository. It
aborts while checking nixosConfigurations.client. MEASURED 2026-09-22 on pristine
origin/main at f8e27b432fd1d41887c79f2f39ea83b9de93e5e6, and byte-identically on the
ax/package branch, so it is pre-existing and is not any branch's bug.
The gate for this repository is nix flake check locally (there are no GitHub Actions),
so while this abort stands, no checks.${system} entry is exercised by the gate at all.
grep -c "checking derivation checks" over the run's log is 0. Every per-feature
topology check currently has to be built by hand, one at a time, with
nix build --no-link .#checks.x86_64-linux.<name>.
The exact error
checking flake output 'nixosConfigurations'...
checking NixOS configuration 'nixosConfigurations.coordinator'...
checking NixOS configuration 'nixosConfigurations.nas'...
checking NixOS configuration 'nixosConfigurations.worker'...
checking NixOS configuration 'nixosConfigurations.client'...
error:
… while checking flake output 'nixosConfigurations'
at /home/tom/overnight-tuesday/wt/dotfiles/flake.nix:599:7
… while checking the NixOS configuration 'nixosConfigurations.client'
… while evaluating the option `system.build.toplevel':
… while evaluating the option `warnings':
… while evaluating the option `systemd.services.mandb.serviceConfig':
… while evaluating the option `systemd.services.mandb.script':
… while evaluating the option `documentation.man.man-db.manualPages':
error: path '61p9hcv46vjy4isl01f36a3g7bczrkzc-source.drv' is not valid
rc=1
Two eliminations, so nobody repeats them
Both MEASURED, both rc 0, both outside nix flake check:
nix eval .#nixosConfigurations.client.config.documentation.man.man-db.manualPages.drvPath
->/nix/store/qzsl8k9dkby9wizdw11hh8yna5r3sjqb-man-paths.drvnix eval .#nixosConfigurations.client.config.system.build.toplevel.drvPath
So the client's whole toplevel instantiates fine on its own. The failure is specific to
what nix flake check does on top of evaluation, not to evaluating the client.
The named suspect, INFERRED and not confirmed
61p9hcv46vjy4isl01f36a3g7bczrkzc-source.drv does not exist in the store, and neither
does its output path. A .drv that is "not valid" and that is not rebuilt is the
signature of a garbage-collected builtins.storePath reference. The only
builtins.storePath pair in the tree is pkgs/local-ai-monthly/stages.nix:14-15
(bash, pureStage).
That is a hypothesis. It was not confirmed and the root cause was not chased to a named
package. Anyone picking this up should start by confirming or eliminating that pair.
Provenance
Found by the 2026-09-22/23 overnight run, item 10 (ax-package-dotfiles-pr), receipt
section 5, and filed from item 17 (ax-conwip-dotfiles-module) so the fix becomes
durable. Neither item's changes cause it and neither item fixed it.
Activity
home/ax-conwip: a CONWIP scheduler user service, declared and OFF
mecattaf commentedon Sep 22, 2026
Correction and an update from the same run, a few minutes after filing this.
The
nixosConfigurations.clientabort did not reproduce. Two furthernix flake check --no-buildruns on theax/packagebranch both got PASTnixosConfigurations.clientwithout error and reached thechecksoutput:grep -c "checking derivation checks"is 21 on the first and 26 on thesecond, where it was 0 on the run this issue quotes. Nothing in the tree
changed between the failing run and the passing ones that touches the client.
So the abort is store state, not tree state, which upgrades the hypothesis at
the bottom of this issue from a guess to the most likely reading: a
.drvor asource path that is "not valid" and that is not rebuilt is a reference to
something the garbage collector took. The title of this issue is still right, but
the reproduction is intermittent and depends on what is in the store at the
moment you run it. Anyone trying to reproduce it should expect to have to GC
first, and should not conclude it is fixed because one run got through.
Two more failures of the same class appeared once
flake checkgot that far,each one on a different run, each stopping the gate in a different place:
That one did not reproduce either:
nix eval .#checks.x86_64-linux.nas-personal-tailnet.drvPathis rc 0 and the next full run walked past it.
The run after that reached a failure of a different and real kind, an
assertion in
checks.nas-topologyover the coordinator's firewall, which ispre-existing on
mainand is now filed separately as #457.The practical consequence, unchanged:
nix flake checkis this repository'sonly gate, there are no GitHub Actions, and it does not currently reach a verdict
reliably. Per-feature topology checks still have to be built one at a time with
nix build --no-link .#checks.x86_64-linux.<name>. Fixing this issue and #457are both needed before a green
nix flake checkmeans anything.All of the above MEASURED 2026-09-23 on the coordinator, from
/home/tom/overnight-tuesday/wt/dotfileson branchax/package.mecattaf commentedon Sep 23, 2026
This no longer reproduces, and the named suspect is refuted
MEASURED 2026-09-23, overnight item 28 (
dotfiles-flake-check-fix), in a fresh clone ofmecattaf/dotfilesat/home/tom/overnight-tuesday/wt/dotfiles-fc, branch offorigin/mainatf8e27b432fd1d41887c79f2f39ea83b9de93e5e6(the same sha this issue names),working tree clean, on the same host.
1. The client abort is gone
grep -c "is not valid"over the run's log: 0. The run continued pastnixosConfigurationsand reached thechecksoutput:This issue measured that count as 0. It is now 24, with no change to the tree.
2. Why: the
.drvis valid in this store againThe issue records that this
.drvdid not exist in the store. It does now. Its outputis still unbuilt, which is expected under
--no-build:So the abort was a store-state condition on this host, not a defect in the tree.
Nothing in the repository was changed to make it go away.
3. The
builtins.storePathsuspect is refutednix derivation showon the named path identifies it:That is the
fetchFromGitHubsrc ofpkgs/zenbook-duo-daemon.nix:23-25, a client-onlypackage (
hosts/client/default.nix:259). It has no relationship to thebuiltins.storePathpair atpkgs/local-ai-monthly/stages.nix:14-15. That pair can bestruck off the list. MEASURED.
Why a fixed-output fetch whose
.drvwas absent producedpath ... is not validinsidenix flake checkbut not insidenix eval ...drvPathis INFERRED and untested: theflake evaluation cache memoises drvPaths, so a cached path whose
.drvwas collected isreported invalid rather than re-instantiated. Not measured here, and not chased.
4.
nix flake check --no-buildis still rc 1, for a different and unrelated reasonThe run now aborts in the
checksoutput:MEASURED:
flake.nix:1694asserts 8731 is absent from the coordinator's LAN leg, with thecomment "The coordinator serves no model: no inference door on its LAN leg." The
coordinator's configuration now opens it. Whether the port or the assertion is the thing
that is wrong is a configuration question, not a flake-check repair, so item 28 did not
touch it and opened no pull request.
Receipt:
/home/tom/overnight-tuesday/receipts/dotfiles-flake-check-fix/RECEIPT.md.Full log:
p0-flake-check.logbeside it.mecattaf commentedon Sep 23, 2026
Status (overnight run 09-23): the DF-5 commit
7d72c5d4(vendored zenbook-duo-daemon Cargo.lock,pkgs.path + ...in tests/tailscale-personal) landed on main with #466.nix flake check --no-buildreached "all checks passed!" rc 0 on main7d4704dbande1a8a1dbin the normal store (MEASURED); the fresh-empty-store rc 0 was measured on204c96a0(REPORTED, evals track-dotfiles-green). Left open for Tom to confirm and close.mecattaf commentedon Oct 13, 2026
Done in 7d72c5d (2026-09-23): nix flake check reaches the checks output. It is red today only for #522, fixed by PR #546. Closed on Tom's ruling, 2026-10-13: "close".
🤖 Generated with Claude Code