Docker weirdness when building Elixir Phoenix project

Got a very strange issue with my build, I have a Dockerfile that builds and runs fine on my local machine (Mac M1 16Gb). I try and deploy with flyctl --app morning-field-8704 deploy .

See errors below (different but no config change, just tried again)

My question, how can the behaviour differ between my local machine and what Fly is doing?
(I have previously deployed this app and saw similar errors which got solved by upgrading the memory)

Help greatly appreciated.


=> [build 7/11] RUN mix do deps.get, deps.compile 36.7s
=> => # qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Then I tried again and got #15 5.272 could not compile dependency :earmark_parser, “mix compile” failed. You can recompile this dependency with “mix deps.compile earmark_parser”, update it with “mix deps.update earmark_parser” or clean it with “mix deps.clean earmark_parser”

Oof that’s a pain.

Will you try running fly deploy --remote-only and see if that gets you anywhere?

Trying it now - seems to be doing something.

1 Like

@kurt So that has worked! Amazing, thank you very much for your help. Is this a known issue?

1 Like

Well that’s good. I’m guessing there’s an issue building that x86 image on an m1 CPU. This could either be a bug in flyctl or a bug in Docker cross platform building. Assuming the --remote-only works, will you try building an x86 image with Docker directly and see if you get the same segfault?

@kurt I followed the instructions in the post you sent. Indeed the build does error out at the same point -

` => ERROR [linux/amd64 stage-1 5/10] RUN mix local.hex --force && mix local.rebar --force 0.5s

[linux/amd64 stage-1 5/10] RUN mix local.hex --force && mix local.rebar --force:
#11 0.494 qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Hope that is helpful.

Docker runs x86 images with qemu emulation which doesn’t always work on the M1. That segfault is somewhat of a known issue, but with the images being ran rather than Docker or flyctl. The best options are building with a docker daemon running on x86 system, like our remote builders or another docker host you manage.

It’s often intermittent, so maybe building with docker might help: docker build --platform linux/amd64

We’re contemplating doing remote builds by default on M1 Macs until these issues are fixed.

@michael Thats good to know. I sorted my issue so all is good. @kurt great shout!