/check creates core dump in in Lima VM with Rosetta

[eraserix]

Description

Everytime I create an amd64 image on a Mac, a core dump is created in /. The core is created from the `/check program that is run during container init.

I use a Lima VM on an M4 Mac with Rosetta emulation for amd64.

gdb -c /core.103678 -q -batch
[New LWP 103678]
Core was generated by `/check /check'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x0000800000088d14 in ?? ()

I don't see any ill effect except for / to be full of core files after a while. Maybe the program can be made to not dump core?

Reproduce

This issue reproduced reliably inside my environment (macOS 26.6.1, M4 Max, Lima Debian 13 VM)

1. Create a Dockerfile with the following content:

FROM --platform=linux/amd64 alpine:3.20
RUN uname -m

2. docker buildx build --progress=plain --no-cache --platform linux/amd64 -f Dockerfile.checktest .
3. A new core is placed in my /

Expected behavior

I expect the check utility to not create a core dump if everything appears to be working fine.

docker version

Client: Docker Engine - Community
 Version:           29.7.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        a7dcaa6
 Built:             Wed Aug  5 18:28:24 2026
 OS/Arch:           linux/arm64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       6a43e3d
  Built:            Wed Aug  5 18:28:24 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.3.3
  GitCommit:        aad11006b869517fcd3009450b6f82da282e1a9b
 runc:
  Version:          1.4.3
  GitCommit:        v1.4.3-0-gbb14dabe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    29.7.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.36.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.5.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 12
  Running: 2
  Paused: 0
  Stopped: 10
 Images: 33
 Server Version: 29.7.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /run/cdi
 Discovered Devices:
  cdi: lima-vm.io/rosetta=cached
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: aad11006b869517fcd3009450b6f82da282e1a9b
 runc version: v1.4.3-0-gbb14dabe
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.96+deb13-cloud-arm64
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: aarch64
 CPUs: 8
 Total Memory: 19.51GiB
 Name: lima-wz3j1q-lima
 ID: 3802ec47-3424-4d1a-9fda-f72b294f0846
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http://192.168.5.2:3128
 HTTPS Proxy: http://192.168.5.2:3128
 No Proxy: localhost,127.0.0.1,local,pnet.ch,host.lima.internal
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Registry Mirrors:
  https://docker.repo.pnet.ch/
 Live Restore Enabled: false
 Firewall Backend: iptables
  EnableUserlandProxy: true
  UserlandProxyPath: /usr/bin/docker-proxy

Additional Info

No response

[tonistiigi]

This used to happen because rosetta required /proc that doesn't exist in archutil chrooted environment. But I think Apple fixed it (years ago).

[eraserix]

This used to happen because rosetta required /proc that doesn't exist in archutil chrooted environment. But I think Apple fixed it (years ago).

I'm on macOS 26.6.1, so I should have a more or less up-to-date version of Rosetta 😕