Build1 publisher3 min readPublished
Debian 13 boots as an Apple container machine only after a Dockerfile supplies /sbin/init
A Linux guest under Apple's container CLI cannot reach Metal. So the setup that works keeps the app in a Debian machine and calls Ollama on the Mac at 192.168.64.1. One run there measured 45.2 tok/s.
The Engineer · Build desk
What happened
- Creating a Debian 13 machine with Apple's container CLI reports success, the machine appears, and it never boots. The command line says nothing about why.
- The guest can only reach the Mac at the fixed address 192.168.64.1, so Ollama has to listen on 0.0.0.0, and brew services restart silently undoes that binding.
- Called from inside the Debian machine, gemma4:e2b answered at 45.2 tok/s with the model loaded entirely on the Mac's GPU, in a run dated 2026-09-13.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The Linux guest sees virtual CPUs and virtual devices and no Metal, so anything you run inside the VM cannot touch the GPU; the only route to it is a network call back to macOS.
- exposure Binding Ollama to 0.0.0.0 opens it to every interface on the Mac, not just the VM, and the CLI has no port forwarding to scope the listener down.
- cost 8 GB of memory is the budget the whole design answers to: one model, one 2 GB machine, and the image builder shut down whenever it is not building.
- decision Adoption needs a Mac on macOS 26 or newer and a person at a real Terminal for two steps, so this install cannot be handed to an unattended provisioning script.
`container machine create debian:13` creates a machine that never boots, and the command line offers a success message instead of a reason [4]. It is one of three failures in this dev.to walkthrough that return success. `brew services restart` drops the Ollama binding the VM needs [12]. A low token cap on Gemma 4 returns an empty reply, because the model thinks before it answers and the budget goes to the thinking [16].
The init failure is structural. A container never boots, so its image does not need an init [7]. A machine boots a kernel, and Apple's `/sbin.machine/init` ends in a hard-coded `exec /sbin/init` [6]. The official debian:13 image has no `/sbin/init`, so a machine made from it stays stopped forever [5]. The error message does exist, in `container machine logs`, which prints `/sbin.machine/init: 74: exec: /sbin/init: not found` [6]. Apple's own docs use alpine:3.22, which boots because BusyBox happens to provide the file [8]. The fix is a Dockerfile over debian:13 that installs `systemd-sysv`, plus two more lines so every machine stops sharing one machine-id [9]. That image is also missing `ps`, `ip`, `less` and `sudo` [10].
You pick a machine over a container for persistence: yesterday's packages are still installed, the source tree is already mounted, and services start under systemd [1]. The images are ordinary OCI images, so Docker Hub works. But there is no Docker Desktop, no `dockerd` and no containerd process: each container and each machine runs in its own lightweight VM under Apple's launchd agents [22].
The Linux guest gets virtual CPUs and virtual devices and no Metal access, so the GPU half of this is a network problem [2]. The VM reaches the Mac at 192.168.64.1, with no port forwarding and no hostname to look up [11], and Ollama has to listen on 0.0.0.0 for the call to land [12].
From inside Debian, `gemma4:e2b` answered at 45.2 tok/s with the model loaded 100 percent on the GPU, in a run dated 2026-09-13 [13][14]. The walkthrough does not say which chip the Mac has [27]. For that figure to transfer you would need the same model at the same quantization, a comparable memory budget, and the weights fully resident on the GPU rather than spilling.
`container system start` stops to ask about downloading a Linux kernel. `container system kernel set --recommended` answers that in advance by pulling the Kata Containers kernel, and the kernel has to be in place before anything else runs [21]. The installer is a signed `.pkg`. `pkgutil --check-signature` on version 1.4.1 reports `Developer ID Installer: Apple Inc. - Containerization (UPBK2H6LZM)` with notarization trusted by the Apple notary service [20]. Budget about 1.4 GB of disk for the Debian machine image, plus the model [19].
Copy the sequencing. Steps 0 through 5 build the VM and steps 6 through 9 add the model, and the two halves are independent. Step 7 tests Ollama on the Mac before a VM is in the path, and that is what makes a failure at step 9 easy to place [23].
What to watch
- Whether a future container release adds port forwarding or a host name. Either one would let Ollama bind to something narrower than 0.0.0.0.
- Whether Apple documents the /sbin/init requirement for machine images, or ships a Debian image that boots unmodified.
- A repeat of the gemma4:e2b run on a Mac with a stated chip and more memory. That would separate the model's contribution from the machine's.