azure-search-openai-demo: failing invoking action 'provision'
Please provide us with the following information:
This issue is for a: (mark with an x
)
- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
Minimal steps to reproduce
azd up
Any log messages given by the failure
ERROR: deployment failed: failing invoking action ‘provision’, planning deployment: planning infrastructure provisioning: creating template: failed to compile bicep template: failed running bicep build: exit code: -1, stdout: , stderr: qemu: uncaught target signal 11 (Segmentation fault) - core dumped (signal: segmentation fault)
Expected/desired behavior
OS and Version?
macOS Ventura 13.3.1
Versions
Mention any other details that might be useful
Thanks! We’ll be in touch soon.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 4
- Comments: 21 (1 by maintainers)
Experiencing the same error using the devcontainer on macOS 13.3.1
For folks running into the ‘segmentation fault, core dumped’ issue, I spent some more time digging into this and it seems like there is an underlying bug with bicep when run on emulated amd64 linux containers. It seems tied some combination of running under the emulator via docker (I tried both qemu and the rosetta based emulation) and using a version of bicep compiled with .NET 7.0 (or this bug was introduced in the same release where the bicep team moved from using .NET 6.0 to build to .NET 7.0).
The dev containers use amd64 because when we authored them we didn’t have a great story for azd on linux/arm. We’ve made some investments here, but the support is still in beta so for folks that want to live on the bleeding edge, you can try installing the linux/arm version of azd and using native arm64 containers.
The installer script does not yet support downloading these binaries, but you can fetch them from the github releases page for our most recent release. I made the following edits to the Dockerfile:
The first change removes our flag that was forcing amd64 and the second change replaces the use of the install script with downloading the beta version for arm-linux and then “installs” it as the script would. With these changes, I was able to launch a native version of AZD in a dev container on my M1 MacBook and provision.
@acampb and @Ilarom you might give that a whirl. Note we also publish macos-arm64 versions as well to our github releases, if you wanted to use the arm native versions. We’ll be updating the install script to use these versions in a bit after we’ve gotten some more feedback from users.
Same
azd version 0.9.0-beta.2 (commit afa7ac6e839be8304b86b3df6b8525a97e48a532)
m1 mac 13.3.1
Same azd
azd version 0.9.0-beta.2 (commit afa7ac6e839be8304b86b3df6b8525a97e48a532)
azd version 0.9.0-beta.2
My hunch turned out to be incorrect - I was able to launch a devcontainer locally and confirm that
~/.azd/bin/
was a path inside the container, and thebicep
that was downloaded was the correct amd64 version, as we would expect when running in an amd64 devcontainer.I can reproduce the segfault as well. It is interesting -
bicep --help
does work, so we are clearly able to run at least some part of the bicep binary. Trying to get a better handle on what’s going on here.From the error message, I would hazard a guess that you are on an M1 mac and for some reason we are downloading the amd64 version of
bicep
and trying to launch it and that is failing when run under the emulator.It would be helpful to make sure you are on the latest version of
azd
and also delete~/.azd/bin/bicep
. This will causeazd
to download the newest version of bicep and for the correct architecture.