rollout install script requires $HOME/hero/code/hero_skills/nutools on every user — none have it #29

Closed
opened 2026-05-25 06:49:10 +00:00 by zaelgohary · 0 comments
Member

Observation

The child install script generated by upgrade.run ends with:

nu -c 'use $env.HOME/hero/code/hero_skills/nutools/modules/services/mod.nu *; service_mycelium install --update --reset; service_mycelium start'

This path does not exist on any managed user account on herodev. The new bins are copied into ~/hero/bin/ successfully (the snapshot ships), but the post-copy supervisor refresh fails because nu cannot load the nutools modules — the install/start step exits 1.

This is the same root cause that #292 surfaces for the codescalers daemon. The user-side cleanup wasn't on that issue but has the same shape.

Repro

sudo curl -s --unix-socket /root/hero/var/sockets/hero_codescalers_server/rpc.sock -X POST http://localhost/rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"upgrade.run","params":{"dry_run":false},"id":1}'

Then for any managed user:

sudo -u <user> ls $HOME/hero/code/hero_skills/nutools/modules/services/mod.nu  # no such file

Affected today: every managed user that doesn't have a developer checkout (timur, nabil, atef, mahmoud, mik — and rawan/zainab which got the bins copied but the install/start failed for the same reason).

Suggested fix

Mirror the daemon-side fix from #27 in hero_codescalers:

  1. Lab side: lab should provision ~/hero/code/hero_skills/nutools/ (or just modules/) into every managed user's home as part of user create/user reset. The path is already used by lab's nu-modules installer (crates/lab/src/installers/nu.rs::install_nu_modules_into) — that runs against the template but not against per-user homes. Either: (a) clone the install into each user's home at provisioning, or (b) embed nutools in the lab binary and extract on demand.
  2. Codescalers side: the rollout install script could explicitly use the template's nutools (/home/template/hero/code/hero_skills/nutools/...) instead of $HOME-relative — but that's a workaround. The real fix is per-user provisioning.
## Observation The child install script generated by `upgrade.run` ends with: ```bash nu -c 'use $env.HOME/hero/code/hero_skills/nutools/modules/services/mod.nu *; service_mycelium install --update --reset; service_mycelium start' ``` This path does not exist on any managed user account on herodev. The new bins are copied into `~/hero/bin/` successfully (the snapshot ships), but the post-copy supervisor refresh fails because `nu` cannot load the nutools modules — the install/start step exits 1. This is the same root cause that #292 surfaces for the codescalers daemon. The user-side cleanup wasn't on that issue but has the same shape. ## Repro ``` sudo curl -s --unix-socket /root/hero/var/sockets/hero_codescalers_server/rpc.sock -X POST http://localhost/rpc \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"upgrade.run","params":{"dry_run":false},"id":1}' ``` Then for any managed user: ``` sudo -u <user> ls $HOME/hero/code/hero_skills/nutools/modules/services/mod.nu # no such file ``` Affected today: every managed user that doesn't have a developer checkout (timur, nabil, atef, mahmoud, mik — and rawan/zainab which got the bins copied but the install/start failed for the same reason). ## Suggested fix Mirror the daemon-side fix from #27 in `hero_codescalers`: 1. **Lab side**: lab should provision `~/hero/code/hero_skills/nutools/` (or just `modules/`) into every managed user's home as part of `user create`/`user reset`. The path is already used by lab's nu-modules installer (`crates/lab/src/installers/nu.rs::install_nu_modules_into`) — that runs against the template but not against per-user homes. Either: (a) clone the install into each user's home at provisioning, or (b) embed nutools in the lab binary and extract on demand. 2. **Codescalers side**: the rollout install script could explicitly use the template's nutools (`/home/template/hero/code/hero_skills/nutools/...`) instead of `$HOME`-relative — but that's a workaround. The real fix is per-user provisioning.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_codescalers#29
No description provided.