Make the dev image usable as a VS Code devcontainer, with Rust

[alycda]

Makes the dev image actually work as a VS Code devcontainer, and gives it a Rust toolchain. The two are independent — the Rust commits are the original goal, the Docker commits are what it took to get a devcontainer to open at all.

Two defects, one root cause

The image is a Nix rootfs; Dev Containers and the VS Code Server assume FHS. Both failures reported something other than themselves, which is most of why they took a while:

docker exec was broken. The base image ships /etc/{passwd,group,shadow} as absolute symlinks into the store. They resolve fine inside the container, so docker run works — but docker exec resolves the user entry host-side with openat2 RESOLVE_BENEATH semantics, which rejects absolute symlinks as escaping their parent. Dev Containers execs a shell server as its first act, so it died before any lifecycle command ran:

Shell server terminated (code: 126, signal: null)
openat etc/passwd: path escapes from parent

The server's node couldn't run. It ships a 121 MB glibc-linked binary wanting /lib/ld-linux-aarch64.so.1; this rootfs has no /lib. The visible error was check-requirements.sh: getconf: command not found — a symptom, not the disease. Fixed with the mechanism Microsoft documents under "Can I run VS Code Server on older Linux distributions?": given VSCODE_SERVER_CUSTOM_GLIBC_LINKER, VSCODE_SERVER_CUSTOM_GLIBC_PATH and VSCODE_SERVER_PATCHELF_PATH, the server patchelfs its own node on first launch and the requirements check short-circuits.

--inputs-from resolves nixpkgs through this flake's lock rather than the ambient registry, so it reuses the glibc the image already links against — marginal cost is patchelf and gcc-lib, not a second libc.

Rust in the dev profile

alyssa@dev had no rustup, cargo or bacon, so the image that exists to be a devcontainer couldn't build a Rust project. modules/dev/rust.nix had been there all along with work.nix as its only importer — because importing it cost 1.6 GiB of closure for lldb (measured; rustup is 94 MiB, bacon 63 MiB). That would have landed on alyssa@dev-x86 too, on the 2012 MBP, which is the disk headroom PR #34 exhausted. lldb isn't a Rust dependency and CodeLLDB bundles its own, so it moves to work.nix and the shared module becomes importable.

Also replaces programs.zsh.initExtra = "rustup update" with an activation-time rustup default stable. The old form ran a network call on every shell — miserable when every VS Code terminal pays it — and was the wrong command besides: rustup update installs nothing when no toolchain exists, leaving cargo as a shim that errors. Guarded with || true, because activation runs at container start and a failed run aborts it after dotfiles are linked, which is the documented route to a container with a perfect prompt and no packages.

Verification

• alyssa@dev and alyssa@dev-x86 evaluate; dev gains exactly rustup + bacon, work keeps rustup + bacon + lldb.
• The exec fix was bisected against the plain image before rebuilding: docker exec on dev returned 126, and 0 once the three files were materialized.
• The glibc fix was proven end-to-end against the exact server build VS Code 1.131.0 pulls — unpatched node fails with a bare "no such file or directory"; patched through these paths, node -e prints v24.18.0.
• Confirmed working: a devcontainer now opens against this image.

Notes

• alyssa@work-dev does not evaluate on aarch64-linux — work.nix carries cocoapods, which is aarch64-darwin only. Verified pre-existing on main; left alone as unrelated.
• The Docker commits are independent of the Rust ones and cherry-pick cleanly to main on their own. Worth landing first if the Rust work needs discussion — until they're in, every fresh dev build breaks Dev Containers for any folder.
• Consumers need "postStartCommand": "/opt/dotfiles/docker/entrypoint.sh true" in their devcontainer config: the CLI starts containers with --entrypoint /bin/sh, so the image ENTRYPOINT and its home-manager activation never run on their own.

Full write-up in docs/solutions/integration-issues/vscode-dev-containers-on-a-nix-rootfs.md, including the two wrong turns.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KBhs11SMRHwp2CGkoGRzRj

[github-actions]

⊕ Entity-level changes

CONCEPTS.md

Status	Type	Name
+	heading	Dev image

Dockerfile

Status	Type	Name
Δ	chunk	lines 61-80
Δ	chunk	lines 81-100
Δ	chunk	lines 101-120
-	chunk	lines 121-130
+	chunk	lines 121-140
+	chunk	lines 141-160
+	chunk	lines 161-180
+	chunk	lines 181-200
+	chunk	lines 201-220
+	chunk	lines 221-223

docs/solutions/integration-issues/vscode-dev-containers-on-a-nix-rootfs.md

Status	Type	Name
+	preamble	(preamble)
+	heading	VS Code Dev Containers fails against the Nix-based dev image
+	heading	Problem
+	heading	Symptoms
+	heading	What Didn't Work
+	heading	Solution
+	heading	Why This Works
+	heading	Prevention
+	heading	Related Issues

home-manager/modules/dev/rust.nix

Status	Type	Name
Δ	orphan	module-level
Δ	binding	home.packages
-	binding	programs.zsh.initExtra
~	orphan	module-level
+	binding	home.activation.rustupDefaultToolchain

home-manager/profiles/dev.nix

Status	Type	Name
-	orphan	module-level
+	orphan	module-level
+	binding	imports

home-manager/profiles/work.nix

Status	Type	Name
Δ	binding	home

Summary: 19 added, 7 modified, 3 deleted across 6 files (1 added orphan, 2 modified orphans, 1 deleted orphan)

_{functions and classes, not lines · sem}

[alycda]

https://code.visualstudio.com/docs/remote/faq#_can-i-run-vs-code-server-on-older-linux-distributions

[alycda]

home-manager/modules/dev/rust.nix:30

P1 — stdenv.cc here reaches ditto, not just the container

work.nix:7 imports this module, so this line puts a C toolchain on the work MacBook's PATH too. On aarch64-darwin it resolves to clang-wrapper-21.1.8 (verified by eval), which means nixpkgs' cc, clang, ld, as and ar land ahead of Apple's — on a profile that also carries cmake, cocoapods, openjdk and flutter-via-puro, all of which shell out to cc/ld and expect Apple clang plus the macOS SDK.

That's outside what this PR set out to do: the commit fixes linker `cc` not found in the container, and as a side effect changes which compiler a laptop build picks up. pkg-config has the same shape, shadowing Homebrew's.

Suggested fix — scope both to Linux:

home.packages = with pkgs; [
  rustup
  bacon
] ++ lib.optionals pkgs.stdenv.hostPlatform.isLinux [
  stdenv.cc
  pkg-config
];

The mechanism is verified; the practical breakage on macOS is inferred — I couldn't test it on the actual machine.

[alycda]

home-manager/profiles/dev.nix:5

P2 — this size justification is now off by ~4x, on the machine it names

The comment says rustup is 94 MiB and that the import "stays cheap for alyssa@dev-x86 on the 2012 MBP, whose disk headroom is the constraint PR #34 blew through." That was accurate when written, before stdenv.cc joined the module in ff59da3.

Measured against cache.nixos.org, deduplicated:

	closure
rustup + bacon	100.9 MiB
+ stdenv.cc	408.0 MiB
marginal	+307.1 MiB

Both container images carry it, alyssa@dev-x86 included. Either the comment gets corrected or the x86 image shouldn't carry the C toolchain — but a comment asserting a constraint the code no longer respects is the worse of the two, because it's what the next reader will trust.

If the stdenv.cc finding lands as lib.optionals … isLinux, this stays true for both Linux images and the number still needs updating.