Velo Workspaces
Start with what fails
Be precise about the failure first. "Command not found" or a package manager with nothing to install is a different problem from a binary that exists but won't start, which is different again from a docker pull that can't find a matching image. The error usually tells you which of the four cases below you're in. The mistake is reaching for the same fix, usually "just emulate it", whichever case it is.
1. The package has no arm64 build
Check that it's really missing before working around it. A distribution's arm64 ports repository doesn't always carry every amd64 package, and pulling an amd64 .deb by hand for a package that doesn't exist on arm64 gets you a 404, not an install. The Ubuntu post shows where that bites. If there's no native build, building from source often works; watch for hard-coded x86_64 in build scripts or target triples, which look like a compatibility failure but are just a script nobody updated for a second architecture.
2. It's one binary, not a whole ecosystem
A single, self-contained x86-64 executable, such as a CLI tool or a compiled binary someone handed you, is what Rosetta for Linux is for. The setup is here: it translates that one binary inside a native, accelerated arm64 guest, and it's much faster than any of the emulation options below. It stops being the right tool once the binary pulls in x86-64-only shared libraries or a dependency tree that also isn't built for arm64. Then you're back in case 1 or 3.
3. It's a container image
An amd64-only Docker image has its own mechanism: QEMU emulation by default, and sometimes Rosetta if it's already set up in the same guest. That post covers it. Keep it separate from case 2. A container that can't find your architecture in its manifest is a Docker and registry problem, which update-binfmts alone won't fix, even though the same kernel facility is involved in the end.
4. It really needs a different CPU architecture
The rare case: software with hand-written x86 assembly or SIMD intrinsics, an out-of-tree kernel module with no arm64 port, or a requirement to verify behavior on the CPU your users run rather than a translated stand-in. None of the above helps. That's full QEMU emulation of the other architecture, with the performance cost that comes with it, or a real x86-64 machine somewhere in the loop.
The triage, short version
| Symptom | Likely case | Fix |
|---|---|---|
| Package manager finds nothing | 1: no native build | Confirm it's missing, then build from source or find an alternative |
| One binary won't execute | 2: a single x86-64 binary | Rosetta for Linux |
docker pull can't find your architecture | 3: a container image | amd64 image emulation |
| Needs a real x86 CPU to behave correctly | 4: a true architecture dependency | Full QEMU emulation |
Related reading: Rosetta 2 in Linux VMs, running x86 Docker images on an Apple Silicon Mac, and ARM64 vs. x86-64 on Apple Silicon for the broader picture. Or download Velo Workspaces and try it yourself.