Sign up
View stargazers13Sign up

[Bug]: Antigravity runtime install fails on Debian VMs that use GCE OS Login#23005

opened3d agobyAArtem-B

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Run T3 on a Debian 13 GCE VM with OS Login enabled, as an OS Login user. These users are not in /etc/passwd, and /etc/nsswitch.conf has passwd: files cache_oslogin oslogin.
  2. Settings > Providers > Antigravity > Install.

Standalone repro with the managed 1.3.0 runtime (agy-acp-server-1.3.0-linux-x86_64.zip), started the way T3 starts it:

sh
1printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}' \
2 | ./agy_acp_server.par --uid=
3echo $? # 255, nothing on stdout or stderr

Expected behavior

The runtime installs and answers ACP initialize.

Actual behavior

Install fails with "The downloaded Antigravity runtime could not start in this environment." (ACP process exited with code 255), and T3 deletes the download.

The process exits before speaking ACP, with no output. The .par loads its own libgcc_s from a memfd. To resolve the current user it calls getpwuid_r, which loads libnss_oslogin.so.2 (from google-compute-engine-oslogin 20260924.00). That module links the system libstdc++, which can't bind against the bundled libgcc_s, so the lookup fails and the server exits. LD_DEBUG=libs shows:

1trying file=/lib/x86_64-linux-gnu/libnss_oslogin.so.2
2/proc/self/fd/5: error: version lookup error: version `GCC_4.3.0' not found (required by /lib/x86_64-linux-gnu/libstdc++.so.6) (fatal)

Users listed in /etc/passwd are presumably unaffected, since files answers before the OS Login module loads. Runtime 1.4.1, the current ACP registry version, behaves the same.

Impact

Blocks work completely

Version or commit

T3 0.1.2-nightly.20261021.3473; Antigravity ACP runtime 1.3.0

Environment

Debian 13 (trixie) GCE VM, kernel 6.12.111+deb13-cloud-amd64, OS Login enabled, google-compute-engine-oslogin 1:20260924.00-g1+deb13

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

Preload the system libgcc_s. With LD_PRELOAD=/lib/x86_64-linux-gnu/libgcc_s.so.1 the same command returns a normal initialize result. I put that in a wrapper script and pointed the Antigravity binary path at it, with a localharness_external symlink next to it. Adding the user to /etc/passwd should also work, but needs root.

JJulius Marminge2d ago

Triage at main b5a226e49c: runtime compatibility bug; no matching duplicate found.

The triage VM is Ubuntu 24.04 with a local user, so I tested the standalone command in an isolated Debian 13 x86-64 container with runtime 1.3.0, passwd: files cache_oslogin oslogin, and Google's 20260924.00-g1+deb13 NSS libraries. The container has no GCE metadata service or actual OS Login identity.

Sending the reported initialize payload to agy_acp_server.par --uid= produced:

text
1local /etc/passwd user: exit 0, initialize result, 899 stdout bytes
2UID absent from /etc/passwd: exit 0, initialize result, 899 stdout bytes
3same absent UID with system libgcc_s preloaded: exit 0, initialize result

The loader trace also contains the reported GCC_4.3.0 lookup error, but this attempt still returns initialize; exit 255 and the Settings install failure remain unverified.

Please provide dpkg-query -W libc6 libgcc-s1 libstdc++6 from the affected VM and the redacted tail of LD_DEBUG=libs for the failing standalone command through process exit. Does it still exit 255 with USER and LOGNAME unset? Please omit usernames, tokens and account details. These differences should help isolate why the real OS Login identity turns the loader error into a startup failure.

AArtem-B2d ago
Synced from GitHub

Thanks for testing. I think HOME explains the difference: the user lookup fails in every case, and HOME decides whether the runtime exits afterwards.

All results below are from runtime 1.3.0, using the same initialize payload and --uid= with no preload.

text
1$ dpkg-query -W libc6 libgcc-s1 libstdc++6
2libc6:amd64 2.41-12+deb13u4
3libgcc-s1:amd64 14.2.0-19
4libstdc++6:amd64 14.2.0-19

USER and LOGNAME unset: still exits 255. USER=other is also 255.

HOME: this is what decides the result. Exit code by HOME value:

text
1/home/<user> (the real home) 255
2/home/x/y 255
3/usr/local/google/home/x 255
4/home 0
5/homex/user 0
6/root 0
7/var/tmp/nosuch 0
8/tmp/<dir> 0
9unset 0

Every run shows the same GCC_4.3.0 error, so getpwuid_r fails in all of them. Both OS Login NSS modules link the system libstdc++, which can't bind against the runtime's bundled libgcc_s, so neither loads. The runtime then builds the user from env vars. Its own log shows what happens next:

text
1E loas_internal_util.cc:78] //base/nsscache.h failed to lookup uid <uid>
2W loascookie.cc:237] Constructed user information from env: <user>,/home/<user>,<uid>,<uid>,unknown-name,unknown-shell
3E loascookie.cc:305] =====================================================
4 getpwuid_r(3) failed on this machine for the uid <uid>.
5 Please find the root cause and fix it. Or please
6 pass the flag -loas_pwd_fallback_in_corp to continue
7 anyway with the env vars $USER("<user>")
8 and $HOME("/home/<user>").
9=====================================================
10Exiting since this machine is misconfigured

When HOME is outside /home/... or /usr/local/google/home/..., it logs the same two lookup lines and continues. I'd guess your container's HOME was /root or /, which would explain the exit 0 there. On a typical OS Login VM, HOME is /home/<user>.

Other ways it starts: passing --loas_pwd_fallback_in_corp, without any preload, gives a normal initialize result with exit 0. So does LD_PRELOAD of the system libgcc_s.so.1, because then the lookup itself succeeds.

Redacted LD_DEBUG=libs tail for the failing command (real environment, exit 255). I removed the identical dependency-search lines:

text
1find library=libnss_cache_oslogin.so.2 [0]; searching
2 search cache=/etc/ld.so.cache
3 trying file=/lib/x86_64-linux-gnu/libnss_cache_oslogin.so.2
4find library=libcurl.so.4 [0]; searching
5... (libjson-c, libstdc++, libnghttp3/2, libidn2, librtmp, libssh2, libpsl, libssl, libcrypto,
6 libgssapi_krb5, libldap, liblber, libzstd, libbrotli*, libz, libunistring, libgnutls,
7 libhogweed, libnettle, libgmp, libkrb5*, libk5crypto, libcom_err, libsasl2, libp11-kit,
8 libtasn1, libkeyutils, libresolv, libffi: all found in /lib/x86_64-linux-gnu)
9/proc/self/fd/5: error: version lookup error: version `GCC_4.3.0' not found (required by /lib/x86_64-linux-gnu/libstdc++.so.6) (fatal)
10find library=libnss_oslogin.so.2 [0]; searching
11 search cache=/etc/ld.so.cache
12 trying file=/lib/x86_64-linux-gnu/libnss_oslogin.so.2
13... (same dependency list)
14/proc/self/fd/5: error: version lookup error: version `GCC_4.3.0' not found (required by /lib/x86_64-linux-gnu/libstdc++.so.6) (fatal)
15calling fini: [0]
16calling fini: /lib/x86_64-linux-gnu/libdl.so.2 [0]
17calling fini: /lib/x86_64-linux-gnu/librt.so.1 [0]
18calling fini: /lib/x86_64-linux-gnu/libutil.so.1 [0]
19calling fini: /proc/self/fd/6 [0]
20... (fini for /proc/self/fd/8 through /proc/self/fd/23)
21calling fini: /lib/x86_64-linux-gnu/libpthread.so.0 [0]
22calling fini: /lib/x86_64-linux-gnu/libm.so.6 [0]
23calling fini: /lib/x86_64-linux-gnu/libc.so.6 [0]
24calling fini: /lib64/ld-linux-x86-64.so.2 [0]
25calling fini: /proc/self/fd/5 [0]
26calling fini: /proc/self/fd/4 [0]

To reproduce without OS Login, this should work: a UID missing from /etc/passwd, the OS Login NSS modules in nsswitch.conf, and HOME=/home/anything.

JJulius Marminge2d ago

Reproduced at main a50cd989ae using the bundled 1.3.0 runtime in an isolated Debian 13 container, UID 54321 absent from /etc/passwd, and passwd: files cache_oslogin oslogin. Package versions match the reply: libc 2.41-12+deb13u4, libgcc/libstdc++ 14.2.0-19, OS Login 20260924.00-g1+deb13.

The reported ACP initialize payload with --uid= gives:

text
1HOME=/home/anything: exit 255, stdout/stderr empty
2HOME=/root: exit 0, initialize result (899 bytes)
3HOME=/home/anything + --loas_pwd_fallback_in_corp: exit 0, initialize result (899 bytes)

The HOME difference explains the previous container result. This fixture has no GCE metadata service or actual OS Login identity; preloading system libgcc still exits 255 here.