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)

Most upvoted comments

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:

index 2751d6c..55b1852 100644
--- a/.devcontainer/Dockerfile
+++ b/.devcontainer/Dockerfile
@@ -1,6 +1,8 @@
 ARG VARIANT=bullseye
-FROM --platform=amd64 mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}
+FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}
 RUN export DEBIAN_FRONTEND=noninteractive \
      && apt-get update && apt-get install -y xdg-utils \
      && apt-get clean -y && rm -rf /var/lib/apt/lists/*
-RUN curl -fsSL https://aka.ms/install-azd.sh | bash
+RUN mkdir -p /opt/microsoft/azd \
+     && curl -L https://github.com/Azure/azure-dev/releases/download/azure-dev-cli_0.9.0-beta.2/azd-linux-arm64-beta.tar.gz | tar zxvf - -C /opt/microsoft/azd \
+     && ln -s /opt/microsoft/azd/azd-linux-arm64 /usr/local/bin/azd

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

Hello guys. @acampb @Ilarom Can you please mention what azd version do you have run azd version

azd version 0.9.0-beta.2

Same azd

azd version 0.9.0-beta.2 (commit afa7ac6e839be8304b86b3df6b8525a97e48a532)

Hello guys. @acampb @Ilarom

Can you please mention what azd version do you have run azd version

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 the bicep 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 cause azd to download the newest version of bicep and for the correct architecture.