Crash with exit code 132 on an Apple M4 VM

Symptom: VectorStep (or the Gateway) is running inside a Linux VM on an Apple M4 Mac — Multipass is the case we’ve seen, typically hosting a local Kubernetes cluster — and the container crashes immediately on start. In Kubernetes it lands in CrashLoopBackOff with:

Last State:     Terminated
  Reason:       Error
  Exit Code:    132

Exit code 132 is 128 + 4: the process was killed by SIGILL, an illegal instruction. It’s tempting to blame the image, or whichever native library was loading when it died (usually cryptography, since it loads early) — but the same arm64 image runs cleanly on other Apple Silicon VMs and on arm64 Linux servers. The problem is the VM, not VectorStep.

What’s actually going on

The M4 does not implement SVE/SVE2 (ARM’s scalable vector extensions), but some hypervisor setups on M4 Macs pass a CPU description through to the Linux guest that claims it does. OpenSSL — bundled inside Python’s cryptography package — checks the kernel’s CPU feature flags at startup, sees SVE2, picks its SVE2-optimised code path, and the first SVE2 instruction it executes kills the process.

Anything that picks code paths from those flags can be hit, not just VectorStep — VectorStep is simply often the first thing in a fresh cluster that exercises it.

1. Confirm it

On the Mac, check the chip:

sysctl -n machdep.cpu.brand_string      # Apple M4 (or M4 Pro/Max)

Then look at the CPU flags the VM advertises (substitute your VM name):

multipass exec <vm-name> -- grep -m1 Features /proc/cpuinfo

If that line contains sve2, svei8mm or svebf16, this is your problem — the M4 has none of those. (A telltale sign of a misreported CPU: sve2 listed without plain sve.)

2. Unblock now: turn off OpenSSL’s CPU-specific paths

Set OPENSSL_armcap=0 on the crashing workload. This tells OpenSSL to ignore the advertised features and use its generic code:

kubectl -n vectorstep set env deployment/vectorstep OPENSSL_armcap=0
kubectl -n vectorstep set env deployment/vectorstep-gateway OPENSSL_armcap=0   # if the Gateway is affected too

(Use whatever namespace you deployed into — vectorstep is the one the Kubernetes tutorial uses. Without -n the command runs against default and fails with NotFound.) The crash leaves no log output — the process dies before it can write any — so the exit code is the only clue: kubectl -n vectorstep get pod -l app=vectorstep -o jsonpath='{.items[0].status.containerStatuses[0].lastState.terminated.exitCode}'.

For Docker, pass -e OPENSSL_armcap=0 (or add it under environment: in Compose). If the pod comes up after this, the diagnosis is confirmed. The performance cost is negligible for VectorStep’s workload.

3. Fix it properly: hide SVE from the VM’s kernel

The env var only protects the workloads you set it on. To fix the VM itself, tell the Linux kernel to ignore SVE (and SME, a related extension) so nothing inside the VM is offered them. Run this in every VM that hosts cluster nodes:

multipass exec <vm-name> -- sudo sed -i \
  's/^GRUB_CMDLINE_LINUX_DEFAULT="/&arm64.nosve arm64.nosme /' /etc/default/grub
multipass exec <vm-name> -- sudo update-grub
multipass restart <vm-name>

Re-run the grep Features check from step 1 — the sve* flags should be gone, and you can remove OPENSSL_armcap again.

It’s also worth keeping Multipass and macOS up to date — this is a host/hypervisor issue, and newer releases may stop advertising the features in the first place.

What not to do

Don’t try to work around this by pinning an older cryptography or rebuilding the image from source. The published image is correct; changing it would only mask one symptom of a VM that will trip up other software too.

Where next

Kubernetes installation — the shipped manifests this page’s kubectl commands assume.
Status and support — if you hit exit code 132 on hardware other than an M4 VM, that’s worth reporting.