[vaind]

Draft until DevInfra answers the open questions below.

Why

devenv pins colima 0.8.1, whose VM image runs Linux 6.8.0-50. On Apple M4/M5 that kernel tells containers they have SVE2, and they crash with SIGILL. #236 fixes existing VMs in place. This PR makes new VMs correct from the start.

colima 0.10.3's default image runs 6.8.0-117-generic (Ubuntu 24.04.4). On an M4 Pro it has no sve*/sme* hwcaps, and import cryptography.hazmat.bindings._rust works in an arm64 container.

New VMs also get colima 0.9's separate data disk. Recreating a VM then no longer has to lose containers and volumes (colima delete keeps them unless you pass --data).

Changes

• colima v0.8.1 → v0.10.3, the latest release. The sha256s match upstream's .sha256sum assets.
• lima 1.0.3 → 2.2.1. colima 0.10 writes rosetta under vmOpts.vz.rosetta, which only lima ≥ 2 understands. lima 1.0.3 drops it without an error.
  • lima 2 looks for its guest agents and drivers relative to limactl, in ../share/lima and ../libexec/lima. So devenv now installs upstream's release tarball as a prefix under ~/.local/share/sentry-devenv, instead of picking files out of a Homebrew Sonoma bottle. Those bottles were only needed while devenv supported macOS 14.
  • Upstream's tarball only has the guest agent for the host's arch (the others ship separately). That's all devenv's native-arch VMs need, but the Homebrew bottle had both.
  • uninstall() also removes the lima 1 layout from bin/.
  • install_global() reinstalls if a guest agent directory is missing, the same lesson as fix(tenv): reinstall when a shim is missing #231.
• --cpu → --cpus. --cpu was renamed in colima 0.8.2 and is still accepted as a hidden alias.
• --mount-inotify is now passed explicitly. colima 0.10.2 turned it off by default, and this keeps new VMs consistent with existing ones.
• limaDns fixer restarts dnsmasq on VMs whose image ships it, which colima ≥ 0.9 makes the resolver, and systemd-resolved otherwise. It checks that dnsmasq is installed rather than running, so a crashed dnsmasq gets restarted too.

⚠️ What existing users will see

There is no automatic migration, and nothing is deleted. I tested it: I started a VM created by colima 0.8.1, holding a named volume, a container and pulled images, using these binaries and devenv's flags.

• The VM keeps working. It keeps its old disk layout (no data disk) and its old kernel. So fix(colima): Upgrade Colima/Lima and repair M4+ SVE without data loss #236 is still what fixes SIGILL on existing VMs.
• Images and containers become invisible. Since 0.8.3, colima writes features.containerd-snapshotter: true to /etc/docker/daemon.json on every start, so docker switches to the containerd image store. Afterwards docker images and docker ps -a were empty.
  • The old overlay2 data, 155 MB in my test, stays on disk but is orphaned.
  • Named volumes survived with their data intact.
  • For devservices users, that means re-pulling every image and recreating containers. Data in named volumes is kept.
• There's no going back. lima ≥ 2.1 converts the instance's disk on start, so downgrading to lima 1.x afterwards isn't supported.

Open questions for DevInfra

1. Image store switch. Is the switch acceptable, maybe with an announcement and devservices up re-pulling? Or should devenv keep existing VMs on overlay2 by setting docker.features (buildkit only) in ~/.colima/default/colima.yaml, given that colima has no flag for it? The containerd store is docker's default for new installs now.
2. Orphaned overlay2 data. Should devenv tell people to recreate their VM eventually (colima delete + devenv colima start) to get the data disk and drop the orphaned data?
3. --mount-inotify. Does any repo still rely on file events reaching containers? If not, matching colima's new default (off) is cheaper.
4. Rollout. Ship together with or after fix(colima): Upgrade Colima/Lima and repair M4+ SVE without data loss #236, so existing M4/M5 users get their kernels fixed regardless?

Testing

• uv run pytest: 143 passed. New tests:
  • tests/lib/test_limactl.py covers the prefix layout, reinstalling over a previous install, removing the lima 1 layout, and reinstalling when a guest agent directory is missing but not when the install is complete.
  • tests/checks/test_limaDns.py covers which resolver gets restarted, including when dnsmasq is installed but not running.
• End to end on an M4 Pro (macOS 26.7), in a throwaway HOME:
  • Fresh VM: install_global() replaced a colima 0.8.1 + lima 1.0.3 install, downloading and checking both sha256s. Then devenv colima start created a fresh VM. It runs kernel 6.8.0-117-generic with clean hwcaps. Rosetta works (--platform linux/amd64 gives x86_64). It has mountInotify: true, a 20 GiB root disk plus a 512 GiB data disk, and docker 29.5.2.
  • Checks: devenv doctor passes, and the limaDns fix worked on the dnsmasq VM. That run used an earlier systemctl is-active probe. The systemctl cat dnsmasq.service probe that replaced it picks systemd-resolved on a colima 0.8.1 VM, but hasn't been re-run on a dnsmasq VM yet.
  • Existing VM: the upgrade behavior described above.

🤖 Generated with Claude Code

[joshuarli]

The Colima/Lima upgrade and compatible fixes have been consolidated into the canonical PR #236: #236. This PR is superseded and is being closed without merging.