I think there's a bit of confusion here (understandable, given the complex state of the Apple Silicon / Docker ecosystem). Let me try to clarify / confirm a few things to hopefully aid us in making forward progress.
- Rosetta2 only supports macOS x86-64 userspace applications. As such, as soon as one is talking about x86 Linux Docker images then Rosetta2 is out of the picture - it has no role / ability to translate Linux applications.
- Docker-for-Mac for Apple Silicon has a somewhat complex software stack: It creates a hidden aarch64/linux Virtual Machine (using the built-in macOS Hyperkit framework), and then:
- For aarch/linux Docker image creates and runs a docker container inside the VM.
- For x86-64/linux Docker images it uses the same aarch64/linux VM, but then runs the x86-64/linux userspace applications using QEMU - an open-source, mutli-architecture emulator - see ref 1 - docker-for-mac/multi-arch.md.
Given the above, what I believe is happening with couchbase/docker issue #165 is that the user is trying to run our (x86-64) CB Server docker image under QEMU via Docker. It is QEMU which appears to have issues with some of the instructions emitted by go-1.8.5; but that is ultimately a QEMU/Docker-for-mac bug; nothing to do with CB Server par-se.
Note that running x86 docker images on Apple Silicon via Docker-for-Mac is only supported on a "best-effort" basis - quoting from the Docker-for-Mac Known Issues:
Not all images are available for ARM64 architecture. You can add --platform linux/amd64 to run an Intel image under emulation. In particular, the mysql image is not available for ARM64. You can work around this issue by using a mariadb image.
However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. In addition, filesystem change notification APIs (inotify) do not work under qemu emulation. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.
In summary, running Intel-based containers on Arm-based machines should be regarded as “best effort” only. We recommend running arm64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce arm64, or multi-arch, versions of their containers. We expect this issue to become less common over time, as more and more images are rebuilt supporting multiple architectures.
To back this up, demonstrating this isn't just a theoretical limitation and Docker are covering themselves, see these other bug reports about the embedded QEMU failing to run various other (x86) Docker images in this deployment - see 2 (postgres), 3 (neo4j), 4 (Jupyter)...
A choice quote to back this up from the Docker devs:
Running containers under emulation is documented as "best effort" only. We know that qemu sometimes crashes, but we have no control over that. Even when it works, it is likely to be low performance. The only long-term solution is to use multi-arch images, or images targetted at your native architecture.
Ok, so where does this leave us with respect to this bug? Well, as per the above quote there's probably little we can do if our x86-64 Linux CB Server images don't work correctly on Docker-for-Mac-for-Apple-Silicon - it's an issue / limitation with QEMU'e emulation. To the larger issue of how do Apple Silicon users run CB Server Docker images, I believe the answer to that is a native architecture (i.e. aarch64) image; which does not require QEMU (or Rosetta2) and can simply run natively on Apple Silicon machines.
As such, I propose this issue is resolved as "Not a Bug / Known Error" or similar; referring back to the Docker documentation about this not being a fully supported configuration.
: https://github.com/docker/for-mac/issues/6016 - Intermittent failures with certain amd64 images when using > 1 CPU (Apple M1)
: https://github.com/docker/for-mac/issues/6060 - Running amd64 neo4j container gets randomly stuck on M1
: https://github.com/docker/for-mac/issues/6097 - M1 Mac amd64 Jupyter kernel errors in Docker for Mac >= 4.1.1