[ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.
I’m submitting a…
[ ] Regression (a behavior that stopped working in a new release)
[X] Bug report
[ ] Performance issue
[ ] Documentation issue or request
Current behavior
App launched via docker-compose-noproxy.yml: squidex container failing to launch.
Error is:
Unhandled exception. System.IO.IOException: Function not implemented
NB. I have updated the docker-compose to use mongo latest to bypass exit code 62 with unsupported version
I’m docker for mac, I performed the pruning/restart which resolved my mongo issue so I was able to use the docker-compose exactly as cloned. Still get the same issue for the Squidex container however
When running x86/amd64 code in a container on M1 the binaries are emulated with qemu. The emulation is not perfect and it can go wrong – I believe this is one of those times.
The ideal solution in terms of reliability and performance would be to have a native arm64 image.
I think this explanation makes sense. Dotnet core provides a base image for arm64, but I am not sure which other dependencies might fail. I cannot implement this, because I do not have a mac available and can therefore not test it, but PRs are very welcome.
I have therefore changed this topic to a feature request.
As I said before, It should be relatively straight forward to provide another Dockerfile for ARM and then add this to the CI. The cache should do the rest.
The problem is, that I cannot test it, therefore I do not want to do it myself.
Hey Sebastian,
I have freshly cloned the Squidex project (master) and tried to build the Docker image with the build.sh file. The first stage went through successfully, but in the 2nd stage, where the frontend builds, i get an error as shown in the screenshot. It looks like it has a problem with the npm run test:coverage command. Do you know this error, or did I forget to do something beforehand?
The frontend base image uses google-chrome-stable which is not available for arm64, but we can use Chromium. I got this to work by changing docker-puppeteer Dockerfile lines 9 to 17 (inclusive) to:
Then, change the squidex Dockerfile stage 2 FROM (line 45) to refer to the rebuilt frontend image, and below that add the line ENV CHROME_BIN=/usr/bin/chromium , then rebuild this image as well which should now go through without error including the Angular tests.
Finally, update your docker-compose.yml to point to the rebuilt Squidex image.
For what it’s worth, as a workaround: you should be able to run a x86 image on ARM by passing the platform param in the docker command when running it, and it should work as expected ( in most cases )
in the above discussion, they use linux/amd64 because that target platform was built, and pushed to dockerhub, but I’ve had a lot of success with using platforms that you’d assume wouldn’t work, like linux/amd64 ( I think this works because of rosetta, but I can’t be sure of that, it’s just my experience on a M1 ). So, I suggest choosing the closest published platform when choosing to do this, which is shown here:
and there is only the one platform, linux/amd64, so maybe try adding --platform linux/amd64 in all of the docker commands? I haven’t tried this myself, it may or may not work, just adding my personal experience.
