Inconsistent or wrong architecture tags, cannot run or build on a raspberry pi 4

[dionjwa]

Environment

• Platform:
• Raspberry PI 4: Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
• Docker Version:

Client: Docker Engine - Community
 Version:           20.10.9
 API version:       1.41
 Go version:        go1.16.8
 Git commit:        c2ea9bc
 Built:             Mon Oct  4 16:06:55 2021
 OS/Arch:           linux/arm
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.9
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.8
  Git commit:       79ea9d3
  Built:            Mon Oct  4 16:04:47 2021
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.4.11
  GitCommit:        5b46e404f6b9f661a205e28d59c982d3634148f8
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

• Node.js Version:
• Image Tag:

Expected Behavior

Running node images that have the matching OS/ARCH should work.

Current Behavior

It's hit or miss:

pi@raspberrypi:~ $ docker run --rm --platform linux/arm/v7 node:16.11.1-alpine3.14


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbed0765c

pi@raspberrypi:~ $ docker run --rm node:16.11.1-alpine3.14


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbe84565c

But this works:

pi@raspberrypi:~ $ docker run --rm node:16.6 ls
bin
boot
dev
etc
home
lib
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

Possible Solution

I don't know whats going on here but there are related issues around building and running for arm where the platform architecture doesn't match:

• https://github.com/docker/for-linux/issues/1170
• https://github.com/docker/for-linux/issues/1025

Additional Information

[aguegu]

I believe it is related to the base image choice. I have tried arm32v7/node:16-slim, which is debian based, it works fine. But arm32v7/node:16-alpine, it still get

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbefa2634
Trace/breakpoint trap (core dumped)

But we still want alpine to be our baseimage, right?

[axelstudios]

Edit: It seems like the solution is to use Alpine 3.12 or lower

This is a very frustrating issue, particularly for cross-compiling with alpine images (and since v16 is the active LTS release). Here's a non-exhaustive list of Node images that I've tested on a Raspberry Pi 3 Model B with the command docker run --rm --platform linux/arm/v7 node:<TAG>. I have yet to see an issue with slim images:

Alpine Tag Alpine Version Success 17.1.0-alpine 3.14 ❌ 17.1.0-alpine3.13 3.13 ❌ 17.1.0-alpine3.12 3.12 ✔ 17.0.1-alpine 3.14 ❌ 17.0.0-alpine 3.14 ❌ 16.13.0-alpine 3.14 ❌ 16.13.0-alpine3.13 3.13 ❌ 16.13.0-alpine3.12 3.12 ✔ 16.12.0-alpine 3.13 ❌ 16.11.1-alpine 3.13 ❌ 16.11.0-alpine 3.13 ❌ 16.10.0-alpine 3.13 ❌ 16.9.1-alpine 3.13 ❌ 16.9.0-alpine 3.13 ❌ 16.8.0-alpine 3.13 ❌ 16.7.0-alpine 3.13 ❌ 16.6.2-alpine 3.13 ❌ 16.6.1-alpine 3.13 ❌ 16.6.0-alpine 3.13 ❌ 16.5.0-alpine 3.13 ❌ 16.4.2-alpine 3.13 ❌ 16.4.1-alpine 3.13 ❌ 16.4.0-alpine 3.13 ❌ 16.3.0-alpine 3.13 ❌ 16.2.0-alpine 3.13 ❌ 16.1.0-alpine 3.13 ❌ 16.0.0-alpine 3.13 ❌ 15.14.0-alpine 3.11 ✔ 15.0.0-alpine 3.11 ✔ 14.18.1-alpine 3.14 ❌ 14.18.1-alpine3.13 3.13 ❌ 14.18.1-alpine3.12 3.12 ✔ 14.18.1-alpine3.11 3.11 ✔ 14.18.0-alpine 3.11 ✔ 14.17.6-alpine 3.11 ✔ 14.5.0-alpine 3.11 ✔ 13.1.0-alpine 3.10 ✔ 13.0.1-alpine 3.10 ✔ 13.0.0-alpine 3.10 ✔ 12.22.7-alpine 3.14 ❌ 12.22.6-alpine 3.11 ✔ 12.22.0-alpine 3.11 ✔

Slim Tag Success 17.1.0-slim ✔ 17.0.0-slim ✔ 16.13.0-slim ✔ 16.5.0-slim ✔ 16.0.0-slim ✔ 15.14.0-slim ✔ 15.0.0-slim ✔ 14.18.1-slim ✔ 14.0.0-slim ✔ 12.22.7-slim ✔

[yosifkit]

Can you reproduce with the Alpine-provided package?

# make sure you are getting the arm32v7 image to have a valid comparison
FROM arm32v7/alpine:3.14
RUN apk add --no-cache nodejs npm
CMD [ "node" ]

If it works, then maybe something from their build process (or custom patches) could be useful? (https://git.alpinelinux.org/aports/tree/main/nodejs?h=3.14-stable)

[axelstudios]

It's reproducible with arm32v7/alpine:3.14, but it actually fails as soon as running apk add, or even ping. The root cause seems to be this change in Alpine 3.13, which is also detailed here.

Changing seccomp to unconfined works, but that's not an acceptable solution:

docker run --rm --platform linux/arm/v7 --security-opt seccomp=unconfined node:17.1.0-alpine3.14

Looks like one of the best solutions for Raspberry Pi OS is to manually update libseccomp to at least v2.4.2 (it has v2.3.3 currently). Node images with the latest Alpine base image work as expected after running the following:

wget http://ftp.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.3-1_armhf.deb
sudo dpkg -i libseccomp2_2.5.3-1_armhf.deb
sudo systemctl restart docker

[crnkofe]

Kudos to @axelstudios for the list. I had a Dockerfile with FROM node:lts-alpine suddenly start crashing on Raspbian/Raspberry 2. Switching to FROM node:lts-alpine3.12 fixed it.

[nschonni]

Switching to FROM node:lts-alpine3.12 fixed it.

That release is no longer supported and probably is missing several security patches

[aguegu]

The latest Raspbian 11 Bulleye could upgrade libseccomp2 to 2.5.1-1+rpi1+deb11u1

[erwineverts]

Default alpine image stopped working from version 16-alpine on armv7, cu

docker run --rm node:15-alpine --print 'console.log("Got here!")' works docker run --rm node:16-alpine --print 'console.log("Got here!")' does not work docker run --rm node:17-alpine --print 'console.log("Got here!")' does not work docker run --rm node:18-alpine --print 'console.log("Got here!")' does not work

Keeps failing with:

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0x7ef4a694

docker run --rm node:17-alpine3.12 --print 'console.log("Got here!")' works again

[yosifkit]

Default alpine image stopped working from version 16-alpine on armv7

As noted earlier, the answer is to update libseccomp on the host:

Looks like one of the best solutions for Raspberry Pi OS is to manually update libseccomp to at least v2.4.2 (it has v2.3.3 currently).

I also recommend updating docker too.

(related issues https://github.com/nodejs/docker-node/issues/1543, https://github.com/docker-library/postgres/issues/812#issuecomment-769499951, https://github.com/docker-library/redis/issues/269#issuecomment-778448769)