I was trying to install rover using
curl -sSL https://rover.apollo.dev/nix/latest | sh
but kept getting this error Bad CPU type in executable
I came across this thread and I went ahead with what is suggested here to build and install rover from source, which worked for me.
But now running the following:
rover supergraph compose \ --config ./private/apollo_federation/supergraph.yaml \ --elv2-license accept > ./private/apollo_federation/supergraph_schema.graphql
gives me this error:
installing plugin 'supergraph-2' for 'rover supergraph compose'...
Downloading supergraph from https://rover.apollo.dev/tar/supergraph/x86_64-apple-darwin/latest-2
supergraph-2 was successfully installed. Great!
Composing supergraph with Federation v2.0.5.
error: Failed to execute command
Bad CPU type in executable (os error 86)
Can you please help me solve this issue?
Hi @akoul889 - I’m under the impression that Rover should work out of the box on an M1 machine because of Apple’s “Rosetta 2” software which emulates x86 code on the ARM chip. This should be installed already on your machine, but you can make sure by running
softwareupdate --install-rosetta. If this doesn’t fix your problem, it would lead me to believe that you might be trying to run these commands from inside a Docker container on an M1? In this scenario, Rosetta is not enabled unless you are running Macos Ventura (v13) because Apple wouldn’t attempt emulation. We are working on building native Linux ARM support for Rover but are blocked on some upstream releases that should be coming out in the next while or so. You can follow along with the progress of that initiative here.
@avery-harnish I’m sure you’re aware that this is also an issue with Apollo Router (and I’m sure whatever other binaries you all ship). Are your other products also included in this roadmap?
Additionally, I don’t think that we should be operating under assumptions here. You should actually try to run
rover on a M1 mac - it does not work. Try to run
router on a M1 mac - it does not work. I am admittedly extremely frustrated at the Apollo organization at the moment, so I apologize, but how the hell do you release a series of products whilst ignoring an entire segment of end-users?
@hobbsh - I have tested Rover on M1 machines and there are Apollo developers that use M1 machines to develop our internal supergraph. It works. We do not currently provide native prebuilt ARM binaries due to the fact that there are currently no CI providers that run on M1 machines because of Apple’s strict licensing requirements. As I mentioned earlier, we are working on prebuilt native ARM for Rover. You can follow along with the PR I linked in my comment above.
In the meantime, we do provide x86 builds that you can absolutely run on an M1 machine. I can troubleshoot a specific issue if you can provide me with an error message or other information.
This is console output from the Cloud M1 instance that I use for testing since my macbook is x86_64.
$ uname -m
$ curl -sSL https://rover.apollo.dev/nix/latest | sh
downloading rover from https://github.com/apollographql/rover/releases/download/v0.7.0/rover-v0.7.0-x86_64-apple-darwin.tar.gz
Writing binary to /Users/administrator/.rover/bin/rover
rover was successfully installed. Great!
If you would like to disable Rover's anonymized usage collection, you can set APOLLO_TELEMETRY_DISABLED=1
You can check out our documentation at https://go.apollo.dev/r/docs.
$ rover --version
@avery-harnish Sorry for the lack of clarification, I may have been blinded by rage. I forgot the detail that this is running in a docker container on a M1 mac, so the architecture is technically linux-aarch64.
Emulation support is quite poor apparently after heading down that path, so I don’t think that’s an appropriate solution for something like k3s or any other kubernetes-in-docker approach.
Sure - so I mentioned that this wouldn’t work unless you are running MacOS 13 in my above comment. We’ll have ARM linux binaries soon-ish. Hang tight.
You may be able to pass
--platform=linux/amd64 to your docker invocation to force emulation on your M1.
Emulation does not work properly as
qemu has its own issues when it comes to k3d and emulation can’t be forced for the cluster, thus all workloads on it need to be arm64.