NVIDIA / NVIDIA/NemoClaw

curl|bash upgrade from v0.0.111 refuses to retire the OpenShell 0.0.101 gateway on a clean install, host left in split-version state

Open
#10,541 0 comments 0 reactions 1 assignee Claimed by @rluo8 View on GitHub
area: install area: sandbox NV QA platform: arm64 platform: ubuntu
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

## Description

The documented curl|bash in-place upgrade from NemoClaw v0.0.111 to v0.0.114 aborts at the OpenShell gateway retirement step on a completely clean, single-sandbox installation, refusing to retire a gateway service that the installer itself created moments earlier. The host is left in a mixed-version state: the NemoClaw CLI reaches v0.0.114, but OpenShell stays on 0.0.101 and is never reinstalled, and re-running the identical upgrade command hits the same error again with no way to proceed via the documented flow.

**Platform scope:** Reproduced on Ubuntu 24.04 (aarch64) only; other Linux architectures/distributions not tested.
**Regression:** Unknown — earlier versions not tested; this is the first time this exact v0.0.111 to v0.0.114 upgrade path was exercised.
**OpenShell issue:** No — the failing operation is orchestrated by the NemoClaw installer script's gateway-retirement logic, not a standalone `openshell` command.

## Environment

```text
Device: DGX Station (aarch64)
OS: Ubuntu 24.04.4 LTS
Architecture: aarch64
Node.js: v22.23.2
npm: 10.9.8
Docker: 29.2.1 (build a5c7197)
OpenShell CLI: 0.0.101
NemoClaw: v0.0.111 baseline, upgrade target v0.0.114 (CLI itself reaches v0.0.114 after the failed attempt; OpenShell stays at 0.0.101)
OpenClaw: v2026.7.1
```

## Steps to Reproduce

1. On a Linux host with a systemd `--user`-managed OpenShell gateway, install NemoClaw v0.0.111 fresh:
```bash
curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_INSTALL_TAG=v0.0.111 bash
```
2. Complete onboarding with any provider so exactly one sandbox is registered and running (`nemoclaw list` shows a `*` marker).
3. Confirm the baseline: `nemoclaw --version` reports v0.0.111; `openshell --version` reports 0.0.101.
4. Run the documented upgrade:
```bash
curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_INSTALL_TAG=v0.0.114 bash
```
5. Observe the installer output at the "Retiring OpenShell 0.0.101 gateway" step.

Reproduced 3/3 across independent, fully clean v0.0.111 baselines (a full uninstall + state reset between attempts, with no manual intervention of any kind before triggering the upgrade) — ruling out leftover state as the cause.

## Expected Result

The upgrade retires the existing OpenShell gateway — which the installer itself created during the v0.0.111 onboard and which was never modified afterward — installs the new OpenShell release, and recreates the gateway, completing successfully.

## Actual Result

The upgrade aborts partway through, after the pre-upgrade backup succeeds but before OpenShell is ever reinstalled:

```text
[INFO] Retiring OpenShell 0.0.101 gateway before installing current OpenShell...
[ERROR] Refusing to retire the OpenShell gateway because the active user service
does not match ~//.config/systemd/user/nemoclaw-openshell-gateway.service.
```

The pipeline exits non-zero at this point. `nemoclaw --version` afterward already reports v0.0.114 (the CLI itself was updated before this step), but `openshell --version` still reports 0.0.101, because the OpenShell reinstall step is never reached.

We independently confirmed on the live host that this is a false mismatch, not a genuine identity problem. The path the installer compares against contains a double slash immediately after the home directory, visible in the error text above, while the systemd-reported path for the exact same, still-running, unmodified gateway service is single-slash and otherwise identical. In a side-by-side comparison performed outside the installer, stripping only the redundant slash from the home-directory value made the two path strings match exactly — confirming the installer is rejecting a gateway service it created itself moments earlier because of a cosmetic difference in how the same path is represented, not any real change in gateway identity.

## Logs

```text
[2/3] NemoClaw CLI
--------------------------------------------------
[INFO] Backing up 1 sandbox(es) before upgrading OpenShell...
[INFO] Preparing current NemoClaw CLI for pre-upgrade backup...
[INFO] Installer payload is not a persistent source checkout - installing from GitHub...
[INFO] Installing NemoClaw from GitHub...
[INFO] Resolved install ref: v0.0.114
[ok] Cloning NemoClaw source
[ok] Preparing OpenClaw package
[ok] Installing NemoClaw dependencies
[ok] Building NemoClaw CLI modules
[ok] Building NemoClaw plugin
[ok] Linking NemoClaw CLI
[INFO] Deferring OpenShell CLI installation until after pre-upgrade backup.
[INFO] Verified: nemoclaw is available at ~/.npm-global/bin/nemoclaw
Backing up 'my-sandbox'...
[ok] my-sandbox: 12 dirs, 1 files backed up to ~/.nemoclaw/rebuild-backups/my-sandbox/{timestamp}

Pre-upgrade backup: 1 backed up, 0 failed, 0 skipped
Backups stored in: ~/.nemoclaw/rebuild-backups
[INFO] Retiring OpenShell 0.0.101 gateway before installing current OpenShell...
[ERROR] Refusing to retire the OpenShell gateway because the active user service
does not match ~//.config/systemd/user/nemoclaw-openshell-gateway.service.
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.