prisma: Prisma fails to generate artifacts with NodeJS Alpine image on M1 Mac

Bug description

Following the request from Jan here, I’ve created this as a new ticket.

While attempting to build/run prisma using a NodeJS Alpine image, prisma fails to generate artifacts during the postinstall script, as a result, running the application cannot find generated models and typescript type-checking fails.

When observing the npm install logs, I note the following error:

Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided. Which has been tracked before, but according to recent posts, this should still work within Rosetta 2 emulation, right?

I should note, that if I run a general FROM node:14, the project builds no problem, using FROM node:14-slim or alpine fails.

I’ve attached the docker build logs so you can see the failing script line here:

build-output.txt

How to reproduce

Use M1 Mac
Clone the following NestJS Prisma repo I’ve created: https://github.com/uncvrd/prisma-alpine-docker
Build the image using: docker build -t [IMAGE TAG] --target development --no-cache --progress plain .
Run the built image locally and observe the missing generated files

Expected behavior

I expect to be able to build and run using NodeJS Alpine on M1 Mac. I can confirm that this Dockerfile works as expected on an Intel Mac so I guess the Rosetta 2 emulation is not running as expected?

Prisma information

Prisma schema etc. is referenced in the repository above.

Environment & setup

OS: Mac OS Big Sur 11.4
Database: PostgreSQL
Node.js version: 14 (in docker image)

Prisma Version

prisma               : 2.21.2
@prisma/client       : 2.21.2
Current platform     : darwin
Query Engine         : query-engine e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : e421996c87d5f3c8f7eeadd502d4ad402c89464d
Studio               : 0.371.0

^ ran this inside the docker container, I do find it interesting that it shows darwin as this is an alpine image running in the docker container?

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 5
Comments: 24 (8 by maintainers)

Links to this issue

Pop!_OS 22.04 LTS post udpated issued

Commits related to this issue

Disable ARM64 build for the moment (https://github.com/prisma/prisma/issues/7755) — committed to alexandresoro/ouca by deleted user 3 years ago

Most upvoted comments

Not using Alpina will result in really large Docker images, so it would be helpful if binaries get made for this situation.

+22

stingalleman on Jul 20, 2021

Try remove package-lock.json and build again

+19

vedrigo on May 5, 2022

I was also facing the same issue with my Mac M1, and resolved by adding --platform-linux/amd64 right after FROM in respective dockerfile.

FROM --platform=linux/amd64 node:14.19.0-alpine3.14

+14

gamenic-dipendra on Nov 14, 2022

Hey @janpio I have now tested on 3 different devices using the referenced repo:

iMac M1: Fails during postinstall hook Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided
Macbook Pro M1: Fails during postinstall hook Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided
Macbook Pro Intel: Succeeds

Hope that helps, What can I help with next?

+13

uncvrd on Jun 19, 2021

I think you need to install openssl using apk if the image doesn’t contain openssl. Openssl is requirement for running Prisma.

https://pkgs.alpinelinux.org/package/edge/main/x86/openssl

I tried apk add openssl, and it got me a step further. Openssl seemed to need a file from libc6-compat, so I added that too, but then it still failed with a __res_init: symbol not found error.

As others have reported, this is only an issue for me using Alpine on M1. Debian on M1 seems to work fine.

+11

jrood on Dec 11, 2021

node:lts-alpine on m1 mac need aarch64-unknown-linux-musl target binary, and node:lts need aarch64-unknown-linux-gnu target.

See: https://github.com/Brooooooklyn/snappy/blob/main/.github/workflows/CI.yaml#L58-L62

Brooooooklyn on Jun 20, 2021

I was using the node:16-slim image, after changing it to node:16 the error disappeared.

thvozdovic on Jul 23, 2021

so this is probably a recurrence of that when running on Apple Silicon only

I’m running into a similar issue on an Intel Mac. I’m trying to build an arm64 image so I can eventually run it on a Raspberry Pi. The following command docker buildx build --platform linux/arm64 .fails with the following error: Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided.

This error only occurs when the Dockerfile extends from node:12-alpine, node:12 builds fine.

Tridie2000 on Jun 23, 2021

The platform matrix never seems to end 😅

pantharshit00 on Jun 21, 2021

I think you need to install openssl using apk if the image doesn’t contain openssl. Openssl is requirement for running Prisma.

https://pkgs.alpinelinux.org/package/edge/main/x86/openssl

pantharshit00 on Jul 20, 2021

Same here via docker buildx build --platform linux/arm64 .

Error: Unknown binaryTarget linux-arm-openssl-undefined and no custom binaries were provided

My binary targets:

binaryTargets   = ["native", "linux-arm-openssl-1.1.x"]

UPD: probably prisma 2.27 fixed this, need to check.

UPD: no, it’s not

UPD: just migrated to buster and works fine

Satont on Jul 20, 2021

Seems like relate to which version of Node docker image you use. I build it with some version like -slim or bullseye-slim, they all fail. But just regular version, it is fine

tianhuizhou on Oct 29, 2022

Wow thanks for that @Brooooooklyn, as usual. So seems we would need to build some more binaries… *sigh

janpio on Jun 20, 2021

Absolutely understand the low priority, luckily it’s not much of a blocking issue, in the mean time I’ll look in to building these images in the cloud.

uncvrd on Jun 19, 2021