Summary
scripts/install.sh aborts during server --setup-only on Ubuntu 26.04 because the overlaybd dependency-refresh step constructs a download URL using the host's exact detected distro+version (ubuntu1.26.04), and containerd/overlaybd has no release asset published for that target — only up to ubuntu1.24.04.
Environment
- Host: Ubuntu 26.04 LTS ("resolute"), kernel 7.0.0-28-generic, x86_64
- AgentENV: v0.1.1, installed via the documented
curl | sudo bash flow with AENV_HOME_PATH overridden to a custom data directory
Repro
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo AENV_HOME_PATH=/opt/aenv bash
Fails partway through with:
downloading url="https://github.com/containerd/overlaybd/releases/download/v1.0.18/overlaybd-1.0.18-20260710.cee2186.ubuntu1.26.04.x86_64.deb"
Error: HTTP 404 Not Found for https://github.com/containerd/overlaybd/releases/download/v1.0.18/overlaybd-1.0.18-20260710.cee2186.ubuntu1.26.04.x86_64.deb
Confirmed via the GitHub API that containerd/overlaybd release v1.0.18 only ships .deb assets for ubuntu1.18.04, 20.04, 22.04, and 24.04 (plus .rpms for other distros) — no 26.04 build exists yet.
Because install.sh runs under set -euo pipefail, this failure aborts the script before it reaches the systemd unit / env file / final chown steps, leaving a partially-installed host (CLI + server binaries present, dependencies mostly staged, but no working service).
Notes on the "path override" comment
The compiled-in default deps_manifest.toml (visible via strings on the server binary) has this comment on the [overlaybd] section:
# Automatic overlaybd package download currently targets Ubuntu release
# assets only; other distros must provide overlaybd with path overrides.
I could not find a working end-user-facing override for this — writing a config/deps_manifest.toml under the configured home path with an [overlaybd] path key had no effect (confirmed the file isn't read at all: even intentionally-invalid TOML there didn't produce a parse error). If this comment refers to a source-level override for a custom build rather than a runtime config file, that'd be worth clarifying in the docs, since the natural reading (given the config/config.toml comment pointing at config/deps_manifest.toml) is that it's a supported runtime override.
Workaround we used
The release tarball (aenv-server-linux-x86_64.tar.gz) already bundles a fully working overlaybd build under deps/overlaybd/ — built from the ubuntu1.24.04 asset per the bundled deps/overlaybd/tools-release.json. We confirmed via ldd and direct execution that these binaries run cleanly on Ubuntu 26.04 (all shared library dependencies resolve against system libs, including libssl.so.3/libc.so.6). The only actual problem is that tools-release.json records the ubuntu1.24.04 asset name, which no longer matches the host's freshly-detected ubuntu1.26.04 target, so --setup-only treats it as stale and attempts a redownload.
Editing deps/overlaybd/tools-release.json's asset_name field to read ubuntu1.26.04 (matching what the host now expects) makes --setup-only treat dependencies as already satisfied and skip the redownload, since the actual binaries already work fine. This is obviously a metadata-spoofing hack, not a real fix, and it gets silently reverted by any future install/upgrade that re-extracts the tarball's bundled tools-release.json.
Suggested fixes (any of these would help)
- A genuine, documented runtime override for the overlaybd asset (path or URL), independent of host OS detection.
- Falling back to the bundled/already-present overlaybd version when the host-specific asset isn't available, with a warning, instead of hard-failing.
- Not aborting the entire install (or at least completing systemd unit setup) when a non-fatal dependency-refresh step fails, so the host isn't left in a partially-installed, unrecoverable-via-rerun state.
- Publishing a broader release-asset matrix upstream in
containerd/overlaybd (outside this project's control, but worth a note).
Happy to provide more detail or test a fix — this is a promising project and we'd like to keep using it for a sandboxed-agent-execution pilot.
Summary
scripts/install.shaborts duringserver --setup-onlyon Ubuntu 26.04 because the overlaybd dependency-refresh step constructs a download URL using the host's exact detected distro+version (ubuntu1.26.04), andcontainerd/overlaybdhas no release asset published for that target — only up toubuntu1.24.04.Environment
curl | sudo bashflow withAENV_HOME_PATHoverridden to a custom data directoryRepro
Fails partway through with:
Confirmed via the GitHub API that
containerd/overlaybdreleasev1.0.18only ships.debassets forubuntu1.18.04,20.04,22.04, and24.04(plus.rpms for other distros) — no26.04build exists yet.Because
install.shruns underset -euo pipefail, this failure aborts the script before it reaches the systemd unit / env file / finalchownsteps, leaving a partially-installed host (CLI + server binaries present, dependencies mostly staged, but no working service).Notes on the "path override" comment
The compiled-in default
deps_manifest.toml(visible viastringson theserverbinary) has this comment on the[overlaybd]section:I could not find a working end-user-facing override for this — writing a
config/deps_manifest.tomlunder the configured home path with an[overlaybd]pathkey had no effect (confirmed the file isn't read at all: even intentionally-invalid TOML there didn't produce a parse error). If this comment refers to a source-level override for a custom build rather than a runtime config file, that'd be worth clarifying in the docs, since the natural reading (given theconfig/config.tomlcomment pointing atconfig/deps_manifest.toml) is that it's a supported runtime override.Workaround we used
The release tarball (
aenv-server-linux-x86_64.tar.gz) already bundles a fully working overlaybd build underdeps/overlaybd/— built from theubuntu1.24.04asset per the bundleddeps/overlaybd/tools-release.json. We confirmed vialddand direct execution that these binaries run cleanly on Ubuntu 26.04 (all shared library dependencies resolve against system libs, includinglibssl.so.3/libc.so.6). The only actual problem is thattools-release.jsonrecords theubuntu1.24.04asset name, which no longer matches the host's freshly-detectedubuntu1.26.04target, so--setup-onlytreats it as stale and attempts a redownload.Editing
deps/overlaybd/tools-release.json'sasset_namefield to readubuntu1.26.04(matching what the host now expects) makes--setup-onlytreat dependencies as already satisfied and skip the redownload, since the actual binaries already work fine. This is obviously a metadata-spoofing hack, not a real fix, and it gets silently reverted by any future install/upgrade that re-extracts the tarball's bundledtools-release.json.Suggested fixes (any of these would help)
containerd/overlaybd(outside this project's control, but worth a note).Happy to provide more detail or test a fix — this is a promising project and we'd like to keep using it for a sandboxed-agent-execution pilot.