Trouble running OpenMRS 3.x docker image on Apple M1(ARM64)

Hi, I was trying to install openmrs 3.x using the docker image. But for some reason, it fails to install and run the application.

When I start the containers, the backend suddenly crashes showing this error.

(The error log shows a JDK error)

The front end is running without any error, but it is extremely slow.

In the docker desktop app, I can see a warning saying that the images are built for amd64 architecture:

I am using a MacBook Pro M1 which has ARM64 architecture. So, probably that may be the reason for this error.

I think @anjisvj and @pasindur2 are also facing this issue. @ibacher could you please help us to solve this issue.

cc: @jayasanka

1 Like

yeah I’m also having the same issue

1 Like

We can try to test if an ARM-specific build will fix things. Unfortunately, I don’t have access to an M1, but if you checkout the 3.x branch of this project (git clone -b 3.0.0-alpha.4 --single-branch and then build it mvn clean install, you can then run the docker-compose in the run/docker subfile of that folder which should now be an ARM build of everything… assuming ARM versions of the base images we rely on exist.

If that works, we can look into how we get ARM versions of our images built automatically for you…


Hi @ibacher, thank you for the response. I tried building it by following your instructions, but the build fails and throws an error saying that the package.json file is missing. There’s a package-lock.json file inside the openmrs-distro-referenceapplication/package/ directory. But the package.json file is missing.

Error log: ARM build -

Could you try running this in a directory where there aren’t any spaces in the path?

1 Like

Oh right. It works! Thank you.

After building that and running docker compose, the backend and the database are working fine.

But the SPA frontend doesn’t display anything in the login page. It shows some errors in the console:

The esm versions in the actual frontend deployment are different than the versions shown in the error. I’ll try rebuilding it and let you know if the problem doesn’t get fixed

Update 2022-03-04T18:30:00Z: It works correctly with the latest version

Just wanted to stop by and say I haven’t forgotten about this. Docker’s multi-architecture support isn’t as easy to leverage as I was hoping.


When trying to run the image the frontend container throws the following error:

./ 8: ./ cannot open /var/www/ui/index.html: No such file

error opening output file: No such file or directory

Any thoughts?

@ibacher did you make any progress on multi-arch builds? I could definitely build it locally and publish to dockerhub to unblock people. On CI we will need to upgrade the linux kernel on Bamboo agents to support multi-arch builds. We were awaiting that for OCL as well.

@cintiadr are there any plans to upgrade kernels in not so distant future? If not, would it be okay for me to look into upgrading bamboo agents only or does it need to happen for all our instances for consistency?

Not really.

The good(ish) news on this front is that Jetstream is being retired in favour of Jetstream2; from the chat on the #infra channel on Slack, I think part of the migration will involve moving to at least Ubuntu 20.04, i.e., we’re going to have to migrate the infrastructure anyway…

It might be helpful if you could push the images out there.

Generally what happens here is that an earlier build step failed. If you look up in the log, you should see something shortly after Maven logs a message about running a long command that includes npm exec -- openmrs@... build . When this build fails, the index.html file doesn’t get created. Under some conditions (and I’m not really sure what those are), the webpack run triggered by openmrs build fails, but the openmrs executable (for some reason) doesn’t catch that, so the rest of the build proceeds as if it had succeeded.

Hopefully a git pull to get the latest version of the 3.x branch helps, but if you could post the full build log that would also be helpful.

Thanks @ibacher ! I built it again and rebuilt the image. The front end works fine now.

The DB container failed with this error. Then I temporarily upgraded the image to mariadb:10.7 and it worked.

However, the backend throws the following error:

For the backend error, try delete the lucene folder in your application data directory and then start again.

1 Like

Since this is Docker, if you don’t mind losing any data you might have locally, docker compose down -v will destroy the associated volumes which should handle both deleting the lucene directory (as @dkayiwa suggested) and undoing whatever caused some file to be created by MariaDB 10.7 (though I don’t think there’s a good reason we couldn’t support 10.7).

1 Like

Thanks, @dkayiwa and @ibacher running the down command helped!! :hugs:

@raff over the next months, we should be migrating to a new jetstream, which will get us with a new a new machine and new kernel

1 Like