diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-05 19:48:10 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-05 19:48:10 +0200 |
| commit | fff1974edf19cf1186e0f49da5f8a4d237bcb13e (patch) | |
| tree | 3c623c6253cd005773546b207f4749e98151a7b5 /packaging/win | |
| parent | 5b4c4df56bcc795be6a8416987e2d91f91ea14ba (diff) | |
| download | meshbay-fff1974edf19cf1186e0f49da5f8a4d237bcb13e.tar.gz | |
fix(win): finish the desktop setup flow — node-key link + service task
Two independent breaks in the Windows first-run path:
- node:start's win32 branch never linked the node's Ed25519 key to the hub
account, so the daemon sat at waiting_for_account and the Create Group
wizard span on "Detecting local node…" for ever — the only way through
was pasting the key by hand on the Profile page. The Linux branch has
always done this inline; factor it into linkNodeKeyAndAwaitRunning() and
call it from win32 too. PUT /v1/users/me/node_key overwrites, so this
also recovers an account still carrying a previous machine's node key.
- service.ps1's install branch did `$action = New-ScheduledTaskAction`,
shadowing its own [ValidateSet(...)][string]$Action parameter (PowerShell
variable names are case-insensitive). The CimInstance was coerced to the
string "MSFT_TaskExecAction", Register-ScheduledTask -Action rejected it,
and "background service" mode never created the task — reproduced live.
Rename the locals to $taskAction / $bootTrigger / $taskPrincipal.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Diffstat (limited to 'packaging/win')
| -rw-r--r-- | packaging/win/service.ps1 | 17 |
1 files changed, 12 insertions, 5 deletions
diff --git a/packaging/win/service.ps1 b/packaging/win/service.ps1 index 29a02fe..1f84a29 100644 --- a/packaging/win/service.ps1 +++ b/packaging/win/service.ps1 @@ -68,11 +68,18 @@ switch ($Action) { "install" { if (-not (Test-Path $node)) { throw "meshbay-node.exe not found at $node" } $user = Get-CurrentUser - $action = New-ScheduledTaskAction -Execute $node - $trigger = New-ScheduledTaskTrigger -AtStartup - $principal = New-ScheduledTaskPrincipal -UserId $user -LogonType S4U -RunLevel Limited - Register-ScheduledTask -TaskName $TASK_NAME -Action $action -Trigger $trigger ` - -Principal $principal -Force -ErrorAction Stop | Out-Null + # NOT $action: PowerShell variable names are case-insensitive, so $action + # is this script's own [ValidateSet("install",...)][string]$Action + # parameter. Assigning the New-ScheduledTaskAction CimInstance to it + # runs the ValidateSet check (fails) and coerces the object to the + # string "MSFT_TaskExecAction", which Register-ScheduledTask -Action + # then rejects with "MSFT_TaskExecAction is not a valid value for the + # Action variable" -- the install path never actually created the task. + $taskAction = New-ScheduledTaskAction -Execute $node + $bootTrigger = New-ScheduledTaskTrigger -AtStartup + $taskPrincipal = New-ScheduledTaskPrincipal -UserId $user -LogonType S4U -RunLevel Limited + Register-ScheduledTask -TaskName $TASK_NAME -Action $taskAction -Trigger $bootTrigger ` + -Principal $taskPrincipal -Force -ErrorAction Stop | Out-Null Write-Host "service: installed ($user, runs at boot)" } "remove" { |