Mac M1 - after upgrade to Docker Desktop 4.27.1 docker container with java fails with qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[ThomasHurek]

Description

Various docker containers built on arm64 and work fine with docker desktop 4.26.1 and earlier now fail with 4.27.1 with the following error when the Java JVM tries to start:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Rolling back to 4.26.1 solves the problem.

Reproduce

docker run -p 10039:10039 -p 10041:10041 -p 10042:10042 -p 10020:10020 -p 10200:10200 -p 10203:10203 -p 10202:10202 -p 127.0.0.1:7779:7779 --platform=linux/amd64 -d ...
Inside the container check the JVM logs.

Expected behavior

Docker container with Java JVM should be able to start.

docker version

Client:
 Cloud integration: v1.0.35+desktop.10
 Version:           25.0.2
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Thu Feb  1 00:18:45 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.27.1 (136059)
 Engine:
  Version:          25.0.2
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       fce6e0c
  Built:            Thu Feb  1 00:23:21 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    25.0.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1-desktop.4
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.3-desktop.1
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container. (Docker Inc.)
    Version:  0.0.22
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.21
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.0.0
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.3.0
    Path:     /Users/thomashurek/.docker/cli-plugins/docker-scout
WARNING: Plugin "/Users/thomashurek/.docker/cli-plugins/docker-scan" is not valid: failed to fetch metadata: fork/exec /Users/thomashurek/.docker/cli-plugins/docker-scan: no such file or directory

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 6
 Server Version: 25.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.12-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 11.92GiB
 Name: docker-desktop
 ID: 0c2b3f80-2c24-4c41-8a0a-694a04bd78ef
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Diagnostics ID

87F8214C-033B-4E15-8F11-D909E9F5EF70/20240205200938

Additional Info

No response

[dgageot]

Thank @ThomasHurek, sorry for breaking your workflow. I think I know where it comes from. I'll investigate some more tomorrow. Do you have an example of docker image I can use?

[ThomasHurek]

@dgageot Thank you for looking into it. Unfortunately not a public image.

[bradleygore]

@dgageot If it's helpful, I'm also getting a qemu seg fault when trying to run containers based off of postgis/postgis:15-master image. That one is public. I'm currently on macOS Monterey, but am going to update to Sonoma this evening.

db            | performing post-bootstrap initialization ... ok
db            | syncing data to disk ... ok
db            |
db            | initdb: warning: enabling "trust" authentication for local connections
db            | initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
db            |
db            | Success. You can now start the database server using:
db            |
db            |     pg_ctl -D /var/lib/postgresql/data -l logfile start
db            |
db            | waiting for server to start....2024-02-05 20:51:40.289 UTC [126] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
db            | 2024-02-05 20:51:40.292 UTC [126] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db            | 2024-02-05 20:51:40.309 UTC [134] LOG:  database system was shut down at 2024-02-05 20:51:39 UTC
db            | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
db            | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
db            | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
db            |  stopped waiting
db            | pg_ctl: could not start server
db            | Examine the log output.
db exited with code 1

Then when I looked at the container logs after stopping it, I saw these:

2024-02-05 17:24:21 
2024-02-05 17:24:21 PostgreSQL Database directory appears to contain a database; Skipping initialization
2024-02-05 17:24:21 
2024-02-05 17:24:21 2024-02-05 23:24:21.311 UTC [1] LOG:  starting PostgreSQL 15.5 (Debian 15.5-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2024-02-05 17:24:21 2024-02-05 23:24:21.317 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-02-05 17:24:21 2024-02-05 23:24:21.317 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2024-02-05 17:24:21 2024-02-05 23:24:21.382 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-02-05 17:24:21 2024-02-05 23:24:21.449 UTC [70] LOG:  database system was interrupted; last known up at 2024-02-05 22:55:06 UTC
2024-02-05 17:24:21 2024-02-05 23:24:21.994 UTC [72] FATAL:  the database system is starting up
2024-02-05 17:24:22 2024-02-05 23:24:22.309 UTC [70] LOG:  database system was not properly shut down; automatic recovery in progress
2024-02-05 17:24:22 2024-02-05 23:24:22.341 UTC [70] LOG:  invalid record length at 0/14FE148: wanted 24, got 0
2024-02-05 17:24:22 2024-02-05 23:24:22.341 UTC [70] LOG:  redo is not required
2024-02-05 17:24:22 2024-02-05 23:24:22.379 UTC [66] LOG:  checkpoint starting: end-of-recovery immediate wait
2024-02-05 17:24:22 2024-02-05 23:24:22.395 UTC [66] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.028 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2024-02-05 17:24:22 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
2024-02-05 17:24:22 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
2024-02-05 17:24:22 qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[bradleygore]

After upgrading OS to Sonoma this error went away 🥳

[yilinjuang]

Same here.

• docker-compose
• postgis/postgis:11-2.5
• macOS Ventura 13.6.4 (22G513)

Error message

qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Edit:

I downgraded to docker desktop 4.26.1 and the issue seemed to be gone

[jan-osch]

Same here

• qemu: uncaught target signal 11 (Segmentation fault)
• macOS 13.5.2 M1 Max
• I downgraded a few versions, to 4.24.2 and it stopped happening
• The base Image I'm using is ubuntu:focalwith a custom Node.js 18x application

If you experience this issue: downgrade Docker for Mac https://stackoverflow.com/a/64825028/4681920

[jan-osch]

Update: after updating to macOS 14.3 the issue does not occur anymore

[ThomasHurek]

Unfortunately macOS 14.x is not rolled out in our company yet so stuck with 12.x or 13.x.

[zross]

I'm also having this issue, building the container worked yesterday, not today after the update to 4.27.1

-macOS Monterey 12.7, M1

When I downgraded back to 4.26.1 here it worked again.

[jmlapre]

It happens with linux/amd64 docker/dev-environments-default:stable-1 on my M1 Mac.

[dgageot]

@jmlapre and everyone, could you try Docker Desktop 4.27.2 that was released today?

[ThomasHurek]

Just tried and still seeing:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[jasonfine]

Also seeing this after updating to Docker Desktop 4.27.1 in the last few days. A number of our older builds that previously worked over the past years are now suddenly seeing various output similar to this

app-1  | /gems/gems/image_optim_pack-0.6.0-x86_64-linux/lib/image_optim/pack.rb:69: [BUG] Segmentation fault at 0x0000000000000000
app-1  | ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
app-1  |
app-1  | -- Control frame information -----------------------------------------------
app-1  | qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[dgageot]

Hi everyone, here's the status on this one:

• I was able to reproduce the qemu: uncaught target signal 11 (Segmentation fault) error on 4.27.2, with Rosetta disabled.
• When Rosetta is enabled, it all works fine
• On Docker Desktop 4.26.1, the very old version of Qemu that we had also seems to work fine. We updated Qemu to a more recent version in 4.27.0

Could you all try and activate Rosetta, in 4.27.2, and tell me if that works for you too?
I'll try QEMU 8.1.5 and 8.2.1 to see if they fixe the issue. (We currently ship 8.1.4)

[magnolo]

Hey everyone,

i just stumbled across the same error after updating to version 4.27.1 this morning and then to 4.27.2.

@dgageot after enabling Rosetta the error seems to be gone.

[ThomasHurek]

@dgageot When you mention enabling rosetta I have rosetta enabled in my mac - is there a docker desktop setting to switch to rosetta instead of qemu? I am on macOS 12.7.

[jasonfine]

Same - not seeing this configuration option in the Docker Desktop preferences.

[hubofgitongithub]

@ThomasHurek @jasonfine I do see the Use Rosetta for x86/amd64 emulation on Apple Silicon option in the general settings of docker desktop on v4.27.1. Also worked for me!

[Gogoro]

Upgraded to macOS 14.3.1 and docker-compose started running like a 👸🏻 again 👍🏻

[Nikoplezi]

Yup, upgrade to Mac OS 14 did the trick for me too, thanks

[dgageot]

@ThomasHurek @jasonfine Don't you see these settings?

[ThomasHurek]

This is how it looks like for me:

[NiklasBr]

On Mac OS 14.3.1 with Docker Desktop 4.27.2 PHP container fails like this with containerd on:

A. With Rosetta emulation disabled

2024-02-14 11:39:10 [14-Feb-2024 11:39:10] WARNING: [pool www] child 115 said into stderr: "qemu: uncaught target signal 11 (Segmentation fault) - core dumped"
2024-02-14 11:39:10 [14-Feb-2024 11:39:10] WARNING: [pool www] child 115 exited on signal 11 (SIGSEGV) after 241.836107 seconds from start

B. Enabled Rosetta

2024-02-14 11:49:25 [14-Feb-2024 11:49:25] WARNING: [pool www] child 198 exited on signal 11 (SIGSEGV) after 39.904495 seconds from start

In other words there is no Qemu error with Rosetta enabled, but the container crashes consistently nonetheless with v4.27.x.

[dgageot]

This is how it looks like for me:

@ThomasHurek Sorry, I checked and you have to be at least on macOS 13 to enable Rosetta.

[dgageot]

@ThomasHurek I understand those are private images. Can you reproduce with their base images?

[hutchkintoot]

@dgageot the 4.28 resolved the issue for us. Thanks!

[NiklasBr]

I think it resolved the Segmentation Fault issue here!

(Though it introduced a new one: Warning: include(vendor/symfony/console/Event/ConsoleErrorEvent.php): Failed to open stream: Too many open files which does not happen in v4.26.1)

[dankarran]

I was running into similar issues with a Postgres image, but upgrading to Docker Desktop 4.28 seems to have fixed it for me on Ventura.

[unkrich]

v4.28.0 on MacOS Sonoma solved this issue for me as well regardless of whether I have Rosetta enabled 👍

[AllanOricil]

updating docker "desktop" to v4.28.0 isn't the solution. I did it, and nothing changed.

[alessfg]

I am running into a some similar issues. Emulated platforms fail when using 4.27.x and 4.28. Depending on whether the settings I enable I get a segmentation fault, an exec format error, or a failed to extract layer/failed to get reader from content store error. Rolling back to 4.26.1 seems to have done fixed the issue.

[dubo-dubon-duponey]

Docker Desktop v4.28.0
macOS 14.3.1
Intel macbook

QEMU still segfaults on a simple apt-get install.

Cannot install Rosetta (older macbook pro) - docker4desktop is pretty bust for us at this point...

[Darep]

I was also getting this error with Docker Desktop 4.28.0, on macOS Ventura 13.6.6. Checking "Use Rosetta for x86_64/amd64 emulation" fixed it!

[am11]

"Use Rosetta for x86_64/amd64 emulation"

Fixed for me too, but unfortuantely it doesn't help with arm32 containers which rely on qemu. I think we are running into this mmap issue in qemu 8+ https://gitlab.com/qemu-project/qemu/-/issues/1890.

[ryanlambert-wk]

EDIT: Updating MacOS to Sonoma 14.4.1 seems to have fixed this.

I just upgraded docker desktop to v4.29.0 and am running into this issue as well. M2 Max running MacOS Venture 13.5.2.

Container Details:
image: mysql:5.7
platform: linux/amd64

% docker info
Client:
 Version:    26.0.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.13.1-desktop.1
    Path:     /usr/local/lib/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.26.1-desktop.1
    Path:     /usr/local/lib/docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container. (Docker Inc.)
    Version:  0.0.27
    Path:     /usr/local/lib/docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /usr/local/lib/docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.23
    Path:     /usr/local/lib/docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /usr/local/lib/docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.1.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.6.3
    Path:     /usr/local/lib/docker/cli-plugins/docker-scout

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 26.0.0
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.22-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 12
 Total Memory: 7.657GiB
 Name: docker-desktop
 ID: f9955f57-22e3-4d6f-9a91-eee4730ead10
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/ryanlambert/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

[phil-lavin]

Similar findings here. qemu segfault on linux/amd64 docker buildx. The segfault was when running ./configure on the codebase at https://github.com/signalwire/freeswitch. Segfault was fixed by upgrading to MacOS Sonoma.

That said, at the exact point it previously segfaulted, I now get:

56.75 checking for erl... /usr/bin/erl
56.75 checking erlang version... 13.1.5
56.97 checking erlang libdir... configure: error: failed

Seems to be linked to this erlang issue, which they are blaming on a bug/feature of qemu: erlang/otp#5625

[omawnakw]

Same issue.
I have rosetta2 installed on my 12.6.3 Monterey on M1 pro.
There is no such thing like Use Rosetta for x86/amd64 emulation on Apple Silicon neither in General nor in experimental options in the latest Docker desktop 4.30.0. Sounds like a plan:

• break qemu
• remove an option to use Rosetta2

So I've downgraded to Docker Desktop 4.26.0 (130397) - works fine.

[estemendoza]

Same issue. I have rosetta2 installed on my 12.6.3 Monterey on M1 pro. There is no such thing like Use Rosetta for x86/amd64 emulation on Apple Silicon neither in General nor in experimental options in the latest Docker desktop 4.30.0. Sounds like a plan:

* break qemu

* remove an option to use Rosetta2

So I've downgraded to Docker Desktop 4.26.0 (130397) - works fine.

Thanks! I installed that version and it seems to be working fine now.

[Rajesh1213]

Same Issue:

• Rosetta 2, macOS Monterey on chip M1 Pro.
• Mysql.5.7.44
• Docker Desktop 4.30.0 (149282).
• Ran into the issue below:

2024-06-12 11:35:08 2024-06-12 11:35:08+01:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.44-1.el7 started.
2024-06-12 11:35:09 2024-06-12 11:35:09+01:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2024-06-12 11:35:10 2024-06-12 11:35:10+01:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.44-1.el7 started.
2024-06-12 11:35:11 2024-06-12 11:35:11+01:00 [Note] [Entrypoint]: Initializing database files
2024-06-12 11:35:11 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
2024-06-12 11:35:11 /usr/local/bin/docker-entrypoint.sh: line 236:   219 Segmentation fault      "$@" --initialize-insecure --default-time-zone=SYSTEM

• Downgraded to 4.26.0 (130397)
• Works fine.

[Tigatok]

I have the same issue, I downgraded docker to 4.26.0 and it works for me too. I am not sure what would be the difference.

Rosetta 2, macOs sonoma 14.5, M3 Max

[mahdikhashan]

I had the same issue on mac m1 with monterey, updated to sonoma and docker 4.32.0 and it works now.

[dwatteau]

Same thing here on Monterey, where Rosetta 2 is enabled. Docker Desktop 4.32.0 (157355) still triggers the segfaults in old distros with older libc, while Docker Desktop 4.26.1 is fine.

Docker Desktop 4.32.0 ❌

$ sw_vers ; arch
ProductName:	macOS
ProductVersion:	12.7.5
BuildVersion:	21H1222
arm64

$ docker version
Client:
 Version:           27.0.3
 API version:       1.46
 Go version:        go1.21.11
 Git commit:        7d4bcd8
 Built:             Fri Jun 28 23:59:41 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.32.0 (157355)
 Engine:
  Version:          27.0.3
  API version:      1.46 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       662f78c
  Built:            Sat Jun 29 00:02:44 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.18
  GitCommit:        ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
 runc:
  Version:          1.7.18
  GitCommit:        v1.1.13-0-g58aa920
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker run -ti --platform linux/amd64 centos:6.10 yum makecache
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

then, reverting to Docker Desktop 4.26.1 ✅

$ sw_vers ; arch
ProductName:	macOS
ProductVersion:	12.7.5
BuildVersion:	21H1222
arm64

$ docker version
Client:
 Cloud integration: v1.0.35+desktop.5
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:04:20 2023
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.26.1 (131620)
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:08:15 2023
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.25
  GitCommit:        d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
 runc:
  Version:          1.1.10
  GitCommit:        v1.1.10-0-g18a0cb0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker run -ti --platform linux/amd64 centos:6.10 yum makecache
Loaded plugins: fastestmirror, ovl
[...]

[jklaiho]

The "reverse" is still broken: on an Intel Mac, with Sonoma 14.5 and Docker 4.33.0, Qemu still segfaults during builds of an ARM64 image.

[peidrao]

I had the same issue on mac m2 14.5, downgrade the docker desktop to 4.26.0 and it works now.

[prodehghan]

Here is the download link for version 4.26.0:
https://desktop.docker.com/mac/main/arm64/130397/Docker.dmg

[rajivml]

I had the same issue on Mac M1, Docker 4.33 , downgrading docker to 4.26.0 helped fix the issue

[rtrahin]

Same issue Thank you for the Link downgraded from latest to 4.26.0 resolved my issue

[enzoxic]

Docker isn't the most suitable option for M1, M2 Max, or ARMX64 architectures overall. Although efforts are being made to create a bridge to utilize the GPU in our devices, the common solution is to use virtual machines running Linux or Windows to access Docker services that operate with CUDA GPU servers. The main challenge lies in figuring out how to connect all these technologies and get them to work in unison. An Orin kit could assist, but that seems too simple to me ;)