Skip to content

nix flake check aborts at nixosConfigurations.client, so the checks output is never reached #455

Closed

Description

@mecattaf

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.drv
  • nix 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

  1. mecattaf commented on Sep 22, 2026

    @mecattaf
    OwnerAuthor

    Correction and an update from the same run, a few minutes after filing this.

    The nixosConfigurations.client abort did not reproduce. Two further
    nix flake check --no-build runs on the ax/package branch both got PAST
    nixosConfigurations.client without error and reached the checks output:
    grep -c "checking derivation checks" is 21 on the first and 26 on the
    second, 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 .drv or a
    source 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 check got that far,
    each one on a different run, each stopping the gate in a different place:

    checking derivation checks.x86_64-linux.nas-personal-tailnet...
    error: path 'pl6rmijq3dkwqw9cf16wzpycsc7gb9m2-86byf0qaz7f0vgj7x4km4zc9q446skd0-source' is not valid
    

    That one did not reproduce either: nix eval .#checks.x86_64-linux.nas-personal-tailnet.drvPath
    is 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-topology over the coordinator's firewall, which is
    pre-existing on main and is now filed separately as #457.

    The practical consequence, unchanged: nix flake check is this repository's
    only 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 #457
    are both needed before a green nix flake check means anything.

    All of the above MEASURED 2026-09-23 on the coordinator, from
    /home/tom/overnight-tuesday/wt/dotfiles on branch ax/package.

  2. mecattaf commented on Sep 23, 2026

    @mecattaf
    OwnerAuthor

    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 of
    mecattaf/dotfiles at /home/tom/overnight-tuesday/wt/dotfiles-fc, branch off
    origin/main at f8e27b432fd1d41887c79f2f39ea83b9de93e5e6 (the same sha this issue names),
    working tree clean, on the same host.

    1. The client abort is gone

    checking NixOS configuration 'nixosConfigurations.client'...
    checking flake output 'deploy'...
    

    grep -c "is not valid" over the run's log: 0. The run continued past
    nixosConfigurations and reached the checks output:

    grep -c "checking derivation checks" p0-flake-check.log
    24
    

    This issue measured that count as 0. It is now 24, with no change to the tree.

    2. Why: the .drv is valid in this store again

    $ nix path-info /nix/store/61p9hcv46vjy4isl01f36a3g7bczrkzc-source.drv
    /nix/store/61p9hcv46vjy4isl01f36a3g7bczrkzc-source.drv          rc 0
    

    The issue records that this .drv did not exist in the store. It does now. Its output
    is still unbuilt, which is expected under --no-build:

    $ nix path-info /nix/store/61p9hcv46vjy4isl01f36a3g7bczrkzc-source
    error: path '/nix/store/61p9hcv46vjy4isl01f36a3g7bczrkzc-source' is not valid   rc 1
    

    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.storePath suspect is refuted

    nix derivation show on the named path identifies it:

    "name": "source", "owner": "PegasisForever", "repo": "zenbook-duo-daemon",
    "rev": "7955be868aba807b02ec748c02ab537aabec3ada",
    "urls": ["https://github.com/PegasisForever/zenbook-duo-daemon/archive/7955be....tar.gz"]
    

    That is the fetchFromGitHub src of pkgs/zenbook-duo-daemon.nix:23-25, a client-only
    package (hosts/client/default.nix:259). It has no relationship to the
    builtins.storePath pair at pkgs/local-ai-monthly/stages.nix:14-15. That pair can be
    struck off the list. MEASURED.

    Why a fixed-output fetch whose .drv was absent produced path ... is not valid inside
    nix flake check but not inside nix eval ...drvPath is INFERRED and untested: the
    flake evaluation cache memoises drvPaths, so a cached path whose .drv was collected is
    reported invalid rather than re-instantiated. Not measured here, and not chased.

    4. nix flake check --no-build is still rc 1, for a different and unrelated reason

    The run now aborts in the checks output:

    … while checking the derivation 'checks.x86_64-linux.nas-topology'
        at flake.nix:1559:9
    error: assertion '(! ((builtins).elem 8731 (coordinator).networking.firewall.interfaces.wlp192s0.allowedTCPPorts))' failed
        at flake.nix:1694:11
    

    MEASURED:

    $ nix eval --json .#nixosConfigurations.coordinator.config.networking.firewall.interfaces.wlp192s0.allowedTCPPorts
    [80,443,8731]          rc 0
    

    flake.nix:1694 asserts 8731 is absent from the coordinator's LAN leg, with the
    comment "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.log beside it.

  3. mecattaf commented on Sep 23, 2026

    @mecattaf
    OwnerAuthor

    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-build reached "all checks passed!" rc 0 on main 7d4704db and e1a8a1db in the normal store (MEASURED); the fresh-empty-store rc 0 was measured on 204c96a0 (REPORTED, evals track-dotfiles-green). Left open for Tom to confirm and close.

  4. mecattaf commented on Oct 13, 2026

    @mecattaf
    OwnerAuthor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions