Repository navigation
Install issues #360
Description
I had the following issues installing nemoclaw on an nvida thor.
- Remove the "$" from the curl command.
- Docker needs to be enabled for the $USER installing the app.
- The install doesn't add openshell to the path.
- Use "sudo lsof -i :8080 -sTCP:LISTEN" (missing sudo) to see the conflict. "docker-ps" was the conflict for me.
- Preflight checks don't discover the gpu on the Thor: ⓘ No GPU detected — will use cloud inference
- Install stops at 3/7: [3/7] Creating sandbox
──────────────────────────────────────────────────
Sandbox name (lowercase, numbers, hyphens) [my-assistant]: [INFO] === Installation complete === nemoclaw onboardwill fail if you use a custom sandbox name.- 'nemoclaw start' requires an NVIDIA key even though it is supposed to be local.
At this point, I gave up and started my own container and running:
ollama launch openclaw --model nemotron-3-super
Activity
fix: propagate custom sandbox name through promptOrDefault (NVIDIA#360)
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
craigamcw commentedon Mar 22, 2026
Fix submitted in #631 —
promptOrDefaultnow trims and falls back todefaultValuein both interactive and non-interactive mode. Redundant fallback increateSandboxremoved. 12 tests added (7 non-interactive + 5 interactive via injectable prompt).CorwynSMP commentedon Mar 22, 2026
Nemoclaw-Jetson AGX Thor workaround / lessons learned
I got to a working local sandbox on Jetson AGX Thor and wanted to share what actually moved the needle for me.
Environment
I would suggest fixing things in this order.
This was the deepest blocker on my system.
Before the fix:
That caused this exact failure pattern:
Host fix:
sudo modprobe br_netfilter
sudo modprobe overlay
echo 'br_netfilter' | sudo tee /etc/modules-load.d/k8s.conf >/dev/null
echo 'overlay' | sudo tee -a /etc/modules-load.d/k8s.conf >/dev/null
sudo tee /etc/sysctl.d/99-kubernetes-cri.conf >/dev/null <<'EOF'
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system
Host verification:
lsmod | egrep 'br_netfilter|overlay'
sysctl -a 2>/dev/null | egrep 'net.bridge.bridge-nf-call-(iptables|ip6tables)'
ls -l /proc/sys/net/bridge
Expected:
I downloaded a local copy of nemoclaw.sh instead of repeatedly using curl | bash:
curl -fsSL https://www.nvidia.com/nemoclaw.sh -o ~/nemoclaw.sh
chmod +x ~/nemoclaw.sh
I did this for two reasons:
In my case, I uncommented the install_or_upgrade_ollama call so that Ollama was installed before onboarding. That was necessary to get the local Ollama path working reliably on my system.
On my system I had to manually apply the NVIDIA device plugin so that Kubernetes inside OpenShell advertised the GPU correctly.
These steps are not required, unless you want this fix for a gateeway out side of this context
#Gateway hard reset + GPU injection:
#openshell gateway destroy
#openshell gateway start
While nemoclaw was running right after it said it started a gateway and it is waiting for a sandbox name, I went to another window and ran
openshell doctor exec -- kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.0/deployments/static/nvidia-device-plugin.yml
Important:
wait about 10 seconds before running the verification command below so the pod has time to initialize.
Verify GPU is visible to k8s:
openshell doctor exec -- kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.'nvidia.com/gpu'
Expected:
NAME GPU
1
Once I got farther into onboarding, local Ollama worked only after making sure it listened on all interfaces, not just localhost.
Start Ollama correctly:
export OLLAMA_HOST=0.0.0.0:11434
nohup ollama serve >/tmp/ollama.log 2>&1 &
Verify:
curl http://localhost:11434/api/tags
ss -lntp | grep 11434
I needed port 11434 listening on * / 0.0.0.0, not just 127.0.0.1, otherwise the sandbox could not reach it via host.openshell.internal.
What finally worked
I ended up with:
Verification from my system:
Important caution
nemoclaw.sh behaved like a bootstrap / onboarding script, not a resumable installer. Rerunning it re-touched gateway / sandbox state.
Once I got to a working sandbox, I stopped rerunning the installer and only used:
Bottom line
The biggest fix for me was not the model selection or the cloud/API side.
The biggest fix was the host kernel networking state:
Without that, ClusterIP routing inside the OpenShell k3s environment was broken, and the rest of the stack behaved unpredictably.
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(cli): respect defaultValue in promptOrDefault interactive mode
fix(bootstrap): support cgroup v1 hosts by disabling kubelet failCgro…
fix(cli): respect defaultValue in promptOrDefault interactive mode
wscurran commentedon Apr 13, 2026
Several of the issues listed here have since been fixed — the curl TTY issue (#377) and custom sandbox name handling (#631) are both resolved. Thanks to @CorwynSMP for the detailed AGX Thor workaround; the br_netfilter, overlay module, and Ollama host bind notes are exactly the kind of platform-specific context that's hard to rediscover. Jetson/Thor support is on our roadmap and that writeup will be useful when we get there. Closing to consolidate tracking — please open targeted issues for any specific failures that persist on the current version.
fix(cli): respect defaultValue in promptOrDefault interactive mode