Description

Fresh onboarding with NEMOCLAW_PROVIDER=install-ollama fails in non-interactive/headless environments when the official Ollama installer needs sudo. A user-local Ollama install works as a workaround, so NemoClaw could make this path first-class or offer it as a fallback.

Environment

Device:        DGX Spark / NVIDIA GB10
OS:            Ubuntu 24.04-family, Linux 6.17.0-1014-nvidia
Architecture:  aarch64
Docker:        29.2.1, build a5c7197
OpenShell CLI: 0.0.44
NemoClaw:      v0.1.0
Install ref:   main
Commit:        7c7f7a428624ad72082d7b11395e25d7ae43daad

Steps to reproduce

Run onboarding in a non-interactive shell where sudo cannot prompt for a password:

NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 \
NEMOCLAW_NON_INTERACTIVE=1 \
NEMOCLAW_PROVIDER=install-ollama \
NEMOCLAW_MODEL=qwen3.6:35b \
NEMOCLAW_POLICY_MODE=suggested \
NEMOCLAW_YES=1 \
nemoclaw onboard --fresh --non-interactive --yes --yes-i-accept-third-party-software

Observed behavior

NemoClaw invokes the official Ollama installer, which needs sudo for /usr/local, system user/service setup, etc. In a non-interactive harness this fails:

The Ollama installer creates a system user, a systemd service, and writes to /usr/local. It uses sudo, may ask for your password, and can take a few minutes; installer output will stream below.
>>> Installing ollama to /usr/local
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
Command failed (exit 1): set -o pipefail; curl -fsSL https://ollama.com/install.sh | sh

Workaround that succeeded

A user-local install works without sudo:

mkdir -p "$HOME/.local"
curl --fail --show-error --location https://ollama.com/download/ollama-linux-arm64.tar.zst \
  | zstd -d \
  | tar -xf - -C "$HOME/.local"

nohup env OLLAMA_HOST=127.0.0.1:11434 "$HOME/.local/bin/ollama" serve \
  >"$HOME/.local/state/nemoclaw/ollama-user.log" 2>&1 &

NEMOCLAW_PROVIDER=ollama nemoclaw onboard --fresh --non-interactive --yes --yes-i-accept-third-party-software

Onboarding then detected local Ollama, started the auth proxy, pulled/validated qwen2.5:7b, and completed successfully.

Expected behavior

When install-ollama cannot use sudo in non-interactive mode, NemoClaw should either:

• offer/use a user-local Ollama install fallback, or
• print a concise fallback command block and exact resume command.

Suggested fix

Add a supported ~/.local Ollama install mode for Linux/aarch64 and Linux/amd64, possibly gated behind an env var such as NEMOCLAW_OLLAMA_INSTALL_MODE=user or selected automatically when sudo is unavailable in non-interactive mode.