[Docker Desktop for Mac] - Support for running x86-64 binaries with Rosetta 2 #384
Comments
christophermclellan
added
the
docker_desktop
|
@christophermclellan With this feature, we should be able to use Microsoft SQL server for Linux on M1. This would be awesome! |
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? |
|
@christophermclellan This would allow us to use Java Temurin images. Currently, they have been investing lots of time figuring out how to build images for m1, and it doesn't seem this will be solved anytime soon. Multiple other services would work amazingly, like Payara or MSSQL |
|
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 heroku/base-images#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 ventura, utm 4.04 beta & manual docker setup on macbook m1 air root@ub1:~# uname -a root@ub1:~# mount | grep rose root@ub1:~# ps -ef | grep rose |
Thank you @christophermclellan! |
|
I need to dev/run python on a x86_64 docker on M1 Macs. Looking forward to it! |
Heya, any news? 😄 |
|
This will be a game changer for our team, thank you for your hard work! |
|
MS SQL on Mac M1 is requested a lot, I think this would solve that issue too. |
|
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. |
|
@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. |
|
@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:
|
@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:19.19.0.0) 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 Anyone else noticing any weird behaviour after enabling that option? |
|
I'm on M1 (Sonoma 14.1) and Docker Desktop 4.25.1 (128006). I see this error while using |
how about this one? docker/for-mac#6998 . nextjs (npm build) with Rosetta on causes 1 cpu 100% and hang, and with rosetta unchecked it works but slow , macos 13.6.1 , tested with latest 3 docker for mac releases (4.24, 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: docker/for-mac#6796 Basically, if you run this command to show the CPU information: If you run this on an Intel Mac, Windows or Linux machine, you'll see: Which is what I would expect to see, both 32-bit and 64-bit op-mode support. However, if you run this on an M1/M2 Mac with Rosetta enabled, you'll see: It's missing the 64-bit op-mode support. Why? 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 |
|
I got the same error with |
|
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>&1Note the Illegal instruction error message at the end. You get this when you run almost any binary inside the container.
Also, for the record, the ❯ 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. |
No suspecting necessary ;) From About the Rosetta Translation Environment | Apple Developer Documentation:
|
Yeah, that's what I ended up doing on my end to fix the error I saw here: |
|
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:
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 |
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. The slightly annoying thing is that it keeps re-enabling itself after each time a software update is taken. |
|
I had an issue with Rosetta + Docker pegging the CPU on Apple Silicon. For anyone encountering this issue with Vite, I found that installing |
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 Unfortunately when trying the solutions proposed above, none of them work. Here are the steps to reproduce the bug: 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 +quitPlease remember to change the CPU_MHZ variable at the start of the command |
|
I’m experiencing insanely slow performance using —platform Linux/amd64, but I have to because one of the Python libraries I’m using doesn’t support arm I guess. I’m confused about why it’s so slow though - is Docker not using Rosetta 2 on Mac silicon for some reason? I know Rosetta 2 emulates fairly quickly with everything I’ve thrown at it so I don’t know why things run at snails pace on docker with —platform.. |
|
I can debug inside the Linux/amd64 container with the following steps: But how can I analyze the coredump if the program crashed? I failed to find any doc related to this, does anyone konw how? |
and others
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
The text was updated successfully, but these errors were encountered: