Hermes installer: Windows service for WSL2 auto-start with GPU + Tailscale

[joelteply]

Problem

WSL2 doesn't auto-start on Windows boot. Every reboot requires someone to manually:

1. Open PowerShell as administrator (regular won't work — GPU passthrough needs admin)
2. Type wsl
3. Wait for it to start
4. Hope Tailscale and SSH come up

This is unacceptable for a grid node. A machine that needs a human to poke it after every power cycle is not a server.

Solution

Hermes (install.sh) detects Windows/WSL2 and creates a Windows scheduled task:

# Created by Hermes installer — runs at system boot, before login, as SYSTEM
$action = New-ScheduledTaskAction -Execute "wsl.exe" -Argument "-u root -- /etc/continuum/boot.sh"
$trigger = New-ScheduledTaskTrigger -AtStartup
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName "ContinuumWSL" -Action $action -Trigger $trigger -Principal $principal -Settings $settings

Inside WSL: /etc/continuum/boot.sh

#!/bin/bash
# Start SSH
service ssh start

# Start Tailscale  
tailscaled --state=/var/lib/tailscale/tailscaled.state &
sleep 2
tailscale up --ssh --accept-routes

# Protect critical services from OOM killer
for pid in $(pgrep -f 'sshd|tailscaled'); do
    echo -17 > /proc/$pid/oom_adj 2>/dev/null
done

# Log success
echo "$(date): Continuum boot complete" >> /var/log/continuum-boot.log

wsl.conf

[boot]
systemd=true

[automount]
enabled=true

Requirements

• Runs as SYSTEM (not dependent on user login)
• Runs at boot (not at login — machine might be headless)
• GPU passthrough works (admin privileges)
• Tailscale reconnects automatically
• SSH accessible within 30 seconds of Windows boot
• OOM killer can't take down SSH/Tailscale
• Zero user interaction after initial install

The Standard

curl -sL install.continuum.ai | bash on a Windows machine with WSL2:

1. Installs continuum in WSL2
2. Creates the Windows scheduled task
3. Configures wsl.conf and boot.sh
4. Machine survives reboots forever

Dependencies

• Build(deps-dev): Bump @typescript-eslint/eslint-plugin from 8.29.1 to 8.37.0 #93 (sentinel-ai) — Server resilience

[joelteply]

Updated: Installation strategy

Phase 1: Enthusiast/developer (now)

winget install continuum

One command. Winget is already on every Windows 10/11 machine. Handles UAC elevation, WSL2 setup, GPU detection, auto-start service. This is what goes in the README and the tweet.

Phase 2: Website install (soon)

"Install Continuum" button on the website. Uses ms-appinstaller: protocol to trigger MSIX install directly from the browser. Click link → click "Install" in the system dialog → done. Zero downloads, zero file management.

Phase 3: True consumer (later)

Full MSIX package in the Microsoft Store. Auto-updates. One-click install. Repair button. The Discord/Steam experience.

What all paths must do invisibly

• Install/enable WSL2 if needed
• Install GPU drivers if needed (or verify existing)
• Set up the Windows service for auto-start (survives reboots)
• Install Tailscale inside WSL2
• Configure OOM protection for critical services
• Create desktop shortcut to the web UI
• Never show a terminal, PowerShell, or command prompt to the user

Key insight

The target user has a gaming PC with a 5090 and doesn't know what PowerShell is. If the install requires any Windows-specific knowledge, we've lost them. Test by imagining someone who only knows how to double-click things.

[joelteply]

Superseded by #569 for the full install experience

#569 covers the signed MSIX + winget path (Tailscale model). This issue (#565) remains relevant for the WSL2 boot scripts that the installer uses internally — the scripts are already committed on branch fix/generated-content-types:

• src/scripts/wsl-boot.sh — runs inside WSL2 on boot
• src/scripts/windows-setup-autostart.ps1 — creates the scheduled task

These are the plumbing. #569 is the user-facing experience.

[joelteply]

Tailscale on WSL2 is broken

• tailscale up needs sudo which requires a terminal (can't do over SSH)
• Even when DNS is fixed (PR Factory, CLI fix, content routing, session identity, WSL2 DNS #581), Tailscale itself doesn't auto-start on WSL2 boot
• The 100.124.122.107 IP times out — Tailscale daemon isn't running
• This blocks ALL remote work — can only reach tower via LAN 192.168.1.232
• This blocks the grid entirely — nodes can't discover each other

What needs to happen

1. Tailscale must auto-start on WSL2 boot (systemd service or wsl-boot.sh)
2. No sudo password prompt — needs passwordless sudo for tailscale or run as service
3. DNS must persist (resolved in wsl-boot.sh but needs to run on boot)
4. If Tailscale continues to be unreliable on WSL2, consider Reticulum (Reticulum mesh: MPC identity + encrypted transport (replace Tailscale) #349) or our own solution