[DGX Spark][Onboard] "Requested provider 'X' is not available in this environment" gives no reason and no remediation, while sibling failure branches in the same module do #8799

Description

When onboarding is asked for a provider whose runtime is not installed on the host, NemoClaw aborts with a single uninformative line:

[3/8] Configuring inference provider
Requested provider 'vllm' is not available in this environment.

It does not say why the provider is unavailable, what is missing, or how to install it. The user is left with a dead end at step 3 of 8.

This is inconsistent with the product's own error handling. In the same module (dist/lib/onboard/provider-selection-failure.js) the neighbouring branches do give a remediation hint:

case "wsl-recorded-ollama-windows-host":
  "Recorded provider ... (WSL Ollama) is not available in this environment."
  "Hint: Windows-host Ollama is reachable here; re-run with NEMOCLAW_PROVIDER=ollama to use it explicitly."

case "hermes-provider-unavailable":
  "Hermes Provider is only available when onboarding Hermes Agent."
  "Re-run with `nemohermes onboard` or `nemoclaw onboard --agent hermes`."

Only the requested-provider-unavailable branch emits the bare line with no hint.

What actually made it unavailable in this run: the host had no managed vLLM runtime installed (no vLLM container, and the host-local vLLM runtime marker file absent), even though the vLLM image was present in the local image store. Nothing in the output points at that.

This is fully reachable by a first-time user: on a clean machine, choosing the vLLM provider explicitly produces this dead end with no path forward.

Note this occurred on a host where GPU detection succeeded — preflight reported Docker CDI GPU support detected, NVIDIA GPU detected (NVIDIA GB10, 122572 MB) and Sandbox GPU: enabled (auto) — so the message is not a disguised GPU problem.

Environment

Device:        DGX Spark (GB10)
OS:            Ubuntu 24.04.3 LTS (kernel 6.11.0-1014-nvidia)
Architecture:  aarch64
Docker:        28.3.3
OpenShell CLI: 0.0.85
NemoClaw:      v0.0.103 (current remote LKG)
Commit SHA:    db31c286129e878c3356eed49f76ab259561e47e

Steps to Reproduce

1. On a host with a working NVIDIA GPU but no managed vLLM runtime installed (fresh machine, or after nemoclaw uninstall --yes plus removal of ~/.nemoclaw), install the LKG:

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

2. Onboard explicitly requesting the vLLM provider:

export NEMOCLAW_PROVIDER=vllm
export NEMOCLAW_VLLM_MODEL=deepseek-v4-flash
nemoclaw onboard --agent hermes --name <sandbox> --non-interactive --yes

3. Observe the output at [3/8] Configuring inference provider.

Expected Result

The failure states why the provider is unavailable (for example "no managed vLLM runtime is installed on this host") and gives the concrete next step to make it available, in the same style the module already uses for its other branches.

Actual Result

Preflight passes every check, including GPU:

✓ Docker is running
✓ Docker CDI GPU support detected (/etc/cdi/nvidia.yaml)
✓ Container runtime: docker
✓ openshell CLI: openshell 0.0.85
✓ Port 18080 available (OpenShell gateway)
✓ Port 18860 available (NemoHermes dashboard)
✓ NVIDIA GPU detected (NVIDIA GB10, 122572 MB)
✓ Sandbox GPU: enabled (auto)

[2/8] Starting OpenShell gateway
✓ Docker-driver gateway is healthy

[3/8] Configuring inference provider
Requested provider 'vllm' is not available in this environment.

Onboarding did not finish. Resume from the step that failed with:
  nemoclaw onboard --resume

No sandbox is created. The only guidance offered is the generic --resume line, which repeats the same failure.

Host state that made vLLM unavailable (none of which is surfaced to the user):

$ docker ps -a | grep -i vllm     -> no vllm container
$ docker images | grep -i vllm    -> nvcr.io/nvidia/vllm image IS present locally
$ ls ~/.nemoclaw/host-local-vllm-runtime.json  -> absent

Found during the NemoClaw VDR#6 FVR, matrix row 2 (DGX Spark · vllm-nim · DeepSeek V4 Flash · nemohermes).