NVIDIA / NVIDIA/NemoClaw

[Ubuntu 26.04][Onboard] Portable onboard builds the whole image before checking its registry is reachable

Open
#11,724 0 comments 0 reactions 0 assignees View on GitHub
needs: triage NV QA
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

## Description

Portable onboarding does not check that its managed local registry is reachable before it starts building the sandbox image. It runs the complete 134-step image build first, and only then fails when it tries to publish, because nothing answers on the registry port.

The wasted work is the point of this report. The condition that causes the failure is detectable in under a second with a single request to the registry, but the user waits for a full image build before being told.

To be clear about scope: the registry being unreachable in this instance was a stale environment condition, not something the product caused. This report is about the missing readiness check and the resulting late failure, not about why the registry was down.

- **Platform scope:** Reproduced on Ubuntu 26.04 x86_64 only; other platforms not tested.
- **Regression:** Unknown — earlier versions not tested for this path.
- **OpenShell issue:** No

## Environment

```text
Device: Ubuntu 26.04 host, x86_64, NVIDIA RTX PRO 6000 Blackwell Server Edition
OS: Ubuntu 26.04 LTS
Architecture: x86_64
Node.js: Not on PATH (installer-managed Node.js)
npm: Not on PATH (installer-managed Node.js)
Docker: Docker version 29.6.1, build 8900f1d
Podman: podman version 5.7.0
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.123
OpenClaw: N/A (onboard not completed)
```

## Steps to Reproduce

1. On a host that has previously run Portable onboarding, put the managed local registry into a state where its container reports running but nothing answers on its port. A stale `nemoclaw-portable-registry` container whose rootless port forwarder has died produces this; it can also be reproduced by stopping the forwarder while leaving the container up.

2. Confirm the container looks healthy but the port does not answer:

```bash
podman ps --format "{{.Names}} | {{.Status}} | {{.Ports}}"
curl -sS -m 5 http://127.0.0.1:5000/v2/ ; echo "curl_exit=$?"
```

3. Start Portable onboarding:

```bash
nemoclaw onboard --experimental-profile portable --agent openclaw --fresh \
--name portable-timing --yes-i-accept-third-party-software
```

4. Time how long onboarding runs before it reports a failure, and note which step it fails on.

## Expected Result

Onboarding checks that the managed local registry answers before it starts the image build, and fails immediately with a clear message naming the registry and the port when it does not.

The user is not made to wait for a complete image build to learn about a condition that was detectable before any build work started.

## Actual Result

Onboarding runs the full 134-step image build, then fails at the publish stage:

```text
Error: trying to reuse blob ... pinging container registry localhost:5000:
Get "http://localhost:5000/v2/": dial tcp [::1]:5000: connect: connection refused
Error: Managed local registry publish failed (exit 125)
```

The registry had been unreachable for the entire run. A single request to `http://127.0.0.1:5000/v2/` before the build would have returned the same connection refused immediately.

The state was also not obvious from the outside: the `nemoclaw-portable-registry` container reported STATUS "Up" with published port `127.0.0.1:5000` while no process was listening on that port, so neither the product nor the user could rely on the container status alone.

A related recovery snag was observed in the same run: `podman restart` of that container failed with `rootless netns: kill network process: permission denied`, and a separate `podman start` was needed to bring the port back.

## Logs

```text
Not captured beyond the terminal output quoted in Actual Result.
```

Contributor guide

Open the contributing guide

Research direction

Start at the `nemoclaw onboard --experimental-profile portable` entry point and trace the portable onboarding path through managed registry setup and the 134-step image build. Confirm that the registry request to `http://127.0.0.1:5000/v2/` occurs before building, and that an unreachable registry produces a clear error naming the registry and port without starting the build.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, infrastructure
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.