search

docker / roadmap

Welcome to the Public Roadmap for All Things Docker! We welcome your ideas.
https://github.com/orgs/docker/projects/51
Creative Commons Zero v1.0 Universal
1.74k stars 257 forks source link

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

Open christophermclellan opened 2 years ago

christophermclellan commented 2 years ago

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

siromega commented 1 year ago

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!

HarryHung commented 1 year ago

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

nikaro commented 1 year ago

With node:18-alpine image:

[...]
 => ERROR [frontend-base 4/4] RUN npm ci                                                              2.9s
------
 > [frontend-base 4/4] RUN npm ci:
#0 2.826 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#0 2.826 (ThreadContextVm.cpp:47 mmap)
------
Dockerfile:16
--------------------
  14 |       /opt/silvr/
  15 |
  16 | >>> RUN npm ci
  17 |
  18 |     # --------------------------------
--------------------
ERROR: failed to solve: process "/bin/sh -c npm ci" did not complete successfully: exit code: 133
Keoghan commented 1 year ago

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.
edwardsmit commented 1 year ago

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>

edit: The problematic services are always services for which I have specified platform: linux/arm64

JonathanFarina commented 1 year ago

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.

Tupeco commented 1 year ago 
#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:

neblik commented 1 year ago

This is crucial, Docker team please prioritize!

DougPlumley commented 1 year ago 
#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.

Maxwell2022 commented 1 year ago

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

MattAosta commented 1 year ago

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

vahanesac commented 1 year ago

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.

My base image is: ubuntu:20.04 and I am building docker image with --platform linux/amd64 with support for i386

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.
vahanesac commented 1 year ago

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

atomicmattie commented 1 year ago

Just want to throw out there that this isn't necessarily a Docker Desktop issue. Out of curiosity, I installed colima HEAD, re-ran some builds that had been failing with the "VmTracker attempted to allocate existing mapping" error, and they failed the exact same way.

I suspect Rosetta-on-Linux itself needs some improvement.

In the meantime, a remote Intel Docker build host (either something in the cloud or an Intel Mac, if you still have one) keeps me going. QEMU unfortunately is also unreliable in its own ways sometimes.

veljkomih commented 1 year ago

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?

stuartmilne commented 1 year ago

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?

pbednarcik commented 1 year ago

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

Meligy commented 1 year ago

@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".

christophermclellan commented 1 year ago

Hi everyone, just parsing through the above. Thanks for all the feedback.

We will look at (in priority order):

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.

mixmind commented 1 year ago

Hi everyone, just parsing through the above. Thanks for all the feedback.

We will look at (in priority order):

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

bendeguzvarju commented 1 year ago

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

M1ck0 commented 1 year ago

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. This should definitely be prioritized

docker build --platform linux/amd64 -t ...
#12 2.614 vite v4.1.4 building for production...
#12 2.702 transforming...
#12 4.276 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#12 4.276 (ThreadContextVm.cpp:47 mmap)
#12 4.860 npm ERR! path /app
#12 4.864 npm ERR! command failed
#12 4.868 npm ERR! signal SIGTRAP
#12 4.868 npm ERR! command sh -c vite build
hani-q commented 1 year ago

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


# Build Stage ************************************************************************************
# Rebuild the source code only when needed
FROM --platform=linux/amd64 node:16-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Disable telemetry during the build.
ENV NEXT_TELEMETRY_DISABLED 1

RUN yarn build
glade-at-gigwell commented 1 year ago

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

sakamossan commented 1 year ago

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

image

clouedoc commented 1 year ago

Running with -t does not solve the issue for me.

Once I get a crash, subsequently launching process crashes too.

Scraping channel 737009125862408277
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 (737009125862408277) ----------
Scraping channel 762540117377286154
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE (762540117377286154) ----------
Scraping channel 830411981961691136
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE (830411981961691136) ----------
Scraping channel 965541789186531348
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
---------- DONE (965541789186531348) ----------
Scraping channel 740986555572682863
Resolving channel(s)...
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
AbdullahWali commented 1 year ago

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

angoothachap commented 1 year ago

+1

veljkomih commented 1 year ago

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

gabrieltrita commented 1 year ago

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
i2rulloa commented 1 year ago

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.

Captura de pantalla 2023-04-19 a las 11 54 50

sostenesapollo commented 1 year ago

Is that fixed ?

I've ran docker build --platform linux/amd64 . -t imagetag

And this returns the following:

#12 23.59 warning link-preview-js > url > querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
#12 63.55 [2/4] Fetching packages...
#12 66.26 [1/4] Resolving packages...
#12 66.56 [2/4] Fetching packages...
#12 85.83 [3/4] Linking dependencies...
#12 86.43 assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
#12 86.43 (ThreadContextVm.cpp:47 mmap)

UPDATE (SOLUTION) :

THE solution is just disable the option to use rosetta in docker configs 1- Click in docker icon in topbar

image

2- Settings

image

3- Settings wheel on the top

image

4-Features in development

image

5- Disable Rosetta Option

mrthehud commented 1 year ago

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?

sblackstone commented 1 year ago

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.

bgracie commented 1 year ago

I'm unable to build my webpack bundle in an x86 Rosetta emulated container. The compilation proceeds to some midpoint (varies by each run but usually about 17%), and then hangs indefinitely, with one virtual CPU at 100%. The file it hangs on also varies. There is no log output that would help diagnose. Adding more CPUs does not solve the issue, and there is no shortage of memory. The bundle builds fine when the equivalent native ARM container is used.

Unfortunately I can't provide a full reproduction, but here are some of the key dependencies:

daliborfilus commented 1 year ago

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

justincormack commented 1 year ago

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

daliborfilus commented 1 year ago

@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.)

kingtistel commented 1 year ago

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

  1. Make sure you have both ECI and "Use Rosetta for x86/amd64 emulation on Apple Silicon" enabled.
  2. docker pull --platform=linux/amd64 hello-world
  3. 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

austinh commented 1 year ago

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 rosetta emulation feature will work on mac m1/m2 in the future? It would be very nice to have the performance.

daliborfilus commented 1 year ago

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.)

edit: Looks like it's a well known bug in Rosetta in specific conditions and it's on Apple to fix it.

atomicmattie commented 1 year ago

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.

christophermclellan commented 1 year ago

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 !

Harmenius commented 1 year ago

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!~

Edit: I double-checked and it seems I used docker build ., not docker build --platform linux/amd64 .. When using the latter command, I still get the failed assertion. I am nort part of the Beta Program so I cannot test further.

HarryHung commented 1 year ago

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
atomicmattie commented 1 year ago

Hi @christophermclellan, some reports:

MacOS Ventura 13.4.1, having updated Ventura as instructed, and having updated Docker Desktop to

  1. @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"
  2. 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. Update: confirmed. Test 1 is passing, test 2 is failing.

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.

Tahiche commented 1 year ago

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

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.

pbednarcik commented 1 year ago

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

atomicmattie commented 1 year ago

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.

kingtistel commented 1 year ago

@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? Screenshot 2023-07-14 at 16 06 58