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

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

Most upvoted comments

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.

  • It fails on Both Intel and AMD based x86_64 hardware
  • It fails on AWS Arm64 hardware as well
  • It fails with the latest 8.0.6 qemu builds (as provided by the qemu-v8.0.4 tag of tonistiigi/binfmt
  • I’ve tried Ubuntu 22.04 and 23.10 base OS builds

@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 by onistiigi/binfmt Docker image tags, newer version of QEMU are released for buildkit- 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.

  • What debug options can I enable to try and get some useful debug information here?
  • Would trying to connect GDB to the spinning process help?

master doesn’t appear to fix it for me, testing 6.1.0