fatredwombat1

Subject: antigravity-cli — install/update always produces an empty package (binary missing), traced to two bugs in the consolidate pipeline Diagnosis and workaround below were prepared with Claude Code (Anthropic's CLI agent), running on this box under the aicliagents plugin itself — it traced the failure through the plugin's own logs and source rather than me guessing. Plugin version: 2026.09.15.08 Agent affected: antigravity-cli (curl_install source) Symptom: After updating or reinstalling antigravity-cli via the Store card, the workspace fails to launch with: [Agent Binary Missing] The agent binary was not found. Expected: .../agents/.versions/antigravity-cli/agent_antigravity-cli_consolidated_.../home/.local/bin/agy What was found (via lifecycle.log / debug.log and reading the plugin source): 1. Side-by-side install runs for a curl_install agent, which AgentHandler.php itself documents as unsupported. AgentHandler::sideBySideInstallBlocker() (includes/handlers/AgentHandler.php:253) explicitly states curl_install agents aren't ready for side-by-side installs because their vendor script "lands its binary inside a captive home directory inside the agent's own tree." Despite that, lifecycle.log shows an antigravity-cli upgrade going side-by-side anyway: [MOUNT] Agent antigravity-cli: generation ...0001... is still in use — installing ...0002... alongside it (no session closed). 2. The real breakage: consolidate_layers's pre-bake mount refresh wipes the writable layer before packaging it. In src/scripts/storage/storage_ops.sh, the block labeled WP #1246 remounts the overlay ("refresh... before reading the merged view") right before mksquashfs runs. For antigravity-cli, this refresh was confirmed to empty the writable (zram) upper directory: the real agy binary was manually installed (via Google's own https://antigravity.google/cli/install.sh, HOME/PREFIX pointed at the live generation dir) and verified working (agy --version → 1.2.8, 207MB on disk). Running the plugin's own install-bg.php afterward (which re-invokes consolidate_layers) baked a new squashfs at 4096 bytes — i.e. it discarded the populated upper dir and shipped an empty layer, same as every prior attempt. Confirmed via atomic_write_layer log lines (bytes=4096) on every one of 3 separate install attempts across two plugin versions (1.2.4 upgrade, 1.2.8 fresh install, 1.2.8 re-consolidate). Trace IDs for reference: 938fcf06 (upgrade attempt), d1918f1e (fresh install attempt). Impact: Every install/update of antigravity-cli on this system has produced an unusable agent since upgrading to 2026.09.15.08. A workaround (running the vendor install script by hand into the live mount, without letting the plugin's own consolidate re-run) gets it working again, but it only lives in the RAM-backed overlay and is wiped on reboot or the next Store-card action that triggers consolidate. Ask: Could someone check storage_ops.sh's WP #1246 pre-consolidate refresh path for curl_install-sourced agents (or specifically agents that were side-by-side-installed) — it looks like the refresh isn't preserving the correct upper dir before mksquashfs runs. --- Root-cause tracing and the working-again fix above were done end-to-end by Claude Code — reading lifecycle.log/debug.log, walking through AgentHandler.php/CurlInstallSource.php/storage_ops.sh, and reproducing the byte-for-byte empty-package result three times before landing on the actual mechanism. Happy to have it dig further if a maintainer wants more specific repro data. Just the human here wanting to say that I really enjoy this plugin so thanks! Matt UPDATE: (2026-09-27): This just reproduced again on a real update — not just my own reinstall testing. I updated antigravity-cli through the Store card as usual (not manually), and it hit the identical failure: lifecycle.log shows the same signature (old_size_mb: 0 → a 4096-byte consolidated .sqsh), this time on generation agent_antigravity-cli_consolidated_0000000005_20260926T231458Z, going from 1.2.8 → the then-latest 1.2.11: 2026-09-26T23:14:48Z | installer | agent_install_target_resolved | {"agent":"antigravity-cli",...,"version":"1.2.11","fallback":false,"explicit":true} 2026-09-26T23:14:57Z | StorageMountService | consolidate_start | {"type":"agent","id":"antigravity-cli","old_size_mb":0} 2026-09-26T23:14:59Z | atomic_write_layer | atomic_write_ok | {...,"final":"agent_antigravity-cli_consolidated_0000000005_20260926T231458Z.sqsh","bytes":4096} So this is now confirmed across 5 separate installs (2 plugin versions, 2 antigravity-cli target versions, both explicit-version and "latest" upgrade paths) — it's not something specific to how I was triggering it initially. Every single install/update of antigravity-cli since the 2026-09-17 plugin upgrade has produced an empty package on this system. Reapplied the same manual workaround (installing the real vendor binary directly into the live generation mount, without letting the plugin's consolidate step touch it) and it's working again (agy 1.2.12). Update (2026-09-28): Confirmed and fixed for good — not just patched in RAM this time. Had Antigravity run the actual repair itself, using the exact fix it identified: it called the plugin's own atomic_write_layer() function, but passed it agent_mount_real("antigravity-cli") (the already-resolved real directory) instead of the buggy symlink path the plugin's own op_consolidate normally uses. Result — verified independently on my end too: - New persisted layer: agent_antigravity-cli_consolidated_0000000006_20260927T212043Z.sqsh, 45,555,712 bytes (vs. the previous 4,096-byte empty dummy) - unsquashfs -l confirms it actually contains home/.local/bin/agy, VERSION, and the full directory tree — a real package this time - Plugin's own storagectl.sh status reports "outcome":"ok", "mounted":true, layer registered correctly in layer_manifest.json with checksum - Old broken 4KB layer was cleanly removed So antigravity-cli is now genuinely working and should survive a reboot — this was hand-applied outside the Store UI (since the UI's own install/update path still has the underlying bug), but it proves the one-line fix works cleanly with zero side effects on the plugin's own manifest/mount bookkeeping. tl;dr for whoever picks this up: storage_ops.sh line ~1600 just needs $MNT_POINT swapped for $_MOUNT_POINT_REAL (or the equivalent agent_mount_real "$ID" call) before it's handed to atomic_write_layer. Everything downstream of that already works correctly once it's given a real path instead of a symlink.

So after a lot of mucking around, it turns out the problem seems to be the unraid USB maker. It IS NOT adding all of the files from the backup to the USB. Of course I didn't even think to check the contents of the USB after creation. 48 hours of downtime because I didn't have a quick look. Follow the manual install method for fix. Add the new .key file and away you go....

Hi All Thanks in advance for your assistance. I have been using Unraid for a couple of years now but am far from a power user. I had recently changed to the hardware found in my signature about a month ago from much older hardware without too much drama apart from a couple of dockers that needed some tweaks. My recent issues occurred early in the week when I could not access the unraid GUI remotely via tailscale. Discovered an expired key, renewed the key locally and all good again. Then on Thursday I had the same issue - except I couldn't log in locally via IP. Of interest, dockers seemed to be working. I could access QBittorrent and it seemed to be actively uploading. Finally tried tower.local/ and managed to get a partial GUI with a banner telling me the usb was dead. Ordered a new USB, USB arrives, go to unraid connect, download most recent flash backup, install via Unraid USB creator - most recent being from the 17th June. Plug in the USB to server and it booted into unraid, is assigned an IP address, can ping the IP address from a windows machine, but I am unable to gain access to the GUI either on the local machine or remotely. I have contacted support and had a new key assigned, added the key to the drive and still no dice. A new install of unraid on the same usb key will boot to the GUI but I would like to avoid the need to set up everything again. Happy to try things from the command line or while it's plugged into my windows laptop. Any assistance is appreciated. tower-diagnostics-20250620-1851.zip