[Docker Desktop for Mac] - Support for running x86-64 binaries with Rosetta 2

Tell us about your request
Support Rosetta 2 for running x86-64 Linux binaries on Apple Silicon
Which service(s) is this request for?
Docker Desktop for Mac
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Ensure that users can run their Intel-based workloads on Apple Silicon, using Rosetta 2
Are you currently working around the issue?
Docker Desktop users can currently use QEMU for this

@christophermclellan With this feature, we should be able to use Microsoft SQL server for Linux on M1. This would be awesome!

we should be able to use Microsoft SQL server for Linux on M1

If this is true you're going to make many long-suffering mssql users very happy. Very much looking forward to this.
Due to the presumed qemu "issue" there is actually no workaround for running that image on arm64. (yes, I know about colima. no, it's not a viable workaround)

@christophermclellan Are you able to provide some more detail on the plans for implementing this feature?

@thisisthekap I tested x86_64 mssql-server translated by Rosetta 2 in a Linux VM. This was obviously outside docker. My initial testing sadly showed that Rosetta 2's user mode emulation in Linux is too slow to be practically usable, at lest for MS SQL Server.

Another use case for running Intel on Rosetta 2 over a native amd64 image is because of dev/prod parity with the server for example - see https://github.com/heroku/stack-images/issues/194

@christophermclellan Are you able to provide a timeline describing when this feature is going to be implemented?

Any development here? Ball-park timeline for this?

Please add support for Apple M1 silicon.

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

rosetta seems to works quite well, tested using manual docker setup on macbook m1 air
root@ub1:~# uname -a
Linux ub1 5.15.0-47-generic #51-Ubuntu SMP Fri Aug 12 08:18:32 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
root@ub1:~# mount | grep rose
rosetta on /mnt/rosetta type virtiofs (rw,relatime)
root@ub1:~# ps -ef | grep rose
2001        5803    2728  1 14:28 ?        00:00:42 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibftlserver -c /config/ftl.yaml -n ftlserver-0
2001        5882    5803  3 14:28 ?        00:01:32 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibmux --realmserver http://<IP_ADDRESS>:30080 --client-label ftl.ftlserver-0 --external-address ftlserver-0@ftlserver-0.ftlservers:30080 --bind-address *:30080 --peer-muxes ftlserver-0@ftlserver-0.ftlservers:30080 --trace warn
2001        5983    5803 42 14:28 ?        00:18:50 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibrserver --server.label realm.ftlserver-0 --data /data/ftlserver_0_data --http <IP_ADDRESS>:0 --ftl ftlserver-0.ftlservers:30083 --gui <IP_ADDRESS>:0 --client.url http://<IP_ADDRESS>:30080 --ftlserver.urls ftlserver-0@ftlserver-0.ftlservers:30080 --ftlserver.name ftlserver-0
1001        6187    4686  2 14:28 ?        00:00:56 /mnt/rosetta/rosetta /etc/alternatives/jre/bin/java -javaagent:/jmx_prometheus_javaagent-0.16.1.jar=8080:/opt/config/config.yaml -Djava.util.logging.config.file=logging.properties -Djava.security.auth.login.config=/opt/activemq/conf/login.config -Dcom.sun.management.jmxremote -Djava.awt.headless=true -Djava.io.tmpdir=/opt/apache-activemq-5.15.2//tmp -Dactivemq.classpath=/opt/apache-activemq-5.15.2//conf:/opt/apache-activemq-5.15.2//../lib/: -Dactivemq.home=/opt/apache-activemq-5.15.2/ -Dactivemq.base=/opt/apache-activemq-5.15.2/ -Dactivemq.conf=/opt/apache-activemq-5.15.2//conf -Dactivemq.data=/opt/apache-activemq-5.15.2//data -jar /opt/apache-activemq-5.15.2//bin/activemq.jar start
2001        6337    5803  2 14:28 ?        00:01:08 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibpserver --name default_ftlserver-0 --data /data/ftlserver_0_data --realmserver http://<IP_ADDRESS>:30080
2001        6377    4463  3 14:28 ?        00:01:36 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgkeeper -r http://ftlserver-0.ftlservers:30080 -n keeper-0 -g VirtueleTreinInfoStore
2001        6419    2486  5 14:28 ?        00:02:31 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgproxy -r http://ftlserver-0.ftlservers:30080 -n proxy-0 -g VirtueleTreinInfoStore
2001        6421    3376  0 14:28 ?        00:00:09 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgadmind -r http://ftlserver-0.ftlservers:30080 -l :30081
2001        6734    4895  3 14:28 ?        00:01:24 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgnode -r http://ftlserver-0.ftlservers:30080 -n cs-01-node-0 -g VirtueleTreinInfoStore
joost       7107    3827  0 14:28 ?        00:00:19 /mnt/rosetta/rosetta /opt/tibco/ems/8.6/bin/tibemsd -config /shared/ems/config/emsserver-svc.json
root        7141    3827  0 14:28 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /runPromCollector.sh
root        7159    7141  0 14:28 ?        00:00:18 /mnt/rosetta/rosetta /usr/bin/java -cp emsStatsLogger.jar:/ems/lib/tibjmsadmin.jar:/ems/lib/jms-2.0.jar:/ems/lib/tibjms.jar EmsStatsPromCollector -config /config/servers.xml -interval 60 -job TIB-EMS-vtlocal -debug -nolog
48          9352    9190  0 14:31 ?        00:00:00 /mnt/rosetta/rosetta /bin/bash /treinviewer/scripts/run.sh
root        9368    9352  0 14:31 ?        00:00:00 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48          9369    9368  0 14:31 ?        00:00:00 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48          9370    9368  0 14:31 ?        00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48          9371    9368  0 14:31 ?        00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48          9372    9368  0 14:31 ?        00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48         10480    9368  0 14:35 ?        00:00:03 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
root       13340   13162  0 14:38 ?        00:00:01 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root       17114   16961  0 14:47 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root       17357   17159  0 14:47 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root       17374   17193  0 14:47 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
2001       21600   20248 12 14:58 ?        00:01:54 /mnt/rosetta/rosetta /opt/tibco/be/6.0/bin/be-engine --propFile /opt/tibco/be/6.0/bin/be-engine.tra --propVar AS_DISCOVER_URL=tcp://masterdataengine-74c44cd5c7-rg8bx:50000 --propVar AS_LISTEN_URL=tcp://masterdataengine-74c44cd5c7-rg8bx:50000 --propVar jmx_port=5555 -n VTMasterDataEngine -c /opt/tibco/be/application/MasterData.cdd -u VTMasterDataEngine -p beprops_all.props /opt/tibco/be/application/ear/be_masterdata-1.66.0.ear --innerProcess
472        25099   24317  0 15:04 ?        00:00:04 /mnt/rosetta/rosetta /usr/share/grafana/bin/grafana-server --homepath=/usr/share/grafana --config=/etc/grafana/grafana.ini --packaging=docker cfg:default.log.mode=console cfg:default.paths.data=/var/lib/grafana cfg:default.paths.logs=/var/log/grafana cfg:default.paths.plugins=/var/lib/grafana/plugins cfg:default.paths.provisioning=/etc/grafana/provisioning
root       28779   13340  1 15:12 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheenginediscoverynode-svc 50000
root       28780   17114  1 15:12 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root       28781   17374  1 15:12 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root       28783   17357  1 15:12 ?        00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root       28785   23820  0 15:12 pts/2    00:00:00 grep --color=auto rose

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

Thank you Christopher!

Is there a way to force a container to run using QEMU regardless of host platform. I am attempting to re-create a problem that M1 Macs are having with a container. I would like to recreate the issue on my x64 computer but can't I assume because it isn't running in QEMU.

I need to dev/run python on a x86_64 docker on M1 Macs. Looking forward to it!

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

Heya, any news? 😄

Is there any beta version can try it?

If it helps anyone, when running a fedora 36 VM using UTM with rosetta mounted to /media/rosetta/rosetta the following command allowed docker to use it for x86_64 images
echo ':rosetta-x86_64:M:0:\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00:\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/media/rosetta/rosetta:CF' > /proc/sys/fs/binfmt_misc/register

@wowditi Sounds awesome! Are you able to provide some more detail on how to setup & use docker in this scenario?

@thisisthekap start an aarch64 fedora 36 VM (https://getfedora.org/en/workstation/download/) using UTM and enable "Use Apple Virtualization" and "Enable Rosetta". Once the installation is complete install docker according to the instructions (https://docs.docker.com/engine/install/fedora/). Then mount the Rosetta binary as described by the UTM documentation https://docs.getutm.app/advanced/rosetta/. Fedora does not include an "/usr/sbin/update-binfmts" script so instead of that you need to use the above command. Then you should be able to start docker x86_64 images and you can check using "ps" that every command is started with /media/rosetta/rosetta and that the performance is a lot better than qemu-user-static (which is what docker desktop uses).
I tried to get it to work in docker desktop using a simple mount, but I think the problem is that the VM needs to run in a special memory mode which I could not figure out how to do unfortunately.

@wowditi Concerning using the new vm in a transparent way: Would the creation of a separate docker context be feasible, that might be optionally set to be the default one? (https://docs.docker.com/engine/context/working-with-contexts/)?

@thisisthekap You could do that, but I've simply been using docker in the VM itself. Do realise that in order to mount from the Mac filesystem you would first have to mount it to the VM which is quite a bit slower than using the filesystem in the VM itself (this is also how Docker desktop does it, only they do it a bit more transparently).

No, I do not want do do any mounts. I just want to use it as docker machine for my local docker cli on my mac.

Then it works.
First expose the port of the VM, such as https://gist.github.com/styblope/dc55e0ad2a9848f2cc3307d4819d819f describes.
Then create a new docker context e.g. (the ip must be that of the vm): docker context create vm --docker "host=tcp://<IP_ADDRESS>:2375"
And then you can do: docker -c vm run -it -p 80:80 strm/helloworld-http
You can then in the browser go to the ip address of the VM and should see the hello world page

FYI, the lima-vm implements Rosetta support in the latest development branch.
https://github.com/lima-vm/lima/releases/tag/v0.14.0-beta.1

@dictcp Did you get docker working using the lima beta?

@dictcp +1 on that too, I can't even figure out how to install Lima BETA. Spent 2 hours and then gave up.

@thisisthekap, @JackEllis
Here's a quick guide on how I got Lima/Colima running with Rosetta on my machine:
brew install --HEAD lima

git clone https://github.com/abiosoft/colima.git && cd colima
git checkout support-vz
make build
sudo make install

colima start

From there you should be able to use docker run ..., docker ps, etc, as usual

In case it is going to cause you issues, colima support-vz only enables rosetta on OSX 13 (ventura).

@mmeyer724 Thank you very much for your work! I had to do some adjustments to the script you suggested (https://github.com/microsoft/mssql-docker/issues/734#issuecomment-1333696500).
MSSQL Server is now running just fine on M1 using Rosetta 2 😄

Yeah. My stack of x86 containers is running beautifully in Colima on the Rosetta 2 branch. Thanks! Would love to see this in Docker Desktop for Mac too.

@thisisthekap, @JackEllis
Here's a quick guide on how I got Lima/Colima running with Rosetta on my machine:
brew install --HEAD lima

git clone https://github.com/abiosoft/colima.git && cd colima
git checkout support-vz
make build
sudo make install

colima start

From there you should be able to use docker run ..., docker ps, etc, as usual.
Edit: Here's how you can verify that rosetta is being utilized  docker run -it --platform linux/amd64 ubuntu

Yeah, this approach is working for me, too. But all -vmounts are not working which makes it for me useless. :-(

From there you should be able to use docker run ..., docker ps, etc, as usual.

Yeah, thank you. This approach is working for me, too. But the -vmount option does not work which makes docker useless for me. :-(
I tried fro example
touch foo
docker run -it --rm -v $(pwd):/$(basename $(pwd)) -w /$(basename $(pwd)) ubuntu
ls
But foo is then not visible inside the container.

@eDeviser Try to add --network-address to colima start

@thisisthekap , Thank you, but sorry, this does not solve the problem.

@thisisthekap , Thank you, but sorry, this does not solve the problem.

Which folder are you trying to mount into the container with -v? By default, Colima only allows mounting folders under /Users. If the folder is located elsewhere, it won't work out of the box (but you won't see an error sadly, the folder will just appear empty).
Thankfully you can configure this using Colima's --mount option, for example:
colima start --mount "/Users:w,/some/other/folder/on/your/mac:w"

If you're still having problems, try SSHing into the Colima VM with colima ssh and see if you can see the folder you're trying to share there.

If you're still having problems, pls file an issue under the colima repo
Yeah, you're right. This is not the right place. I would love to see this in docker desktop.
An yes, my folder is inside /User but it does not work.

@eDeviser, I do have this working, but I had to modify the instructions from @thisisthekap slightly.  In addition to setting the driver to vz, I also had to explicitly set the mountType to virtiofs in the colima template.  Did you try that as well?  (microsoft/mssql-docker#734 (comment))

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

Any updates @christophermclellan ?
This feature is very much needed.

Edit: Here's how you can verify that rosetta is being utilized

Question: with this change, is rosetta used in both docker build and docker run, or just docker run?

@christophermclellan Future support for Rosetta 2 emulation for amd64 images in Docker is exactly what is needed. This will allow macOS users to run container images such as SQL Server 2019/2022 on M1 devices without using third-party libs like Colima.

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x84/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

🎉🎉🎉Sent from my iPhoneOn Jan 10, 2023, at 8:08 AM, Chris McLellan @.***> wrote:
Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x84/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

Amazing. Can't wait to Run SQL Server in M1 Mac

Super! Well done Docker team.

@christophermclellan
Will this also be usuable when running docker within a Linux VM e.g. via Parallels Desktop?
Or even more interesting: When using Asahi Linux directly on M1 machines?

@christophermclellan
Will this also be usuable when running docker within a Linux VM e.g. via Parallels Desktop?
Or even more interesting: When using Asahi Linux directly on M1 machines?

Rosetta2 is only meant to be used with Virtualization.framework.
I tried it inside a Parallels VM and it didn't work.  I was able to mount /Library/Apple/usr/libexec/oah/RosettaLinux/rosetta inside the Parallels VM, and install it using the instructions at [1].  When I try to run a x86_64 docker container in the VM, I get this error
$ docker logs 5c53755fbe28
rosetta error: Rosetta is only intended to run on Apple Silicon with a macOS host using Virtualization.framework with Rosetta mode enabled

[1] https://developer.apple.com/documentation/virtualization/running_intel_binaries_in_linux_vms_with_rosetta?language=objc

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

Does it mean we can run Oracle DB images on Apple Silicon?

the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January

Would you please give a link to the git branch? I would like to check if these changes will also be included into the 4.16 beta.
This is because there is also an issue regarding symbolic links (see here and here) and virtiofs which makes it impossible to build my stuff.

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

Amazing. Where will we find the download of this beta, once published? Looking forward to check if this will resolve the issues for my particular case.

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

I just downloaded the beta. However my container fails with same error as before. Is there something we should do?

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

I just downloaded the beta. However my container fails with same error as before. Is there something we should do?

Where did you find the beta?

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

I just downloaded the beta. However my container fails with same error as before. Is there something we should do?

Where did you find the beta?

https://docs.docker.com/desktop/release-notes/

Does the Rosetta beta feature need to be enabled in some way?

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

I just downloaded the beta. However my container fails with same error as before. Is there something we should do?

Never mind. I see it after restarting installing macOS 13 (and restarted at the same time)

the only thin gwhich is wierd now, is that it always prints: image "IMAGENAME": already exists and has a exit code of non zero (even if the image does not exist (system prune --all --force)

the only thin gwhich is wierd now, is that it always prints: image "IMAGENAME": already exists and has a exit code of non zero (even if the image does not exist (system prune --all --force)

this seems to be from enabling "Use containerd for pulling and storing images" rather than Rosetta

I've also find two things which are inconvienient:

there is probably no way to know if the process is running under rosetta, at least I could not yet find one :/ (c or rust code) (uname returns x86_64)
there is no easy way to run a container as platform/aarch64 and use rosetta inside the container on runtime i.e. to run a container which contains a cross compiled executable, because that would make some things easier

this is more an oracle problem than a docker problem, but I'm hoping someone else is trying this and might have some hints for me.  if I startup colima and run
docker run -d --name oracle_db -e ORACLE_PWD=testing container-registry.oracle.com/database/express:21.3.0-xe
i get a happy oracle container in my colima context (slow, but happy)
if I stop colima and run
docker run -d --name oracle_db -e ORACLE_PWD=testing  --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe
I get a sad container in my docker desktop context with logs that start with
The Oracle base remains unchanged with value /opt/oracle```

Anyone figure this out yet?

I have installed a new version of docker, and enabled rosetta support and struggling issue with the running container inside the container. Maybe someone knows how to handle it?
`docker: failed to register layer: Error processing tar file(exit status 1): "dockerd" accepts no argument(s).
See 'dockerd --help'.
Usage:  dockerd [OPTIONS]
A self-sufficient runtime for containers.
.
See 'docker run --help'.`

Is there a possibility to only enable this new feature for selected containers? I need to use two seperate containers, one only runs with the Rosetta support enabled, the other one only when it's disabled.

@Finn-Ko:
docker run --platform linux/amd64 ...
docker run --platform linux/arm64v8 ...

Is there a possibility to only enable this new feature for selected containers? I need to use two seperate containers, one only runs with the Rosetta support enabled, the other one only when it's disabled.

Under the hood it's the same VM, it just tells the kernel to use rosetta if you're executing an x86 binary vs. an arm one. Previously it used qemu to handle x86 execution, which is obviously much slower. But there's no per-container switch.

I've also find two things which are inconvienient:

there is probably no way to know if the process is running under rosetta, at least I could not yet find one :/ (c or rust code) (uname returns x86_64)
I spent way too long on this, and I didn't find a satisfactory answer. I thought maybe I'd find something under getauxvalue(3) but AT_EXECFN is just the binary itself.

there is no easy way to run a container as platform/aarch64 and use rosetta inside the container on runtime i.e. to run a container which contains a cross compiled executable, because that would make some things easier

This works as it is, since the interpreter is set at the VM level for docker desktop, you can run a mix of x86 and arm binaries and the kernel will figure out how to execute each.
 I'm running SingleStore locally on my M1 Air and the speed has improved an unbelievable amount thanks to this change. Now time to leave Docker on overnight with my laptop unplugged to see if there's improvement there :)

@Finn-Ko:
docker run --rm -ti --platform linux/amd64 ubuntu:latest uname -m docker run --rm -ti --platform linux/arm64 ubuntu:latest uname -m
*edited to make more sense 😊

Thanks for the reply!
Problem is that my second image is also amd64 native and used to work with the qemu emulation. It doesn't work with the rosetta emulation. setting the --platform linux/amd64 flag when running it results in:
docker: Error response from daemon: image with reference
[...] was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.
See 'docker run --help'.

Thanks for the reply! Problem is that my second image is also amd64 native and used to work with the qemu emulation. It doesn't work with the rosetta emulation. setting the --platform linux/amd64 flag when running it results in:
docker: Error response from daemon: image with reference
[...] was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.
See 'docker run --help'.

I get this error too. It appears Docker can only hold one image of one platform in your local registry, so you need to rebuild or re-pull the arm64 image before doing the docker run command.

Hi all, thanks for your patience on this one. We'll be releasing Rosetta for x86/amd64 emulation on Apple Silicon as a beta feature in the v4.16 release of Docker Desktop, which is scheduled for this Thursday 12-January. I'll circle back here once it's out !

I just downloaded the beta. However my container fails with same error as before. Is there something we should do?

Never mind. I see it after restarting installing macOS 13. And yes you should be using macOS 13 to see this feature

I don't see this option... I have installed rosetta and Docker Desktop 4.16.0 (95345). Any idea?

Thanks for the reply! Problem is that my second image is also amd64 native and used to work with the qemu emulation. It doesn't work with the rosetta emulation. setting the --platform linux/amd64 flag when running it results in:
docker: Error response from daemon: image with reference
[...] was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.
See 'docker run --help'.

I get this error too. It appears Docker can only hold one image of one platform in your local registry, so you need to rebuild or re-pull the arm64 image before doing the docker run command.

The image I need to use is an amd64 image. It worked fine with qemu but doesn't with rosetta. Re-pulling/-building therefore unfortunately doesn't change anything for me.

@Finn-Ko I could be wrong but you may be suffering from the same issue as me. Qemu used to work for me too, however this is different to Rosetta (Qemu acting as full emulation). I changed my container to be arm64 and am still unable to run my executable but I now get a Rosetta error. The error is rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Anyone shed any light on this? Am I doing things correctly here?

@Finn-Ko I could be wrong but you may be suffering from the same issue as me. Qemu used to work for me too, however this is different to Rosetta (Qemu acting as full emulation). I changed my container to be arm64 and am still unable to run my executable but I now get a Rosetta error. The error is rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Anyone shed any light on this? Am I doing things correctly here?

you need to install a libc6 for amd, if you are on debian you can do: dpkg --add-architecture amd64 && apt-get update && apt-get install -y libc6:amd sometimes you also need libstdc++6:amd64 no idea how to do it in alpine, tough

Awesome work Docker team! 🎉
Running some tooling containers on my local development machine, these images are currently only provided as amd64 variant, I tested one protobuf compiler image now which was before really slow on the M1, feels much much better now.
Docker v4.15.0
time tools/build-proto.sh
real    0m24.817s
user    0m0.076s
sys     0m0.085s

Docker v4.16.0 with Rosetta enabled
time tools/build-proto.sh
real    0m13.517s
user    0m0.085s
sys     0m0.110s

Thank you very much.

We're seeing a huge speed up on SQL queries running on SingleStore dev image. Thanks for working on this!!

@Finn-Ko I could be wrong but you may be suffering from the same issue as me. Qemu used to work for me too, however this is different to Rosetta (Qemu acting as full emulation). I changed my container to be arm64 and am still unable to run my executable but I now get a Rosetta error. The error is rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Anyone shed any light on this? Am I doing things correctly here?

you need to install a libc6 for amd inside the image, if you are on debian you can do: dpkg --add-architecture amd64 && apt-get update && apt-get install -y libc6:amd sometimes you also need libstdc++6:amd64 no idea how to do it in alpine, tough.

Thanks for that. Turns out cross arhictecture issue where the libs are in a different location. Symlinks solved this.

If anyone is having issues trying to find the feature under the Beta Features, make sure your macOS is 13, as this feature was released for macOS 13 and above

This has made things so much faster. I ran some benchmarks this morning and I'm blown away.

Query
Before Rosetta
After enabling Rosetta
How much faster is Rosetta?

CREATE DATABASE test;
3,083 ms
2,954.75 ms
4.16%

DROP DATABASE test;
939 ms
740.33 ms
21.15%

CREATE TABLE users (id BIGINT AUTO_INCREMENT PRIMARY KEY, name TEXT, email TEXT);
121 ms
28.75 ms
76.24%

INSERT INTO users (id, name, email) VALUES (1, 'Jack Ellis', 'jack.ellis@google-analytics.com');
5.4 ms
2.66 ms
50.74%

SELECT * FROM users WHERE id = 1;
4.8 ms
2.5 ms
47.91%

UPDATE users SET name = 'Jack Google' WHERE id = 1;
6 ms
3 ms
50%

DELETE FROM users WHERE id = 1;
5.8 ms
2.25 ms
61.21%

SELECT SUM(pageviews) from pageviews;
67.6 ms
7.4 ms
89%

SELECT pathname, SUM(pageviews) as x from pageviews GROUP BY pathname ORDER BY x DESC LIMIT 100;
125.2 ms
16.2 ms
87%

SELECT pathname, SUM(pageviews) as x FROM pageviews WHERE referrer_hostname = ‘https://laravel.com' GROUP BY pathname ORDER BY x DESC LIMIT 100;
133.6 ms
12 ms
91%

UPDATE pageviews SET utm_campaign = ‘boop’;
22,000 ms
3,593 ms
83.66%

DELETE FROM pageviews WHERE referrer_hostname = 'https://laravel.com';
610.33 ms
93 ms
84.76%

DELETE FROM pageviews;
488.5 ms
44 ms
90.99%

Source: https://usefathom.com/laravel-tips/singlestore-faster-docker

Trying to build MS SQL Server with Rosetta emulation enabled on my M1 but docker build fails with following
[+] Building 19.1s (5/5) FINISHED
 => [internal] load build definition from mssql-agent-fts-ha-tools.Dockerfile                                                           0.0s
 => => transferring dockerfile: 1.09kB                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/library/ubuntu:16.04                                                                         0.6s
 => CACHED [1/2] FROM docker.io/library/ubuntu:16.04@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416f59e03c04f5c6ffee0d6            0.0s
 => => resolve docker.io/library/ubuntu:16.04@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416f59e03c04f5c6ffee0d6                   0.0s
 => ERROR [2/2] RUN export DEBIAN_FRONTEND=noninteractive &&     apt-get update &&     apt-get install -yq curl apt-transport-https &  18.4s
------
 > [2/2] RUN export DEBIAN_FRONTEND=noninteractive &&     apt-get update &&     apt-get install -yq curl apt-transport-https &&     curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - &&     curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list | tee /etc/apt/sources.list.d/mssql-server.list &&     apt-get update &&     apt-get install -y mssql-server &&     apt-get install -y mssql-server-ha &&     apt-get install -y mssql-server-fts &&     apt-get clean &&     rm -rf /var/lib/apt/lists:
#5 0.263 Get:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease [247 kB]
#5 0.496 Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [99.8 kB]
#5 0.637 Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [97.4 kB]
#5 0.688 Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [99.8 kB]
#5 0.702 Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 Packages [1466 kB]
#5 0.870 Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/universe arm64 Packages [9493 kB]
#5 1.173 Get:7 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse arm64 Packages [146 kB]
#5 1.175 Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 Packages [1556 kB]
#5 1.187 Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe arm64 Packages [1466 kB]
#5 1.259 Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse arm64 Packages [17.2 kB]
#5 1.260 Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main arm64 Packages [10.9 kB]
#5 1.260 Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe arm64 Packages [10.7 kB]
#5 1.262 Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-security/main arm64 Packages [1118 kB]
#5 1.269 Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe arm64 Packages [943 kB]
#5 1.277 Get:15 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse arm64 Packages [3332 B]
#5 1.876 Fetched 16.8 MB in 1s (9857 kB/s)
#5 1.876 Reading package lists...
#5 2.420 Reading package lists...
#5 2.972 Building dependency tree...
#5 3.061 Reading state information...
#5 3.129 The following additional packages will be installed:
#5 3.129   ca-certificates krb5-locales libasn1-8-heimdal libcurl3-gnutls libffi6
#5 3.129   libgmp10 libgnutls30 libgssapi-krb5-2 libgssapi3-heimdal libhcrypto4-heimdal
#5 3.129   libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal
#5 3.129   libidn11 libk5crypto3 libkeyutils1 libkrb5-26-heimdal libkrb5-3
#5 3.129   libkrb5support0 libldap-2.4-2 libnettle6 libp11-kit0 libroken18-heimdal
#5 3.129   librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0
#5 3.129   libssl1.0.0 libtasn1-6 libwind0-heimdal openssl
#5 3.130 Suggested packages:
#5 3.130   gnutls-bin krb5-doc krb5-user libsasl2-modules-otp libsasl2-modules-ldap
#5 3.130   libsasl2-modules-sql libsasl2-modules-gssapi-mit
#5 3.130   | libsasl2-modules-gssapi-heimdal
#5 3.130 The following NEW packages will be installed:
#5 3.130   apt-transport-https ca-certificates curl krb5-locales libasn1-8-heimdal
#5 3.130   libcurl3-gnutls libffi6 libgmp10 libgnutls30 libgssapi-krb5-2
#5 3.130   libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal
#5 3.130   libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libidn11 libk5crypto3
#5 3.130   libkeyutils1 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libldap-2.4-2
#5 3.130   libnettle6 libp11-kit0 libroken18-heimdal librtmp1 libsasl2-2
#5 3.130   libsasl2-modules libsasl2-modules-db libsqlite3-0 libssl1.0.0 libtasn1-6
#5 3.130   libwind0-heimdal openssl
#5 3.261 0 upgraded, 35 newly installed, 0 to remove and 0 not upgraded.
#5 3.261 Need to get 4370 kB of archives.
#5 3.261 After this operation, 17.3 MB of additional disk space will be used.
#5 3.261 Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libffi6 arm64 3.2.1-4 [16.3 kB]
#5 3.353 Get:2 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libgmp10 arm64 2:6.1.0+dfsg-2 [202 kB]
#5 3.483 Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libnettle6 arm64 3.2-1ubuntu<IP_ADDRESS> [96.1 kB]
#5 3.504 Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhogweed4 arm64 3.2-1ubuntu<IP_ADDRESS> [127 kB]
#5 3.526 Get:5 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libidn11 arm64 1.32-3ubuntu1.2 [42.9 kB]
#5 3.530 Get:6 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libp11-kit0 arm64 0.23.2-5~ubuntu16.04.2 [84.1 kB]
#5 3.540 Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libtasn1-6 arm64 4.7-3ubuntu<IP_ADDRESS> [38.0 kB]
#5 3.544 Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgnutls30 arm64 3.4.10-4ubuntu1.9 [438 kB]
#5 3.575 Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsqlite3-0 arm64 3.11.0-1ubuntu1.5 [335 kB]
#5 3.593 Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libssl1.0.0 arm64 1.0.2g-1ubuntu4.20 [693 kB]
#5 3.619 Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5support0 arm64 1.13.2+dfsg-5ubuntu2.2 [28.3 kB]
#5 3.619 Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libk5crypto3 arm64 1.13.2+dfsg-5ubuntu2.2 [72.1 kB]
#5 3.622 Get:13 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libkeyutils1 arm64 1.5.9-8ubuntu1 [9424 B]
#5 3.623 Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5-3 arm64 1.13.2+dfsg-5ubuntu2.2 [227 kB]
#5 3.628 Get:15 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgssapi-krb5-2 arm64 1.13.2+dfsg-5ubuntu2.2 [97.2 kB]
#5 3.630 Get:16 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libroken18-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [34.6 kB]
#5 3.631 Get:17 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libasn1-8-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [127 kB]
#5 3.636 Get:18 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhcrypto4-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [70.5 kB]
#5 3.637 Get:19 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libheimbase1-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [24.3 kB]
#5 3.663 Get:20 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libwind0-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [47.1 kB]
#5 3.665 Get:21 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhx509-5-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [86.1 kB]
#5 3.668 Get:22 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5-26-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [162 kB]
#5 3.673 Get:23 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libheimntlm0-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [13.2 kB]
#5 3.674 Get:24 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgssapi3-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [76.5 kB]
#5 3.678 Get:25 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-modules-db arm64 2.1.26.dfsg1-14ubuntu0.2 [13.0 kB]
#5 3.678 Get:26 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-2 arm64 2.1.26.dfsg1-14ubuntu0.2 [41.4 kB]
#5 3.683 Get:27 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libldap-2.4-2 arm64 2.4.42+dfsg-2ubuntu3.13 [133 kB]
#5 3.703 Get:28 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 librtmp1 arm64 2.4+20151223.gitfa8646d-1ubuntu0.1 [48.4 kB]
#5 3.706 Get:29 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libcurl3-gnutls arm64 7.47.0-1ubuntu2.19 [156 kB]
#5 3.709 Get:30 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 apt-transport-https arm64 1.2.35 [24.8 kB]
#5 3.711 Get:31 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 openssl arm64 1.0.2g-1ubuntu4.20 [471 kB]
#5 3.721 Get:32 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 ca-certificates all 20210119~16.04.1 [148 kB]
#5 3.723 Get:33 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 krb5-locales all 1.13.2+dfsg-5ubuntu2.2 [13.7 kB]
#5 3.724 Get:34 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-modules arm64 2.1.26.dfsg1-14ubuntu0.2 [40.1 kB]
#5 3.725 Get:35 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 curl arm64 7.47.0-1ubuntu2.19 [133 kB]
#5 3.773 debconf: delaying package configuration, since apt-utils is not installed
#5 3.785 Fetched 4370 kB in 0s (7827 kB/s)
#5 3.798 Selecting previously unselected package libffi6:arm64.

Trying to build MS SQL Server with Rosetta emulation enabled on my M1 but docker build fails with following
[+] Building 19.1s (5/5) FINISHED
 => [internal] load build definition from mssql-agent-fts-ha-tools.Dockerfile                                                           0.0s
 => => transferring dockerfile: 1.09kB                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/library/ubuntu:16.04                                                                         0.6s
 => CACHED [1/2] FROM docker.io/library/ubuntu:16.04@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416f59e03c04f5c6ffee0d6            0.0s
 => => resolve docker.io/library/ubuntu:16.04@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416f59e03c04f5c6ffee0d6                   0.0s
 => ERROR [2/2] RUN export DEBIAN_FRONTEND=noninteractive &&     apt-get update &&     apt-get install -yq curl apt-transport-https &  18.4s
------
 > [2/2] RUN export DEBIAN_FRONTEND=noninteractive &&     apt-get update &&     apt-get install -yq curl apt-transport-https &&     curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - &&     curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list | tee /etc/apt/sources.list.d/mssql-server.list &&     apt-get update &&     apt-get install -y mssql-server &&     apt-get install -y mssql-server-ha &&     apt-get install -y mssql-server-fts &&     apt-get clean &&     rm -rf /var/lib/apt/lists:
#5 0.263 Get:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease [247 kB]
#5 0.496 Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [99.8 kB]
#5 0.637 Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [97.4 kB]
#5 0.688 Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [99.8 kB]
#5 0.702 Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 Packages [1466 kB]
#5 0.870 Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/universe arm64 Packages [9493 kB]
#5 1.173 Get:7 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse arm64 Packages [146 kB]
#5 1.175 Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 Packages [1556 kB]
#5 1.187 Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe arm64 Packages [1466 kB]
#5 1.259 Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse arm64 Packages [17.2 kB]
#5 1.260 Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main arm64 Packages [10.9 kB]
#5 1.260 Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe arm64 Packages [10.7 kB]
#5 1.262 Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-security/main arm64 Packages [1118 kB]
#5 1.269 Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe arm64 Packages [943 kB]
#5 1.277 Get:15 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse arm64 Packages [3332 B]
#5 1.876 Fetched 16.8 MB in 1s (9857 kB/s)
#5 1.876 Reading package lists...
#5 2.420 Reading package lists...
#5 2.972 Building dependency tree...
#5 3.061 Reading state information...
#5 3.129 The following additional packages will be installed:
#5 3.129   ca-certificates krb5-locales libasn1-8-heimdal libcurl3-gnutls libffi6
#5 3.129   libgmp10 libgnutls30 libgssapi-krb5-2 libgssapi3-heimdal libhcrypto4-heimdal
#5 3.129   libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal
#5 3.129   libidn11 libk5crypto3 libkeyutils1 libkrb5-26-heimdal libkrb5-3
#5 3.129   libkrb5support0 libldap-2.4-2 libnettle6 libp11-kit0 libroken18-heimdal
#5 3.129   librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0
#5 3.129   libssl1.0.0 libtasn1-6 libwind0-heimdal openssl
#5 3.130 Suggested packages:
#5 3.130   gnutls-bin krb5-doc krb5-user libsasl2-modules-otp libsasl2-modules-ldap
#5 3.130   libsasl2-modules-sql libsasl2-modules-gssapi-mit
#5 3.130   | libsasl2-modules-gssapi-heimdal
#5 3.130 The following NEW packages will be installed:
#5 3.130   apt-transport-https ca-certificates curl krb5-locales libasn1-8-heimdal
#5 3.130   libcurl3-gnutls libffi6 libgmp10 libgnutls30 libgssapi-krb5-2
#5 3.130   libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal
#5 3.130   libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libidn11 libk5crypto3
#5 3.130   libkeyutils1 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libldap-2.4-2
#5 3.130   libnettle6 libp11-kit0 libroken18-heimdal librtmp1 libsasl2-2
#5 3.130   libsasl2-modules libsasl2-modules-db libsqlite3-0 libssl1.0.0 libtasn1-6
#5 3.130   libwind0-heimdal openssl
#5 3.261 0 upgraded, 35 newly installed, 0 to remove and 0 not upgraded.
#5 3.261 Need to get 4370 kB of archives.
#5 3.261 After this operation, 17.3 MB of additional disk space will be used.
#5 3.261 Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libffi6 arm64 3.2.1-4 [16.3 kB]
#5 3.353 Get:2 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libgmp10 arm64 2:6.1.0+dfsg-2 [202 kB]
#5 3.483 Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libnettle6 arm64 3.2-1ubuntu<IP_ADDRESS> [96.1 kB]
#5 3.504 Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhogweed4 arm64 3.2-1ubuntu<IP_ADDRESS> [127 kB]
#5 3.526 Get:5 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libidn11 arm64 1.32-3ubuntu1.2 [42.9 kB]
#5 3.530 Get:6 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libp11-kit0 arm64 0.23.2-5~ubuntu16.04.2 [84.1 kB]
#5 3.540 Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libtasn1-6 arm64 4.7-3ubuntu<IP_ADDRESS> [38.0 kB]
#5 3.544 Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgnutls30 arm64 3.4.10-4ubuntu1.9 [438 kB]
#5 3.575 Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsqlite3-0 arm64 3.11.0-1ubuntu1.5 [335 kB]
#5 3.593 Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libssl1.0.0 arm64 1.0.2g-1ubuntu4.20 [693 kB]
#5 3.619 Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5support0 arm64 1.13.2+dfsg-5ubuntu2.2 [28.3 kB]
#5 3.619 Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libk5crypto3 arm64 1.13.2+dfsg-5ubuntu2.2 [72.1 kB]
#5 3.622 Get:13 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 libkeyutils1 arm64 1.5.9-8ubuntu1 [9424 B]
#5 3.623 Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5-3 arm64 1.13.2+dfsg-5ubuntu2.2 [227 kB]
#5 3.628 Get:15 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgssapi-krb5-2 arm64 1.13.2+dfsg-5ubuntu2.2 [97.2 kB]
#5 3.630 Get:16 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libroken18-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [34.6 kB]
#5 3.631 Get:17 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libasn1-8-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [127 kB]
#5 3.636 Get:18 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhcrypto4-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [70.5 kB]
#5 3.637 Get:19 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libheimbase1-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [24.3 kB]
#5 3.663 Get:20 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libwind0-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [47.1 kB]
#5 3.665 Get:21 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libhx509-5-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [86.1 kB]
#5 3.668 Get:22 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libkrb5-26-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [162 kB]
#5 3.673 Get:23 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libheimntlm0-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [13.2 kB]
#5 3.674 Get:24 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libgssapi3-heimdal arm64 1.7~git20150920+dfsg-4ubuntu<IP_ADDRESS> [76.5 kB]
#5 3.678 Get:25 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-modules-db arm64 2.1.26.dfsg1-14ubuntu0.2 [13.0 kB]
#5 3.678 Get:26 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-2 arm64 2.1.26.dfsg1-14ubuntu0.2 [41.4 kB]
#5 3.683 Get:27 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libldap-2.4-2 arm64 2.4.42+dfsg-2ubuntu3.13 [133 kB]
#5 3.703 Get:28 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 librtmp1 arm64 2.4+20151223.gitfa8646d-1ubuntu0.1 [48.4 kB]
#5 3.706 Get:29 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libcurl3-gnutls arm64 7.47.0-1ubuntu2.19 [156 kB]
#5 3.709 Get:30 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 apt-transport-https arm64 1.2.35 [24.8 kB]
#5 3.711 Get:31 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 openssl arm64 1.0.2g-1ubuntu4.20 [471 kB]
#5 3.721 Get:32 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 ca-certificates all 20210119~16.04.1 [148 kB]
#5 3.723 Get:33 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 krb5-locales all 1.13.2+dfsg-5ubuntu2.2 [13.7 kB]
#5 3.724 Get:34 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 libsasl2-modules arm64 2.1.26.dfsg1-14ubuntu0.2 [40.1 kB]
#5 3.725 Get:35 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 curl arm64 7.47.0-1ubuntu2.19 [133 kB]
#5 3.773 debconf: delaying package configuration, since apt-utils is not installed
#5 3.785 Fetched 4370 kB in 0s (7827 kB/s)
#5 3.798 Selecting previously unselected package libffi6:arm64.
  This works for me.
docker run --platform linux/amd64 -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=StrongPassword!" -p 1433:1433  mcr.microsoft.com/mssql/server:2022-latest

@jordantshaw that did the trick, thanks!

In my case, running a Dockerfile that adds to benjaminabt/mssql-fts:2019-cu10-ubuntu-2004 for full text support in MS SQL and using docker-compose, setting platform as an environment variable to " linux/amd64" didn't work. I still got an error that  linux/arm64/v8 was not supported.
What seemed to work was to turn off containerd in settings:

I still got warnings, but at least it worked, and the speed was OK

when i activate i get rosseta

I'm not sure why the checkbox doesn't show 🤔
Version

No checkbox

General

I have the latest version of Docker Desktop 😢
OS: macOS 12.6.2 (Monterey) on MacBook Pro M1
Could someone help me figure this out?

@Jolg42 it is only enabled for Ventura macOS and up

I'm I the only having issue with Composer showing segfault (139) on exec?

Thanks a-lot for this Rosetta 2 integration.
I'm building Open VSCode Server (fork of VSCode) and I need this to run on linux/amd64 platform due to binaries compatibilities issues (node-gyp...)

The deps install phase includes 40+ invocations of yarn install in various sub-folders of the vscode repo.

Without Rosetta 2 this step alone easily took over 15 minutes.

With Rosetta its ~5.5 minutes.

With a native arm64 docker image it takes ~4.5 minutes.

So I am very happy with only a ~20% overhead for using a none native image 🎉

I've been fighting to get oracle up and running this way and not having any luck.
the command docker run -d --name oracle_db --pull always --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe
results in a broken container
I can't su in the container (even as root)
the only difference here between a working container on colima and this is that rosetta is running bash when I log into this one.  I'm going to go away for a while and come back hopefully when someone else has it figured out.

Thanks for this feature Docker team!
I'm having issues with a x86 image of elastic search when enabling this.
The error is:
2023-01-17 16:58:12 Exception in thread "main" java.io.IOException: Cannot run program "/usr/share/elasticsearch/jdk/bin/java": error=0, Failed to exec spawn helper: pid: 164, exit value: 1
2023-01-17 16:58:12     at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
2023-01-17 16:58:12     at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
2023-01-17 16:58:12     at org.elasticsearch.tools.launchers.JvmErgonomics.flagsFinal(JvmErgonomics.java:114)
2023-01-17 16:58:12     at org.elasticsearch.tools.launchers.JvmErgonomics.finalJvmOptions(JvmErgonomics.java:88)
2023-01-17 16:58:12     at org.elasticsearch.tools.launchers.JvmErgonomics.choose(JvmErgonomics.java:59)
2023-01-17 16:58:12     at org.elasticsearch.tools.launchers.JvmOptionsParser.jvmOptions(JvmOptionsParser.java:139)
2023-01-17 16:58:12     at org.elasticsearch.tools.launchers.JvmOptionsParser.main(JvmOptionsParser.java:95)
2023-01-17 16:58:12 Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 164, exit value: 1
2023-01-17 16:58:12     at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
2023-01-17 16:58:12     at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:319)
2023-01-17 16:58:12     at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:250)
2023-01-17 16:58:12     at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
2023-01-17 16:58:12     ... 6 more

Docker run for testing:
docker run --name test_elastic -p 9200:9200 -e xpack.security.enabled=false -e discovery.type=single-node elasticsearch:7.7.0

Love this new feature. I built a huuuuuuge package of astronomy software (HEASOFT) and the build time (compared to building on a real amd64 server) was 2.8X -- not bad for emulation.

Similar issue with forking on Groovy side, maybe related?

2023-01-17 16:58:12 Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 164, exit value: 1

when i activate rosseta i get

#0 1.494 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#0 1.494 (ThreadContextVm.cpp:47 mmap)

I can confirm this is an error that pops up often, although I do not see a pattern to it. For me it tends to happen during RUN yarn build, so it would appear it's not specific to php. I use an image based off of node:18-alpine on Docker Desktop 4.16.1 (95567). It does not seem to happen for some other images (without yarn build) I use.

Can confirm that Oracle doesn't seem to like running under Rosetta. There's an Oracle XE image at gvenzl/oracle-xe:21 that's used by testcontainers and which just terminates with:
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<IP_ADDRESS>)(PORT=1521)))
The listener supports no services
The command completed successfully
ORA-03113: end-of-file on communication channel

It works fine on amd64 hardware obviously. It doesn't work under QEMU either for what it's worth.
Rosetta is definitely faster than QEMU though. Hopefully these issues can be worked out.

For anyone having issues with Oracle DB(19c) setup.
I was able to set it up and run successfully on M1 pro following similar instructions as discussed here https://github.com/oracle/docker-images/discussions/1951#discussioncomment-4664280
The issue seems to stem from install scripts, some of the setup utilities do not work under rosetta emulation. The actual database service has no problem running on Rosetta and based on my findings performance is ~7.5x faster than qemu and only ~25% slower compared to native amd64. That's huge.
General steps to follow:

Start oracle db container on amd64 machine
Follow the same steps to start oracle container on arm64 mac with --platform linux/amd64
Wait till installation fails, and stop the container.
Replace the contents of oracle home on mac with the files from your amd64 machine.
Start oracle db container on your arm64 machine.

Hi everyone ! lot’s of great feedback on this thread. thanks for testing it out and letting us know about your issues. it’s great to see the performance benchmarks as well, thanks a lot for sharing those.
@jjimenez and @nickives , did the above suggestion from @mnaujokas solve your problem ?
@arturnasennik and @Harmenius , could one of you possibly replicate the assertion failed error again and send me a diagnostic id so that we can look in to this ? thanks in advance if you're able to do this.
@Finn-Ko, is your issue resolved now ? do you still have a need to specify individual containers that you want to use Rosetta emulation ? we’re aware that it won’t work with every image so i’m wondering whether we should look in to providing this granularity. if anyone’s interested in this then please let me know !

@Finn-Ko, is your issue resolved now ? do you still have a need to specify individual containers that you want to use Rosetta emulation ? we’re aware that it won’t work with every image so i’m wondering whether we should look in to providing this granularity. if anyone’s interested in this then please let me know !

My issue is not resolved yet and whenever I need both containers at the same time I need to use the old colima solution. Therefore I would be very happy if a future update would include a way to select the emulation method for individual containers. :)

@jjimenez and , did the above suggestion from @mnaujokas solve your problem ?

Unfortunately, I can't even get the base container for oracle to come up enough to be able to log into it:
docker run -d --name oracle_db --pull always --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe

does not result in a container that I can log into so I can replace the oracle_base directory contents.

I decided to try to replicate @jjimenez's problem:
docker run -d --name oracle_db --pull always --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe

$ docker ps -a
CONTAINER ID   IMAGE                                                      COMMAND                  CREATED         STATUS                            PORTS     NAMES
cf323995e0fa   container-registry.oracle.com/database/express:21.3.0-xe   "/bin/sh -c 'exec $O…"   8 seconds ago   Up 6 seconds (health: starting)             oracle_db
$ docker exec -it cf323995e0fa bash
bash-4.2$ hostname
cf323995e0fa

So as you can see, it works for me. Exact versions:
Docker version 20.10.22, build 3a2c30b
macOS Ventura Version 13.1 (22C65)

I decided to try to replicate @jjimenez's problem:
docker run -d --name oracle_db --pull always --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe

$ docker ps -a
CONTAINER ID   IMAGE                                                      COMMAND                  CREATED         STATUS                            PORTS     NAMES
cf323995e0fa   container-registry.oracle.com/database/express:21.3.0-xe   "/bin/sh -c 'exec $O…"   8 seconds ago   Up 6 seconds (health: starting)             oracle_db
$ docker exec -it cf323995e0fa bash
bash-4.2$ hostname
cf323995e0fa

So as you can see, it works for me. Exact versions:
Docker version 20.10.22, build 3a2c30b
macOS Ventura Version 13.1 (22C65)

Thanks for trying, if you notice the health status of the system, it is "starting" and, if you manage to check the logs, with docker logs oracle_db, you will see some error messages.

Hi everyone ! lot’s of great feedback on this thread. thanks for testing it out and letting us know about your issues. it’s great to see the performance benchmarks as well, thanks a lot for sharing those.
@jjimenez and @nickives , did the above suggestion from @mnaujokas solve your problem ?

It seems a bit fiddly and I couldn't get it to work. None of the official Oracle images work either. It's the same as @jjimenez reports above: The database is stuck starting.

I'm not seeing the option to enable Rosetta 2 in Docker for Mac 4.16.1. According to reports, I should be able to see that option under the "Beta features" tab in "Features in development". Does anyone know why it's not showing for me?

Are you using the latest version of Ventura?
On Fri, Jan 20, 2023, 00:53 Milos Ivanovic @.***> wrote:

I'm not seeing the option to enable Rosetta 2 in Docker for Mac 4.16.1.
According to reports, I should be able to see that option under the "Beta
features" tab in "Features in development". Does anyone know why it's not
showing for me?
[image: Screen Shot 2023-01-19 at 3 52 01 PM]
https://user-images.githubusercontent.com/1274505/213587688-052844d8-b902-49d6-bd1b-8c2397eab647.png
—
Reply to this email directly, view it on GitHub
https://github.com/docker/roadmap/issues/384#issuecomment-1397755524,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN4OXSFRVXUHO55DWMQSAG3WTHHYVANCNFSM52MJI7UA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@arturnasennik and @Harmenius , could one of you possibly replicate the assertion failed error again and send me a diagnostic id so that we can look in to this ? thanks in advance if you're able to do this.

I have tried a few diagnostics runs from the command-line.  All of our binaries run on amd64. Should the Ubuntu container have platform --platform linux/amd64 specified?

@stuartmilne thats what I did. I specified "--platform linux/amd64 " when doing both docker build and run.
I am running only mac OS 12.5, so I dont have the beta feature mentioned above, but I see I can run the docker containers regardlessly. The only downside is that the containers are noticeably slower, but hopefully that will be resolved when I will do the update to mac OS 13.1

I just wanted to confirm that this new feature allows me to use MSSQL containers on my M1 without issues. I could run both MSSQL and PostgreSQL containers and do a two-hour data processing run without any issues. Thank you!

2023-01-17 16:58:12 Exception in thread "main" java.io.IOException: Cannot run program "/usr/share/elasticsearch/jdk/bin/java": error=0, Failed to exec spawn helper: pid: 164, exit value: 1

Got a similar issue with Java as well.
17:48:21.391 [main] ERROR n.c.w.p.core.lib.blast.BlastRunner - BLAST Failure: -db /paarsnp/databases/1313_paarsnp -perc_identity 80.0 -evalue 1e-5 -query /data/test.contigs.fasta
java.io.IOException: Cannot run program "blastn": error=0, Failed to exec spawn helper: pid: 24, exit value: 1

Have just experienced this issue building on M1 Mac with this simple script:
FROM laravelphp/vapor:php82

RUN docker-php-ext-install exif
RUN docker-php-ext-configure exif --enable-exif

COPY . /var/task ```

Resulting in:

```#5 16.19 cc -I. -I/usr/src/php/ext/exif -I/usr/src/php/ext/exif/include -I/usr/src/php/ext/exif/main
-I/usr/src/php/ext/exif -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/ph
p/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/li
b -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H
-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DZE
ND_ENABLE_STATIC_TSRMLS_CACHE=1 -DZEND_COMPILE_DL_EXT=1 -c /usr/src/php/ext/exif/exif.c -MMD -MF exif.
dep -MT exif.lo -fPIC -DPIC -o .libs/exif.o
#5 16.49 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#5 16.49 (ThreadContextVm.cpp:47 mmap)
#5 16.49 cc: internal compiler error: Trace/breakpoint trap signal terminated program cc1
#5 16.49 Please submit a full bug report, with preprocessed source (by using -freport-bug).
#5 16.49 See <https://gitlab.alpinelinux.org/alpine/aports/-/issues> for instructions.
#5 16.50 make: *** [Makefile:209: exif.lo] Error 1
#5 ERROR: executor failed running [/bin/sh -c docker-php-ext-install exif]: exit code: 2 ```

Turning off Rosetta allows the build to complete.

I have narrowed down the observation by @Harmenius in https://github.com/docker/roadmap/issues/384#issuecomment-1387027955 to the point that this only happens to me when I do a docker-compose build on a docker-compose-file with multiple services (around 10) that haven't been build previously
I can circumvent the problem by building each service one-by-one using docker-compose build <servicename>

2023-01-17 16:58:12 Exception in thread "main" java.io.IOException: Cannot run program "/usr/share/elasticsearch/jdk/bin/java": error=0, Failed to exec spawn helper: pid: 164, exit value: 1

Got a similar issue with Java as well.
17:48:21.391 [main] ERROR n.c.w.p.core.lib.blast.BlastRunner - BLAST Failure: -db /paarsnp/databases/1313_paarsnp -perc_identity 80.0 -evalue 1e-5 -query /data/test.contigs.fasta
java.io.IOException: Cannot run program "blastn": error=0, Failed to exec spawn helper: pid: 24, exit value: 1

If disable Rosetta in Docker, the error disappears

I finally fixed this by adding the -Djdk.lang.Process.launchMechanism=vfork flag when doing the java/mvn etc build.

#15 38.85 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#15 38.85 (ThreadContextVm.cpp:47 mmap)

I am also plagued by this issue in my build scripts when using Rosetta. Mainly the situation arises in a step where a python script tries to set up a venv via a python -m venv subprocess. Some observations:

usually the issue arises when invoking said subprocess for the second time in the build chain but with different parameters (namely target dir name)
the issue only seems to  arise when there is no tty allocated (i.e. during build or running without -t)
the issue does not arise if I set up the venv via an api call instead of subprocess invocation

This is crucial, Docker team please prioritize!

#15 38.85 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#15 38.85 (ThreadContextVm.cpp:47 mmap)

I am also plagued by this issue in my build scripts when using Rosetta. Mainly the situation arises in a step where a python script tries to set up a venv via a python -m venv subprocess. Some observations:
* usually the issue arises when invoking said subprocess for the second time in the build chain but with different parameters (namely target dir name)

* the issue only seems to  arise when there is no tty allocated (i.e. during build or running without -t)

* the issue does not arise if I set up the venv via an api call instead of subprocess invocation

Interesting, I wonder if I'm experiencing a similar issue.  I have a setup script that kept throwing a segmentation fault when installing Python dependencies.

I have the same issue while vscode is indexing files inside a devcontainer. This is happening since I've enabledUse Rosetta for x86/amd64 emulation on Apple Silicon

Having the same problem here, if we can provide any useful other info, please let us know.

I have the same error. I had been using WSL on windows with docker to generate the builds for STM32. I switched to Apple silicon(M1), made changes accordingly(use --platform, install and enable rosetta etc..) and getting the same error when I run my docker image.
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
arm-none-eabi-gcc: internal compiler error: Trace/breakpoint trap signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

@christophermclellan Could you provide any updates on this? Please let us know if you require any additional information.

Hi all,
Thanks for this thread, it really is a lifesaver! Although I have a different use-case that I need help with. I'm doing some cross-compilation on aarch64 and I need to be able to run a binary which is x86 (it is precompiled part of the sdk, I don't have source code to recompile it for aarch64). So far, I was compiling on amd64, it compiles but super-slow (dd-wrt, openwrt, yocto kinda build) I'm giving it a go with rosseta now. It would be much better if I could run rosetta on my aarch64 container image, and run those few binaries with rosetta to complete my build. Is it possible to run x86 binary on aarch64 docker image and if it is, how to do it? Thanks in advance

Hi all,
Thanks for this thread, it really is a lifesaver! Although I have a different use-case that I need help with. I'm doing some cross-compilation on aarch64 and I need to be able to run a binary which is x86 (it is precompiled part of the sdk, I don't have source code to recompile it for aarch64). So far, I was compiling on amd64, it compiles but super-slow (dd-wrt, openwrt, yocto kinda build) I'm giving it a go with rosseta now. It would be much better if I could run rosetta on my aarch64 container image, and run those few binaries with rosetta to complete my build. Is it possible to run x86 binary on aarch64 docker image and if it is, how to do it? Thanks in advance
UPDATE: after enablign rosetta, it seems that I have it also in aarch64 image since I get the error rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2 but I can't find this anywhere, I was hoping it will be there out of the box. Should I rebuild the image perhaps with rosetta enabled?

I am also suffering a similar problem. Did you manage to find a solution @veljkomih?

Hi all,
was anybody able to run any Oracle docker image on MacOS using Rosseta2 with latest Docker Desktop? I am trying to run images from gvenzl but I am stuck at ORA-03113: end-of-file on communication channel.
alert_XE.txt

@pbednarcik latest docker and latest macOS here, running previously built MS SQL container just fine.
One thing that tripped me before though: Make sure only "Use Rosetta for x86/amd64 emulation on Apple Silicon" beta feature is enabled, not "Use containerd for pulling and storing images".

Hi everyone, just parsing through the above. Thanks for all the feedback.
We will look at (in priority order):

the assertion failed errors originally noted by @harmenius, and subsequently noted by many people on the thread
the issues noted with ElasticSearch and Java (from @donperi and @HarryHung)
oracle base container problem, noted by @jjimenez
ability to specify individual containers that should use rosetta emulation (requested by @Finn-Ko)

for now, i think we have all the data we need. if there is anything missing from this list, please let me know ! we'll get going on this very soon. we're balancing this with finishing off some other performance-related work we're doing on macOS.

Hi everyone, just parsing through the above. Thanks for all the feedback.
We will look at (in priority order):

the assertion failed errors originally noted by @Harmenius, and subsequently noted by many people on the thread
the issues noted with ElasticSearch and Java (from @donperi and @HarryHung)
oracle base container problem, noted by @jjimenez
ability to specify individual containers that should use rosetta emulation (requested by @Finn-Ko)

for now, i think we have all the data we need. if there is anything missing from this list, please let me know ! we'll get going on this very soon ~we're balancing this with finishing off some other performance-related work we're doing on macOS.~ and will send these issues through to Apple to request that they investigate.

If it also possible to look into DIND problem related to Rosetta too.
Link
Thanks

I have the same issues, when I'm trying to RUN apk upgrade on an alpine image.

I have the same issue when building NodeJS app on MacBook Pro M1.
Sometimes it happens, sometimes not, and I really have no idea why,

Happening for me when i am budiling a typescript/nextjs app after i enable rosetta
=> [builder 5/5] RUN yarn build                                                                                302.4s
=> => # info  - Loaded env from /app/.env.local
=> => # info  - Linting and checking validity of types...
=> => # assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
=> => # (ThreadContextVm.cpp:47 mmap)
=> => # assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
=> => # (ThreadContextVm.cpp:47 mmap)
Here is the Dockerfile

I have the same issues with nextjs based apps.
It seems like this fixed it for a day, then after a few reboots it breaks again.
softwareupdate --install-rosetta --agree-to-license
According to the JAMF MDM site, the install is flakey.
There are some user provided scripts to repeatedly attempt installation as a work around.
https://community.jamf.com/t5/jamf-pro/intermitent-rosetta-install-failures/td-p/270349

I had the Rosetta 2 feature enabled and ran into this problem when I ran docker compose --build on M2 Apple Silicon. it exit with an error when executing the nodejs less command.

#0 50.20 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#0 50.20 (ThreadContextVm.cpp:47 mmap)

failed to solve: executor failed running [/bin/sh -c npm run build:css]: exit code: 123

I knew that I could build this image on an M1 chip machine, so after some trial and error, I used higher version of the docker-compose (hyphenated) command instead of docker compose, and was able to build it successfully.
software versions
$ docker compose version
Docker Compose version v2.15.1
$ docker-compose version
Docker Compose version 2.16.0

$ sw_vers
ProductName:		macOS
ProductVersion:		13.2.1
BuildVersion:		22D68
$ uname -a
Darwin SakamossannoMac-mini.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:43 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8112 arm64

Running with -t does not solve the issue for me.
Once I get a crash, subsequently launching process crashes too.
Scraping channel<PHONE_NUMBER>62408277
Resolving channel(s)...
Exporting 1 channel(s)...

💫 Scraping / general ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  19%
                                                                   assertion failed [block != nullptr]: BasicBlock requested for unrecognized address
(BuilderBase.h:550 block_for_offset)
---------- DONE<PHONE_NUMBER>62408277) ----------
Scraping channel<PHONE_NUMBER>77286154
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE<PHONE_NUMBER>77286154) ----------
Scraping channel<PHONE_NUMBER>61691136
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE<PHONE_NUMBER>61691136) ----------
Scraping channel<PHONE_NUMBER>86531348
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE<PHONE_NUMBER>86531348) ----------
Scraping channel<PHONE_NUMBER>72682863
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)

@christophermclellan is there a way to programatically enable or disable rosetta emulation in docker desktop? similar to how you can enable compose v2 using docker-compose enable-v2 / docker-compose disable-v2

+1

Hi @stuartmilne I have resolved my issue. I'm now able to fully cross-compile anything using aarch64 images of ubuntu. I simply had some of those binaries run with qemu, and that is it. Everything else, which is 99,99% of the codebase, I was cross-compiling natively on aarch64 and compilation time downsized like 10 times :) If I run with platform=amd64 and run it on rosetta, it was also much faster than original one without rosetta. But, since I can run in native image, I don't care now platform=amd64

I am also suffering a similar problem. Did you manage to find a solution @veljkomih?

Hi @stuartmilne I have resolved my issue. I'm now able to fully cross-compile anything using aarch64 images of ubuntu. I simply had some of those binaries run with qemu, and that is it. Everything else, which is 99,99% of the codebase, I was cross-compiling natively on aarch64 and compilation time downsized like 10 times :) If I run with platform=amd64 and run it on rosetta, it was also much faster than original one without rosetta. But, since I can run in native image, I don't care now platform=amd64

A similar error happens to me when trying to install ruby-ldap:
image ruby:2.7.7-alpine using platform=linux/amd64
sw_vers:
ProductVersion: 13.2.1
BuildVersion: 22D68
current directory: /usr/local/bundle/gems/ruby-ldap-0.9.20

make "DESTDIR=" clean
current directory: /usr/local/bundle/gems/ruby-ldap-0.9.20
make "DESTDIR="
compiling clientauth.c
compiling conn.c
conn.c: In function 'rb_ldap_conn_set_option':
conn.c:484:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   484 | optdata = (void *) NUM2INT (data);
       | ^
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
gcc: internal compiler error: Trace/breakpoint trap signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [Makefile:259: conn.o] Error 4

If you are trying to build any kind of image with something like this:
docker build --platform linux/amd64 -t XXX .
And you have "Use Rosetta for x86/amd64 emulation on Apple Silicon" enabled in Docker Desktop, just disable it. This will solve your issue.

Is that fixed ?

It seems to me the "solution" above is actually just disabling the currently beta use of Rosetta for emulation on Apple.
Certainly it gets around the assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping error, but as I understand it, we're then missing out on the performance improvements using Rosetta alleges to bring.
Is there another thread that perhaps could track this problem for anyone currently working on using Rosetta emulation?

Curiously, this was not occurring when I was using docker-compose to build and had the platform key set in the compose file.  Once I tried to use docker build directly, it started to occur.

Please, consider supporting rosetta.
There are many things broken in qemu, for example https://github.com/crystal-lang/crystal/issues/11703 this issue is full of it.
Also, building on top of old ruby x86 docker images is slow, because libraries require compilation. The same libraries are built much much faster on a much lower end x86 cpu.
I'm currently having issues building a few images and docker hangs on them. Sometimes during the build process, sometimes after (stuck on Creating on already running image, for example).
Also, some applications built on alpine x86 report ldd issues in wrong places, for example missing libssl is reported as missing libmusl.so.
This is not just a performance problem, this is also a compatibility problem. Using incomplete qemu emulation instead of apple-supported rosetta is in my opinion just wrong and a temporary solution at best.
Even apple supports your scenario - https://developer.apple.com/documentation/virtualization/running_intel_binaries_in_linux_vms_with_rosetta

@daliborfilus we do support rosetta, in the experimental settings, as documented above.

@justincormack I'm sorry, I didn't notice this setting in Docker Desktop settings before. My apologies.
(But you could excuse me I didn't read all the comments here, because there are too many. I just saw the issue as still open and the last few comments didn't reflect on the fact it's already available for testing.)

Hi, I've come across a different issue:
(Docker business support sent me here)
If I have "Enhanced Container Isolation" enabled along side "Use Rosetta for x86/amd64 emulation on Apple Silicon" then the container does not start, emitting an error:
rosetta error: Failed to get stack rlimit
So if I want the benefit of Rosetta I need to disable ECI.
Two steps reproduction

Make sure you have both ECI and "Use Rosetta for x86/amd64 emulation on Apple Silicon" enabled.
docker pull --platform=linux/amd64 hello-world
docker run --rm hello-world

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
rosetta error: Failed to get stack rlimit

I am still getting this error .3.9 building for production... #0 18.38 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping #0 18.38 (ThreadContextVm.cpp:47 mmap) when using a nextjs app that is set to build for platform amd64 on an ARM machine. If i disable the Rosetta for emulation in "Features in development" - it works, but its very slow. Is there any chance this will work on mac m1/m2 in the future?

Docker Desktop 4.20.1 (110738), enabled Rosetta for x86_64 code. Compilation using Crystal lang on Centos AMD64 image results in:
#0 5.367 Error target myapp failed to compile:
#0 5.367 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#0 5.367 (ThreadContextVm.cpp:47 mmap)

(I see this is already reported in this issue, I thought it would help to provide another app (crystal) as an example, so it's not node-specific.)

Have just experienced this issue building on M1 Mac with this simple script:

@Keoghan I just successfully ran this on Sonoma beta 2. This has been my 100% repeatable test case up till now.
Anyone who has the capacity to run Sonoma (i.e. you have a spare Apple Silicon Mac you can afford to have break), I’m curious if this is fixed.

Hi folks, thank you all for the feedback enclosed above. We’ve been working with Apple and passing your reported issues through to them. They have fixed a lot of these, which is great news.
For those that have reported an issue (e.g. assertion failed) could you try to re-test with the latest version of Rosetta, which you can get via softwareupdate --install-rosetta ? If that doesn’t work, some of the fixes are only included in the beta for macOS Sonoma, which is available for download via the Apple Beta Software Program.
We look forward to hearing whether your issues have been resolved, either via the rosetta update, or the OS update.
Thanks in advance for any feedback !

Hi folks, thank you all for the feedback enclosed above. We’ve been working with Apple and passing your reported issues through to them. They have fixed a lot of these, which is great news.
For those that have reported an issue (e.g. assertion failed) could you try to re-test with the latest version of Rosetta, which you can get via softwareupdate --install-rosetta ? If that doesn’t work, some of the fixes are only included in the beta for macOS Sonoma, which is available for download via the Apple Beta Software Program.
We look forward to hearing whether your issues have been resolved, either via the rosetta update, or the OS update.
Thanks in advance for any feedback !

I am happy to report that after running softwareupdate --install-rosetta and updating Docker Desktop to 4.20.1 (110738) and turning on Rosetta again in Settings > Features in development, the image that used to cause the assertion failed issue now successfully builds and runs for me. It seems to me you people nailed it. Well done!

Updated to Docker Desktop v4.21.1 and ran softwareupdate --install-rosetta.
Sadly, the error remains and I cannot update to Sonoma as I am working with a company laptop.
  	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
  	at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
  	at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
  	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
  	at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408)
  	at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736)
  	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
  	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
  	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
  	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
  	at net.cgps.wgsa.paarsnp.PaarsnpMain.run(PaarsnpMain.java:125)
  	at net.cgps.wgsa.paarsnp.PaarsnpMain.main(PaarsnpMain.java:83)
  Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 26, exit value: 1
  	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
  	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:319)
  	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:250)
  	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
  	... 21 common frames omitted
  Exception in thread "main" java.lang.RuntimeException: java.io.IOException: Cannot run program "blastn": error=0, Failed to exec spawn helper: pid: 26, exit value: 1
  	at net.cgps.wgsa.paarsnp.core.lib.blast.BlastRunner.apply(BlastRunner.java:57)
  	at net.cgps.wgsa.paarsnp.ResistanceSearch.apply(ResistanceSearch.java:45)
  	at net.cgps.wgsa.paarsnp.PaarsnpRunner.apply(PaarsnpRunner.java:48)
  	at net.cgps.wgsa.paarsnp.PaarsnpRunner.apply(PaarsnpRunner.java:23)
  	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
  	at java.base/java.util.stream.ReferencePipeline$11$1.accept(ReferencePipeline.java:442)
  	at java.base/java.util.Collections$2.tryAdvance(Collections.java:4820)
  	at java.base/java.util.Collections$2.forEachRemaining(Collections.java:4828)
  	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
  	at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
  	at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
  	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
  	at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408)
  	at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736)
  	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
  	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
  	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
  	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
  	at net.cgps.wgsa.paarsnp.PaarsnpMain.run(PaarsnpMain.java:125)
  	at net.cgps.wgsa.paarsnp.PaarsnpMain.main(PaarsnpMain.java:83)
  Caused by: java.io.IOException: Cannot run program "blastn": error=0, Failed to exec spawn helper: pid: 26, exit value: 1
  	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
  	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
  	at net.cgps.wgsa.paarsnp.core.lib.blast.BlastRunner.apply(BlastRunner.java:45)
  	... 19 more
  Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 26, exit value: 1
  	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
  	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:319)
  	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:250)
  	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
  	... 21 more

Hi @christophermclellan, some reports:
MacOS Ventura 13.4.1, having updated Ventura as instructed:

@Keoghan's test, docker run --rm -it laravelphp/vapor:php82 sh, docker-php-ext-install exif fails even faster with "rosetta error: Failed to mmap slab for vm allocation tracker"
docker run --platform=linux/amd64 --rm -it alpine:3.5, apk update && apk add gcc, /usr/libexec/gcc/x86_64-alpine-linux-musl/6.2.1/cc1 crashes with "Segmentation fault"

I believe test 1 works on Sonoma now (I'll double-check in a moment), and test 2 never did. I'll come back and verify this shortly.

Don´t know if this is the right place to comment, excuse me in advance...
I´m new to M1 mac ad was going crazy with building and running images, which would fail or not and I couldn't find a pattern.
Here´s the use case:

Working on a php-fpm with ngnix image template to build on top (FROM).
if i built a "whole" image (FROM php-fpm:whatever) for my app  (Drupal) it would work
If instead i built a template image in a pipeline (Azure) and used FROM that image it would produce a php-fpm segmentation fault. No errors on build or run but php-fpm would fail with segmentation fault and SISVG error
If i built that template image on local it´d work.
Hadn't even considered that the arm architecture of the M1 would cause this. So after reading this and other posts I think i got it working...
First i specify platform '--platform linux/amd64 '  when buiding on my mac, as this is what the Azure pipeline will build and matches our prod envs. Also added "export DOCKER_DEFAULT_PLATFORM=linux/amd64" on .zshrc and on docker-compose service 'platform'. Just
then i got a bunch of "[result.value != EEXIST]: VmTracker attempted to allocate existing mapping" errors when building. Oddly, these would trigger at different points of the build. But would always break it.
So i turned off Rosetta experimental thingy in Docker and now it builds the template and i can build FROM the template...

When inspecting i see it´s architecture=amd64 so it seems safe. I´m not sure but i think the problem came from using FROM a amd64 image (built by Azure) when generating an arm64 image (mac local build).
Now, without Docker - Rosetta, builds are painstakingly slow . Like 20 times slower.

Was anybody able to successfully run Oracle docker image provided by Gvenzl running latest docker (4.21.1 with latest rosseta)?
Still getting:
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping

Was anybody able to successfully run Oracle docker image provided by Gvenzl running latest docker (4.21.1 with latest rosseta)? Still getting: assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping

@pbednarcik On Ventura, no, it fails like you describe.
On Sonoma beta 2, it appears to start up but then ends with "ORA-03113: end of file on communication channel". I assume that's not normal? I've never used these images before.

@atomicmattie regarding https://github.com/docker/roadmap/issues/384#issuecomment-1620700948

Hi @christophermclellan, some reports:
MacOS Ventura 13.4.1, having updated Ventura as instructed, and having updated Docker Desktop to
...
I also realized that there's a third test in this thread that works on both Ventura and Sonoma with the requisite updates: docker run --platform=linux/amd64 hello-world. That was mentioned by @kingtistel above.

I've retested and it still doesn't work. Do you have ECI enabled?

Was anybody able to successfully run Oracle docker image provided by Gvenzl running latest docker (4.21.1 with latest rosseta)? Still getting: assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping

@pbednarcik On Ventura, no, it fails like you describe.
On Sonoma beta 2, it appears to start up but then ends with "ORA-03113: end of file on communication channel". I assume that's not normal? I've never used these images before.

@atomicmattie - nope that's not normal. Seems like improvement in Sonoma 2. Hopefully one day it will work as for now I have to use Oracle via Windows installation in Parallels.

PHP with the OPcache extension still crashes, unfortunately:
rosetta error: futex(FUTEX_LOCK_PI_PRIVATE) failure: 35

Oracle now has a new container image for oracle 19 that is arm native.
see oracle container registry
I was able to run
docker run -d --name local_db container-registry.oracle.com/database/enterprise:<IP_ADDRESS>

and it took a while, but it setup the database and ran.  No more need for colima on apple silicon for this.
🎉
If you run into a problem authenticating you have to log in with
docker login container-registry.oracle.com

which, yes, means you need an oracle.com login

Was anybody able to successfully run Oracle docker image provided by Gvenzl running latest docker (4.21.1 with latest rosseta)? Still getting: assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping

see my message above about the new native image for oracle 19

Hi @bryansh! Welcome to the bug from hell 😉
Update: I'm on Sonoma beta 6 (public beta 5, build 23A5328b) now and an earlier crash I mentioned has been resolved. 🥳

docker run --platform=linux/amd64 --rm -it alpine:3.5, apk update && apk add gcc, /usr/libexec/gcc/x86_64-alpine-linux-musl/6.2.1/cc1 crashes with "Segmentation fault"

This unblocks at least one older stack I had been unable to use with Rosetta.
Also,

@atomicmattie regarding #384 (comment)

I also realized that there's a third test in this thread that works on both Ventura and Sonoma with the requisite updates: docker run --platform=linux/amd64 hello-world. That was mentioned by @kingtistel above.

I've retested and it still doesn't work. Do you have ECI enabled?

@kingtistel Apologies! I missed that detail. I don't have access to ECI—just the team tier.

Just wanted to say that please make this feature available in prod and not keep it in beta. This has saved me tonnes of headache running amd64 containers on M2 Mac. I say this because the app says that Beta features can be discontinued without notice and need this feature. Thank you.

I have gone through a variety of builds and had determined that cutting the proc down to 4 worked better than 1, as others had noticed, however this is not ideal so I kept investigating.
On my mac m1 (arch: amd64 through rosetta) where I'm doing a build of OpenSSL (gcc, make) and rust compilation, it seems that the whole culprit is VirtioFS. Ater switching to "gRPC FUSE" I have had zero issues where it hangs and pollutes the docker logs with file access problems.  "osxfs (Legacy)" setting also caused a long hang.
I would therefore highly suggest not using VirtioFS until it's fixed, and if using osxfs, make sure it works for you because it didn't for me. gRPC FUSE setting is twice as fast for me and doesn't hang no matter the number of procs allocated. I was manually setting makeflags for proc units in both rust and make, in addition to specifying cpu count for docker run. I am no longer needing to do either.
Apple M1 Pro
Docker Desktop 4.23.0 (120376)
Engine: 24.0.6
Compose: v2.21.0-desktop.1

The 4.24.0 release of Docker Desktop solved my issues in M1 Silicon.
https://docs.docker.com/desktop/release-notes/#4240

@mcabreb but you used platform: linux/amd64 ?

I don't know if this helps anyone, but I recently had issues with WordPress and MySQL in docker compose - although the recent docker already solved my issues with MS SQL, and the issue for the WordPress turned out to be a bit different.
The key issue is that I had docker-compose installed via homebrew. And this did not work well. I had to uninstall that, and restart my terminal window, etc. for the docker-compose from docker desktop to be used, and work.
I also needed to upgrade the specific images. I know this suggests that newer versions have ARM support already and hence is not exactly this issue. I did this before the docker-compose, so, I assume doing the docker-compose thing first would have worked also.

Hi, I've come across a different issue: (Docker business support sent me here) If I have "Enhanced Container Isolation" enabled along side "Use Rosetta for x86/amd64 emulation on Apple Silicon" then the container does not start, emitting an error: rosetta error: Failed to get stack rlimit
So if I want the benefit of Rosetta I need to disable ECI.
Two steps reproduction

Make sure you have both ECI and "Use Rosetta for x86/amd64 emulation on Apple Silicon" enabled.
docker pull --platform=linux/amd64 hello-world
docker run --rm hello-world

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
rosetta error: Failed to get stack rlimit

Diagnostic ID: 59ACAA94-FE89-4B40-80A2-608E2C4632A9/20230620115220

After updating to macOS Sonoma and Docker Desktop v4.24 - this issue is resolved.

@mcabreb but you used platform: linux/amd64 ?

@apoca I used platform: linux/arm64/v8 to build my docker. My problem was by building a system that called node js code before compiling C++ in an M1. Without Rosetta it built the project but very slowly. With Rosetta it would always hung during the node build. So I had to do first a partial build without Rosetta, stop the container, activate Rosestta, build the rest of the system. With release v4.24.0 all the system builds with Rosetta, including the node js part.

I got this after upgrade to last mac OS and Docker version:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fffff384a93, pid=24880, tid=140737436714688
#
# JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build 1.8.0_74-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x984a93]  oopDesc* PSPromotionManager::copy_to_survivor_space<false>(oopDesc*)+0x143
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /var/www/html/glamourosa/hs_err_pid24880.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp```

@apoca I also see that error with macOS Sonoma and Docker 4.24.0. It wasn't failing in prior OS/Docker versions.

I got this after upgrade to last mac OS and Docker version:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fffff384a93, pid=24880, tid=140737436714688
#
# JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build 1.8.0_74-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x984a93]  oopDesc* PSPromotionManager::copy_to_survivor_space<false>(oopDesc*)+0x143
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /var/www/html/glamourosa/hs_err_pid24880.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp```

Exactly the same issue here on M1 Max, Docker 4.24.0 and JDK 8-15 containers.

@marcdueker  @apoca Did you guys figure out whats wrong and how to fix it?

@MikhailPertsev1 unfortunately not, I did a rollback to Ventura 13.6. But there is also a dedicated thread for this issue: https://github.com/docker/for-mac/issues/7006

@MikhailPertsev1 is there a way to rollback to Ventura 13.6 other than "factory reset" of the macbook?

@marcdueker is there a way to rollback to Ventura 13.6 other than "factory reset" of the macbook?

As far as I know - no. I had to wipe everything to install Ventura.

@apoca , @marcdueker , and all others that are experience this problem: there is another open issue https://github.com/docker/for-mac/issues/7006
In the comments, you can see that there is a solution which works for many of us which suppose to  set you Docker -> Resource -> CPU Cores to 1 or 2 or even 4 worked for me.

Latest release 4.25.0
https://docs.docker.com/desktop/release-notes/#4250

Rosetta is now Generally Available for all users on macOS 13 or later. It provides faster emulation of Intel-based images on Apple Silicon. To use Rosetta, see Settings. Rosetta is enabled by default on macOS 14.1 and later.

Thank you all for your patience and support here, for testing new releases and letting us know what worked and what hadn't.
As you have noticed, Rosetta is no longer a Beta feature in Docker Desktop.
There have been quite a few issues reported here, and most of them also confirmed here as fixed in Sonoma. The most recent issue, the SIGSEGV/SIGBUS error when running Java images, https://github.com/docker/for-mac/issues/7006, has also been fixed in the latest Sonoma version, 14.1.
We will close this roadmap issue soon, but if you encounter any more problems with Rosetta, please let us know by opening an issue in docker/for-mac

Thanks for the continued work across all of these issues @MihaelaStoica.  I'll add a quick note that for Oracle, there is now an arm version of the image to work with, but running an amd image still doesn't work as expected.
docker run -d --name oracle_db --pull always --platform linux/amd64 container-registry.oracle.com/database/express:21.3.0-xe

still results in a container that doesn't run Oracle.
I'm still on Ventura, so that might be fixed on Sonoma.
I don't personally need this fixed right away, but it would be great as there is a licensing difference between the arm image that is available and the amd image that is available.
Congratulations on so much progress and so many improvements over time.

@jjimenez do you have the Command for the ARM-Image? If I'm trying to pull the image, I'll only find the AMD-Version not the ARM-Version.
docker run -d --name oracle_db --pull always --platform linux/arm64 container-registry.oracle.com/database/express:21.3.0-xe
21.3.0-xe: Pulling from database/express
Digest: sha256:dcf137aab02d5644aaf9299aae736e4429f9bfdf860676ff398a1458ab8d23f2
Status: Image is up to date for container-registry.oracle.com/database/express:21.3.0-xe
docker: image with reference container-registry.oracle.com/database/express:21.3.0-xe was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.

@MaLub I believe docker is not pulling the arm64 version because you already have an image matching the version (but not the platform). Try the following:

Go to docker desktop and search for express image under images. There you should identify the image and hopefully verify that it has a tag "AMD64" under it.
Remove/delete the image from docker desktop.
Execute again your command.

@jjimenez do you have the Command for the ARM-Image? If I'm trying to pull the image, I'll only find the AMD-Version not the ARM-Version.
docker run -d --name oracle_db --pull always --platform linux/arm64 container-registry.oracle.com/database/express:21.3.0-xe
21.3.0-xe: Pulling from database/express
Digest: sha256:dcf137aab02d5644aaf9299aae736e4429f9bfdf860676ff398a1458ab8d23f2
Status: Image is up to date for container-registry.oracle.com/database/express:21.3.0-xe
docker: image with reference container-registry.oracle.com/database/express:21.3.0-xe was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.

@MaLub, sorry if I'm not clear.  The issue I'm exposing is that the amd image should be able to run under rosetta emulation and doesn't.  There is an arm image for enterprise on version 19.19 (docker pull container-registry.oracle.com/database/enterprise:<IP_ADDRESS>)
You can use that if you follow the licensing requirements for enterprise

For the benefit of anyone who is wondering why the "Use Rosetta for x86/amd64" setting isn't showing up where everybody says it should be, it has been moved out of experimental section of the settings to the "General" section in the more recent versions of Docker Desktop.  Make sure that it is turned on.

I have a python container running from FROM --platform=linux/x86_64 python:3.10-slim-bullseye  and it is getting stuck when I run the following: RUN npm install -g yarn && yarn install && yarn cache clean && yarn build:css && yarn build:js which only happens when I leave the Use Rosetta for x86/amd64 emulation on Apple Silicon enabled.
Anyone else noticing any weird behaviour after enabling that option?
Already tried to build --no-cache, reinstall Docker app but none had success.

I'm on M1 (Sonoma 14.1) and Docker Desktop 4.25.1 (128006). I see this error while using --platform linux/amd64:
"rosetta error: bss_size overflow
%"

Thank you all for your patience and support here, for testing new releases and letting us know what worked and what hadn't. As you have noticed, Rosetta is no longer a Beta feature in Docker Desktop.
There have been quite a few issues reported here, and most of them also confirmed here as fixed in Sonoma. The most recent issue, the SIGSEGV/SIGBUS error when running Java images, docker/for-mac#7006, has also been fixed in the latest Sonoma version, 14.1.
We will close this roadmap issue soon, but if you encounter any more problems with Rosetta, please let us know by opening an issue in docker/for-mac

how about this one? https://github.com/docker/for-mac/issues/7075 . nextjs (npm build) with Rosetta on causes 1 cpu 100% and hang, and with rosetta unchecked SIGKILL , macos 13.6.1 , tested with latest 3 docker for mac releases (?4.2x, 4.25.1 , 4.25.2)

Not sure if it's related, but this issue also highlights an issue with running 64-bit images on M1 Macs in Rosetta 2: https://github.com/docker/for-mac/issues/6796
Basically, if you run this command to show the CPU information:
docker run -it --rm --platform=linux/amd64 registry.access.redhat.com/ubi8/ubi:latest lscpu

You'll see this on an M1/M2 Mac:
Architecture:        x86_64
CPU op-mode(s):      32-bit

But on an Intel Mac, Windows or Linux machine, you'll see:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit

I'm wondering if all these various M1/M2 Rosetta 2 issues are stemming from the above missing 64-bit CPU op-code support? I have some 64-bit images that will work fine on my M1 Mac, but then others will fail with strange segfaults or other kernel / disk access issues, but they all work fine on Intel machines.

Not sure if it's related, but this issue also highlights an issue with running 64-bit images on M1 Macs in Rosetta 2: docker/for-mac#6796
Basically, if you run this command to show the CPU information:
docker run -it --rm --platform=linux/amd64 registry.access.redhat.com/ubi8/ubi:latest lscpu

You'll see this on an M1/M2 Mac:
Architecture:        x86_64
CPU op-mode(s):      32-bit

But on an Intel Mac, Windows or Linux machine, you'll see:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit

I'm wondering if all these various M1/M2 Rosetta 2 issues are stemming from the above missing 64-bit CPU op-mode support? I have some 64-bit images that will work fine on my M1 Mac, but then others will fail with strange segfaults or other kernel / disk access issues, but they all work fine on Intel machines.

interesting , i've got this on, m1 , macos 13.6.1 , docker 4.25.2
Architecture:           x86_64
CPU op-mode(s):       32-bit

I got the same error with M3 Max 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:05 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6031 arm64
I was trying to create a Docker with Ubuntu 22.04 LTS and install bazel

The switch to requiring users to use Rosetta instead of QEMU appears to have broken things pretty significantly, and there does not appear to be an obvious way to revert to the old QEMU-based behavior in Docker Desktop for Mac.
It is really easy to reproduce the core issue here with a test comment like this:
$ docker run --rm --platform linux/amd64 --name mongo bitnami/mongodb:6.0

Unable to find image 'bitnami/mongodb:6.0' locally
6.0: Pulling from bitnami/mongodb
e1386674fd12: Pull complete
Digest: sha256:fa089cf67d876b2be0f3903819f6579b45b090575ae48dc42a33fd0936412231
Status: Downloaded newer image for bitnami/mongodb:6.0

mongodb 20:36:18.66 INFO  ==>
mongodb 20:36:18.68 INFO  ==> Welcome to the Bitnami mongodb container
mongodb 20:36:18.70 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
mongodb 20:36:18.72 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
mongodb 20:36:18.73 INFO  ==>
mongodb 20:36:18.75 INFO  ==> ** Starting MongoDB setup **
mongodb 20:36:18.82 INFO  ==> Validating settings in MONGODB_* env vars...
mongodb 20:36:18.98 INFO  ==> Initializing MongoDB...
mongodb 20:36:19.18 INFO  ==> Deploying MongoDB from scratch...
/opt/bitnami/scripts/libos.sh: line 346:   196 Illegal instruction     "$@" > /dev/null 2>&1

Note the Illegal instruction error message at the end. You get this when you run almost any binary inside the container.

Are there plans to allow people to revert to the old behavior until there is a fix that allows Rosetta to handle x86_64 properly?

Also, for the record, the lscpu output:
❯ docker run --rm --platform linux/amd64 --entrypoint lscpu --name mongo bitnami/mongodb:6.0
Architecture:                       x86_64
CPU op-mode(s):                     32-bit
Byte Order:                         Little Endian
CPU(s):                             8
On-line CPU(s) list:                0-7
Thread(s) per core:                 1
Core(s) per socket:                 8
Socket(s):                          1
Vendor ID:                          0x61
Model:                              0
Stepping:                           0x0
BogoMIPS:                           48.00
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Mitigation; __user pointer sanitization
Vulnerability Spectre v2:           Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 front

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.
In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart":

Note you may have to scroll down to see the option.

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.

No suspecting necessary ;)
From About the Rosetta Translation Environment | Apple Developer Documentation:

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the sysctlbyname function to check the hw.optional.avx512f attribute.

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.
In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart":
Note you may have to scroll down to see the option.

Yeah, that's what I ended up doing on my end to fix the error I saw here:
https://github.com/docker/roadmap/issues/384#issuecomment-1814228995

I was a bit surprised to find this thread (I really should have looked here first 🤦♂ ) - regardless I had been dealing with it on this ticket https://github.com/GoogleCloudPlatform/cloud-sdk-docker/issues/356.  The fix for me turned out to be either:

what is mentioned here (disable Use Rosetta for x86..)
or
run softwareupdate --install-rosetta --agree-to-license and then re-enable Use Rosetaa for x86..

works on my machine 🤷♂

The lack of AVX support in Rosseta 2 is something that is unlikely to change and the workarounds that Docker is providing appear to work around this well enough.
Either disabling Rosetta or using -e EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 for containers that need AVX, etc.

I was a bit surprised to find this thread (I really should have looked here first 🤦♂ ) - regardless I had been dealing with it on this ticket GoogleCloudPlatform/cloud-sdk-docker#356. The fix for me turned out to be either:
* what is mentioned here (disable `Use Rosetta for x86..`)
  or

* run `softwareupdate --install-rosetta --agree-to-license` and then re-enable `Use Rosetaa for x86..`

works on my machine 🤷♂

Unfortunately the softwareupdate method is not working for me, disabling Rosetta is the only guaranteed solution at the moment for the specific containers that reproduce the problem consistently.

I had an issue with Rosetta + Docker pegging the CPU on Apple Silicon. For anyone encountering this issue with Vite, I found that installing @rollup/rollup-linux-arm64-gnu and setting platform: linux/arm64 in the docker-compose.yml helped resolve this issue.

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.
In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart":
Note you may have to scroll down to see the option.

Thank you!
--platform linux/amd64 and this fixed my issue.

Hi guys,
I'm trying to make an image to be able to launch dedicated servers (Satisfactory in this case) via SteamCMD on a Mac M1 Pro.
For this I need a 64-bit Linux architecture.
However when I launch my image with the "--platform linux/amd64" option I get the following error: ERROR! Failed to install app '1690800' (Requires 64bit operating system)
When I run the "lscpu" command, the output returns:
CPU op-mode(s): 32-bit. Unfortunately when trying the solutions proposed above, none of them work.
Here are the steps to reproduce the bug:
Launch a debian container with the command: docker run --platform linux/amd64 -it debian /bin/bash
And run the following command sequence: export CPU_MHZ=2000 && apt-get update && apt-get upgrade -y && apt-get install software-properties-common curl wget unzip vim nano procps util-linux -y && apt-add- repository -y non-free && dpkg --add-architecture i386 && apt-get update && apt-get upgrade -y && apt-get install lib32gcc-s1 -y && mkdir steam-servers && cd steam-servers && curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf - && ./steamcmd.sh +force_install_dir ~/SatisfactoryDedicatedServer +login anonymous +app_update 1690800 -beta public validate +quit
Please remember to change the CPU_MHZ variable at the start of the command

Hi there.
The 4.29.0 is released and there is a dead loop for disabling Rosetta cause Docker Desktop insists to try to install it.
Rosetta should be optional. I don't have or want to have Intel based containers on my Mac.
The Docker Desktop will ask for installing Rosetta, when I clicked "Not Now", it showed a failed window, I clicked the "Disable Rosetta" button but it showed the required window again and again.
I've unchecked the "Use Rosetta for x86_64/amd64 emulation on Apple Silicon" option in the General settings.
How can I disable Rosetta in this version?

I can debug inside the Linux/amd64 container with the following steps:
# this will hang
ROSETTA_DEBUGSERVER_PORT=1234 ./main &

# gdb
gdb
(gdb) set architecture i386:x86-64
(gdb) file main
(gdb) target remote localhost:1234
(gdb) continue

But how can I analyze the coredump if the program crashed? I failed to find any doc related to this, does anyone konw how?