Open christophermclellan opened 2 years 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!
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
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
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>
edit: The problematic services are always services for which I have specified platform: linux/arm64
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:
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.
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.
@christophermclellan Could you provide any updates on this? Please let us know if you require any additional information.
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.
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?
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):
assertion failed
errors originally noted by @harmenius, and subsequently noted by many people on the threadfor 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.
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. 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
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
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.
$ 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 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)
@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
+1
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 ?
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)
THE solution is just disable the option to use rosetta in docker configs 1- Click in docker icon in topbar
2- Settings
3- Settings wheel on the top
4-Features in development
5- Disable Rosetta Option
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.
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:
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.
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
I am still getting this error `.3.9 building for production...
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.
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 viasoftwareupdate --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.
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, and having updated Docker Desktop to
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. 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.
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.
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?
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