docker-node: npm hangs on linux/s390x containers
Environment
- Platform: linux/s390x
- Docker Version: 24.0.6, build ed223bc
- Node.js Version: 18
- Image Tag:18-alpine
Expected Behavior
npm install
runs and packages are installed.
Current Behavior
Trying to build a container on the linux/s309x platform hangs running npm install
with npm consuming 100% CPU.
Previous builds complete in less than 5mins, current build has been running for over an hour
We are building the https://github.com/node-red/node-red-docker container with
docker buildx build --platform linux/s390x --file .docker/Dockerfile.alpine --build-arg NODE_VERSION=18 .
Possible Solution
Steps to Reproduce
- Check out https://github.com/node-red/node-red-docker
cd node-red-docker
- run
docker buildx build --platform linux/s390x --file .docker/Dockerfile.alpine --build-arg NODE_VERSION=18 .
Additional Information
Same thing is happening with 14-alpine and 16-alpine tags
I’m hitting this both locally and in a GH Action, both of which use Qemu to support building for alternate architectures.
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 22 (2 by maintainers)
Commits related to this issue
- Remove s390x platform build, because of qemu bug Issue: https://github.com/nodejs/docker-node/issues/1973 — committed to mendhak/docker-http-https-echo by mendhak 7 months ago
report the similar in ticket #1946
I’ve been playing with this again (as it’s still a problem). I’ve been using AWS EC2 machines to try out a few different options.
@hardillb seems like after moby/buildkit#1516 we may omit using
setup-qemu-action
, because BuildKit supports QEMU emulation out-of-the-box. Even more, judging byonistiigi/binfmt
Docker image tags, newer version of QEMU are released forbuildkit-
images only. The last one is 7.1.0.However, for my repository the result is still the same, no matter which version is used: 6.0.0, 6.1.0, 6.2.0, 7.0.0, 7.1.0 or
master
.OK, while this appears to be limited to when running builds using qemu, this is going to be the default way 99% of CI builds run that target s390x, so I think we still need to track this down, even if it’s just to raise a sensible upstream issue against qemu.
master
doesn’t appear to fix it for me, testing6.1.0