Root flake check fails on nixosConfigurations due to missing clan-core.clanModules

Issue Summary

Running nix flake check on the root flake fails with:

error: attribute 'clanModules' missing
at /home/user/code/modules/disko.nix:12:15:
    11| {
    12|   imports = [ clan-core.clanModules.disk-id ];

Background

clan-core input structure in the locked flake does not export clanModules.disk-id in the way referenced by modules/disko.nix.

Tasks

Review clan-core flake schema and determine whether disk-id moved to clanModules under another path or if clan-core needs an updated pin or module import.
Ensure root nix flake check or host evaluation passes cleanly.

Detailed error trace reveals upstream clan-core change:
Clan modules (clanModules) have been deprecated and removed in favor of Clan services! Refer to https://docs.clan.lol/guides/migrations/migrate-inventory-services for migration instructions.
Files affected in this repo:

modules/disko.nix (clan-core.clanModules.disk-id)
modules/shared.nix (clan-core.clanModules.{sshd, root-password, user-password, state-version})
Migration to Clan services is documented and can be executed as a dedicated migration task.

Migration audit (Clan Core pinned at 8b9fd720b385de3b6b923bc5cac4ccf3f99cc597, which no longer exports clanModules):

In modules/disko.nix, remove the legacy disk-id module lookup and use the existing disk ID 822c2b3a90814675aa45e433aa1fe59a as the layout suffix. Preserve the installed disk layout; Clan migration guidance warns against changing it.
In modules/shared.nix, remove legacy SSH/password module imports. Clan Core already provides state-version support (retain 25.05). Move SSHD and users behavior into inventory.instances using current sshd and users services, preserving the SSH key, groups, and UID. Set SSHD certificate support off if preserving current behavior; the new service enables certificates by default. Remove the old clan.user-password.user setting only as part of the users-service migration.
The users service makes users immutable and changes generated var names; verify existing installed password state before generating or deploying new vars.
Separately, programs.gvfs.enable appears to be an invalid option; this repo already notes the correct option is services.gvfs.enable.

References: https://clan.lol/docs/unstable/guides/migrations/disk-id ; https://clan.lol/docs/unstable/guides/migrations/migrate-inventory-services ; https://clan.lol/docs/unstable/services/official/users ; https://clan.lol/docs/unstable/services/official/sshd

I recommend keeping this issue open until the service migration is implemented and root machine/flake evaluation passes. A targeted eval attempt timed out during patched nixpkgs setup, so there is not yet post-migration validation.

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), Lane A shift
Session / ID: queue task 2009
Found via: queue claim · repo-health-code-pilot
Task: Triage Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159 — verify whether root flake check still fails on missing clan-core.clanModules at current main; route a scoped fix packet if confirmed, or close with evidence if gone.
Expectation: effort s — done = triage verdict posted, follow-up enqueued or issue closed with evidence, task 2009 completed.
Links: issue Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159

🤖 Agent note · done (triage verdict: CONFIRMED)

Agent: queue worker (repo-worker-code), Lane A shift
Session / ID: queue task 2009 (triage)
Found via: queue claim · repo-health-code-pilot
Task: Triage complete — CONFIRMED at current main, routed to a scoped fix packet (queue task 2943).
Evidence:
- Reproduced on the laptop at main 2953f274 (2026-10-29T00:58Z): nix eval .#nixosConfigurations.user.config.system.name fails with error: attribute 'clanModules' missing … while evaluating the attribute 'clanModules.disk-id' at modules/disko.nix:12:15 — the issue's exact error. The clan machine user reaches the root flake via lib/default.nix make-clan → nixosConfigurations; machines/user/configuration.nix:4,6 imports modules/disko.nix and modules/shared.nix.
- Scope is wider than the one line: modules/shared.nix:5,7,8,9 references clan-core.clanModules.{sshd,root-password,user-password,state-version} in the same machine path — fixing only disk-id surfaces the next missing attribute in the same evaluation.
- Locked clan-core rev 8b9fd720b385de3b6b923bc5cac4ccf3f99cc597 (flake.lock) exports no clanModules output at all: its flake.nix defines none and its tree has no clanModules path and no disk-id module — the old modules were replaced by clanServices/. Its own migration guide (docs/src/guides/migrations/disk-id.md) prescribes replacing clanModules.disk-id with a standalone static disko config using the machine's generated diskId (clan vars list user) — that value must come from the machine's vars, not be invented; the fix packet says so.
Expectation: fix task 2943 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:159) — done = nixosConfigurations.user evaluates cleanly, no clanModules refs left in modules/*.nix, CI green.
Links: follow-up task 2943 · upstream guide https://docs.clan.lol (migrations/disk-id, in-tree at locked rev)

🤖 Agent note · done (triage verdict: STILL CONFIRMED — prior fix task was cancelled on a false premise; replacement packet enqueued, task 2943 revived)

Agent: queue worker (repo-worker-code), lane E
Session / ID: queue task 5533 (fleet-monitor safety-net re-triage)
Found via: queue claim
Checked fresh 2026-11-01: Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159 OPEN; main c6bf933; task 2943 status history (Supabase reads)

Findings

The failure is still live at current main c6bf933. modules/disko.nix still contains imports = [ clan-core.clanModules.disk-id ]; and modules/shared.nix still imports clan-core.clanModules.{sshd, root-password, user-password, state-version} (verified via gh api contents at HEAD this shift). The locked clan-core exports no clanModules at all (triage 2009 evidence stands).
Why this issue sat ownerless: the fix routed by triage task 2009 — task 2943 — was cancelled with cancel_reason issue-closed, but Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159 was never closed (it is OPEN today). The cancellation's premise was false, and the monitor's reconciliation correctly caught the orphaned queue/queued label.
Route: a replacement fix packet (same scope as 2943, refreshed evidence, incl. the migration audit's recorded disk ID 822c2b3a90814675aa45e433aa1fe59a to be cross-checked against clan vars list user, never invented) was enqueued under the same dedupe key — task 2943 is live again, status queued, with the new packet. This issue's queue/queued label correctly mirrors it.
Task 5533 completes as triaged, follow_up_task_ids=[2943].

🤖 Agent note · escalated to Drew

Agent: queue worker (repo-worker-code), OpenChamber scheduled lane
Session / ID: queue task 2943
State: Blocked as escalated-to-user. Fresh GH state confirms PR fix(clan): migrate clan machine path off removed clanModules (#159) #3684 is OPEN and authored by Drew (dezren39), so the runbook prohibits modifying or merging it.
Finding: Codex P1 #4435696537 is valid and unresolved: PR fix(clan): migrate clan machine path off removed clanModules (#159) #3684 preserves the ZeroTier network ID but does not migrate the existing controller identity from the SOPS source into vars; generating a new identity would lose control of that network. The accepted reply #4435800273 confirms this blocker.
Drew decision/action: please resolve the identity migration (or choose the ZeroTier split-out alternative) on the owned PR and release/hand off ownership before a worker resumes. No branch or worktree was created and no secret value was accessed or copied.
Links: fix(clan): migrate clan machine path off removed clanModules (#159) #3684 (comment) · fix(clan): migrate clan machine path off removed clanModules (#159) #3684 (comment)

agent-note:v1
task: 5182 (triage, OpenChamber scheduled lane)
state: picked-up
checked_at: 2026-11-02T00:44:29Z

Agent: repo-worker-code
Session / ID: ses_e5e664d196effeXtKu9JvRgg6W
Found via: queue claim
Task: Revalidate safety-net triage for Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159 against current GitHub state; do not modify the existing PR.
Expectation: verify whether the failure remains live and route without duplicating or touching Drew-owned work.

agent-note:v1
task: 5182 (triage, OpenChamber scheduled lane)
state: blocked — escalated-to-user
checked_at: 2026-11-02T00:45:18Z

Verified Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159 remains open. Existing fix PR fix(clan): migrate clan machine path off removed clanModules (#159) #3684 is OPEN and authored by Drew (dezren39); this lane will not modify or merge it.
The existing task-2943 escalation identifies the unresolved Drew action: migrate the existing ZeroTier controller identity into vars or choose the split-out alternative, then release/hand off PR ownership.
Queue task 5182 blocked as escalated-to-user; resume only after that action/ownership handoff. No duplicate PR or code changes.

Merge pull request #3684 from developing-today/queue/2943-159-clanmod…

Navigation Menu

Repository navigation

Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159

Issue Summary

Background

Tasks

Findings

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Root flake check fails on nixosConfigurations due to missing clan-core.clanModules #159

Description

Issue Summary

Background

Tasks

Activity

dezren39 commented on Oct 12, 2026

dezren39 commented on Oct 12, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Nov 1, 2026

Findings

29 remaining items

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions