When attempting to run any of the demos on an M-1 Chip machine, they fail due to a missing manifest within the docker dependancies. Running the MaEVe-based demos results in the following error...
Full MaEVe Failure
```
~/Documents/everest-demo user$ curl https://raw.githubusercontent.com/everest/everest-demo/main/demo-ac.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1111 100 1111 0 0 2053 0 --:--:-- --:--:-- --:--:-- 2057
[+] Running 1/3
✘ manager Error 2.3s
⠸ node-red Pulling 2.3s
⠸ mqtt-server Pulling 2.3s
no matching manifest for linux/arm64/v8 in the manifest list entries
```
And likewise, running CitrineOS results in the following...
CitrineOS Failures
This issue was originally found within this issue. For those without access to the internal repository, below is a copy of the findings:
Findings
## Issues with Apple Silicone
I've run into some issues running on Apple's M1 Chips. Below are the specs:
- VM: UTM (Running on MacOS 14.4.1), No VM (tested on MacOS hardware)
- Operating Systems Tested: Ubuntu 23.10, MacOS 14.4.1
- CPU: Apple M1 Pro
- 4 GB Ram
- Docker Version: Docker 26.1.2 (_not_ Docker Desktop)
And, the subsequent error when attempting to spin-up _any_ of the demos:
```
no matching manifest for linux/arm64/v8 in the manifest entries
```
From what I understand, this is an issue with one of our docker dependencies. When attempting a hack-y fix described [here](https://stackoverflow.com/a/73614527) and composing locally, we get a bit further -- the script fails with the following:
```bash
Attaching to manager-1, mqtt-server-1, node-red-1
mqtt-server-1 | exec /docker-entrypoint.sh: exec format error
mqtt-server-1 exited with code 1
manager-1 | exec /bin/sh: exec format error
node-red-1 | exec /usr/local/bin/npm: exec format error
manager-1 exited with code 1
node-red-1 exited with code 1
```
This is what makes me believe the issue is with our dependencies, not just the platform declaration (as described in the linked thread). Many of the posts I've read have suggested this is an issue with MySQL ([link](https://stackoverflow.com/q/65456814)), which doesn't seem relevant. These comments do have a common thread, however, suggesting that one of these dependancies is missing the `linux/arm64/v8` manifest.
Looking at EVerest's packages ([link](https://github.com/everest/everest-demo/pkgs/container/everest-demo%2Fmanager)), I do see `linux/amd64` listed within the OS / Arch tab... perhaps the packages in the`.yaml` need to be linked differently? I'll keep reading up on it, will add updates on this / the PyTest issue as I find more details!
Likewise, running a Virtual Machine hosted on an M-1 Chip results in a similar failure (Tested on UTM). Complete emulation of Linux Machines results in a successful launch of the demos, but performance is hindered to the point that this not a viable workaround.
Potential Solutions
As suggested within the original thread, I believe that this issue stems from one of the packages missing an ARM64 dependency. I recall during a discussion with the team that this could be traced back to the internal ghcr for everest, though I cannot find a papertrail for those thoughts. Ideally, this fix should be as simple as finding and updating the correct package within either the ghcr or docker manifests. I will continue to investigate further, and report back what I find!
The Issue
When attempting to run any of the demos on an M-1 Chip machine, they fail due to a missing manifest within the docker dependancies. Running the MaEVe-based demos results in the following error...
Full MaEVe Failure
``` ~/Documents/everest-demo user$ curl https://raw.githubusercontent.com/everest/everest-demo/main/demo-ac.sh | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1111 100 1111 0 0 2053 0 --:--:-- --:--:-- --:--:-- 2057 [+] Running 1/3 ✘ manager Error 2.3s ⠸ node-red Pulling 2.3s ⠸ mqtt-server Pulling 2.3s no matching manifest for linux/arm64/v8 in the manifest list entries ```And likewise, running CitrineOS results in the following...
CitrineOS Failures
This issue was originally found within this issue. For those without access to the internal repository, below is a copy of the findings:
Findings
## Issues with Apple Silicone I've run into some issues running on Apple's M1 Chips. Below are the specs: - VM: UTM (Running on MacOS 14.4.1), No VM (tested on MacOS hardware) - Operating Systems Tested: Ubuntu 23.10, MacOS 14.4.1 - CPU: Apple M1 Pro - 4 GB Ram - Docker Version: Docker 26.1.2 (_not_ Docker Desktop) And, the subsequent error when attempting to spin-up _any_ of the demos: ``` no matching manifest for linux/arm64/v8 in the manifest entries ``` From what I understand, this is an issue with one of our docker dependencies. When attempting a hack-y fix described [here](https://stackoverflow.com/a/73614527) and composing locally, we get a bit further -- the script fails with the following: ```bash Attaching to manager-1, mqtt-server-1, node-red-1 mqtt-server-1 | exec /docker-entrypoint.sh: exec format error mqtt-server-1 exited with code 1 manager-1 | exec /bin/sh: exec format error node-red-1 | exec /usr/local/bin/npm: exec format error manager-1 exited with code 1 node-red-1 exited with code 1 ``` This is what makes me believe the issue is with our dependencies, not just the platform declaration (as described in the linked thread). Many of the posts I've read have suggested this is an issue with MySQL ([link](https://stackoverflow.com/q/65456814)), which doesn't seem relevant. These comments do have a common thread, however, suggesting that one of these dependancies is missing the `linux/arm64/v8` manifest. Looking at EVerest's packages ([link](https://github.com/everest/everest-demo/pkgs/container/everest-demo%2Fmanager)), I do see `linux/amd64` listed within the OS / Arch tab... perhaps the packages in the`.yaml` need to be linked differently? I'll keep reading up on it, will add updates on this / the PyTest issue as I find more details!Likewise, running a Virtual Machine hosted on an M-1 Chip results in a similar failure (Tested on UTM). Complete emulation of Linux Machines results in a successful launch of the demos, but performance is hindered to the point that this not a viable workaround.
Potential Solutions
As suggested within the original thread, I believe that this issue stems from one of the packages missing an ARM64 dependency. I recall during a discussion with the team that this could be traced back to the internal ghcr for everest, though I cannot find a papertrail for those thoughts. Ideally, this fix should be as simple as finding and updating the correct package within either the ghcr or docker manifests. I will continue to investigate further, and report back what I find!