igneum/app
igneum-labs e52d74988f Igneum Miner jobs: WSL as root by default, the shipped wsl2\bin prover run fixture by fixture (no cargo, no setup), account context logged at every job start, dashboard note when the app runs elevated or as another account
PC 2 on 0.3.3: 'wsl -d Ubuntu-24.04 -u [user]' from the app fails with getpwnam([user]) and the default user has no
cargo, while the project lead's own session has both in a distro of the same name: WSL distros belong to the Windows account,
and the engine runs under a different context than the interactive session. So the prover path is self-sufficient
inside the Ubuntu the app sees: the wsl-prover probe and the shard-benchmark job run as root (the job's wsl_user or
IGNEUM_APP_WSL_USER first, root second, the distro default last), and the shard job runs the Linux host the
payload ships next to the app (wsl2\bin\igneum-prove-host, cuda feature) directly for each fixture (shard 0 in
shard mode, the blocks in block mode, results under <app data>\prove\igneum-prove-wsl2\results); params.build
= true keeps the package's prove-shard.sh path. Every job logs the account context first (Windows user, SID,
elevated, the signed-in console user, then 'wsl user <id> uid <n> home <h>' and nvidia-smi inside the distro),
the engine logs it once at start, and the dashboard (Settings and the job strip) says 'The app runs as X
(elevated). The signed-in user is Y; WSL and its tools belong to that account.' when they differ.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 17:14:00 +00:00
..
igneum-app Igneum Miner jobs: WSL as root by default, the shipped wsl2\bin prover run fixture by fixture (no cargo, no setup), account context logged at every job start, dashboard note when the app runs elevated or as another account 2026-10-04 17:14:00 +00:00
mac One-click miner app: Rust engine (node, miner and worker supervisor with a local dashboard), Mac WKWebView window with a menu-bar item, design screenshots 2026-10-04 10:00:22 +00:00
windows Igneum Miner 0.3.3: an unattended Windows miner is never stranded by an update (4 Oct 15:40 incident: both PCs stopped at the installer's UAC prompt). Per-user installer (PrivilegesRequired=lowest, %LOCALAPPDATA%\Programs, migration from Program Files offered only when someone is at the keyboard, firewall rule asked once on first run and mining without it); the Windows helper runs the installer FIRST with the engine still mining and only the installer's own stop step ends it, a declined or unanswered prompt leaves the machine mining with "OTA: waiting for administrator approval" / "administrator approval not given; waits for the next time someone is at this PC" in the log and the intake, retry on Install now, next start or 6 h; machines take turns (apply only in the minute = machine id8 mod 60) and hold while /api/live shows over 30% of identities gone in 10 minutes 2026-10-04 14:59:51 +00:00