Docker fails for Mac M1 chip due to qemu bug

[mszell]

Update: I have searched around more and found that you are already aware elsewhere: darribas/gds_env#72 (comment) 👍
I guess I still leave this issue here as it also affects the install pages.

Hi,
I am trying to make the docker image run on a new MacBook Pro with an M1 chip (arm64), not an Intel chip (amd64).
Using gds version 6.1 I can run all the steps until I open the Jupyter lab on localhost:8888. Here I get a "Failed to fetch" kernel error and Jupyter crashes with the terminal message:

Operation not permitted (src/thread.cpp:309)
qemu: uncaught target signal 6 (Aborted) - core dumped

Already when I run the docker image I get this warning:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

I have searched around and it seems to be a bug with qemu on which docker relies: docker/for-mac#5148 (comment)
Same issue btw with the newer gds_py:7.0

Long story short, it seems one would need to have an arm64 docker container to make this run on Macs with an M1 chip. Since M1 have become mainstream this could be a good idea to look into. What would it take to create such an arm64 container?

(I have no experience with docker but if I can be useful I am happy to help out creating an appropriate container - I plan to teach this kind of material soon and want to avoid dealing with messy native installs).
Thx for the awesome work - Cheers!

[darribas]

Thanks very much for the report @mszell!!! I'm looping in @martinfleis who has some experience on this to let him weigh in.

[martinfleis]

Hi @mszell,
we are currently blocked by some packages that are not available for aarch64 on conda-forge. I have tracked down all of them and started migration but in some cases I need a cooperation from maintainers as they didn't compile on the first attempt. Once all packages are available, we can create aarch64 version of the container (at least gds_py flavour).

In the meantime, I recommend using conda/mamba that runs natively and installs arm64 versions. The best option is probably mambaforge https://github.com/conda-forge/miniforge#mambaforge.

I am keeping an eye on the migration of remaining packages and will post updates in darribas/gds_env#72 once I have some. I hope that the next iteration of the container will have both versions.

[mszell]

Thanks! For myself I had no problem with the native installs (the gds .yml worked like a breeze!), so maybe I will just recommend that for those students that have M1 chips (if any) - seems easy enough. The first class will be Feb 3. If you haven't managed to create the aarch64 by then no worries, happy to let you know my workaround then.

[martinfleis]

the gds .yml worked like a breeze!

Are you sure you are installing native versions? Because in gds.yml are some packages that do not have native version yet (like gstools). You can check that when doing conda list -c, all are either noarch or osx-arm64. Because you may be running conda under Rosetta 2 in which case it installs amd64 versions and everything is emulated.

[mszell]

Thanks, you are probably right. I am starting to lose the overview. It's https://xkcd.com/1987/ all over again, just with architectures..