Open corneliusroemer opened 7 months ago
This should be fixed! Many people complain about that online :-(
Limited workaround is to use colima instead of docker desktop, but with lots of downsides, e.g. more resource intensive, slower, less reliable etc.
Has anyone figured out a workaround for this issue? Unfortunately Supabase is not compatible with arm64 (at least not Bitnami's docker image for it), which means we need some way of emulating amd64 in our k3d environment.
Description
I'm making a new issue following up on:
because recent Docker Desktop for Mac releases no longer rely on QEMU.
The issues were closed as "blocked/upstream" pointing at this QEMU issue: https://gitlab.com/qemu-project/qemu/-/issues/750
However, now that Rosetta is used by default on latest macOS, the QEMU issue should no longer be blocking. However, it seems that the issue is still not fixed even when using Rosetta 2. Is there a new upstream issue, now in Rosetta? Or is QEMU still used to some extent?
Context: I'm trying to get k3s amd64 images to work but this fails as explained in this issue: https://github.com/k3s-io/k3s/issues/4720
Reproduce
docker run -it --platform linux/amd64 alpine:latest cat /proc/cpuinfo
Expected behavior
I get the cpuinfo in the layout of the emulated system, looking somewhat like this:
Actual behavior:
I get
docker version
docker info
Diagnostics ID
239B7F30-E6B8-4B1A-BC49-328E5B2FB8AA/20231115030111
Additional Info
If anyone has found a workaround for this general problem of kubernetes amd64 cluster on M1 mac let me know. I'm totally blocked right now.