feat(bookworm): take Node.js from the official image instead of apt

[sidey79]

Why

The full image currently installs nodejs from Debian bookworm, which means Node v18.20.4 — end-of-life since April 2025, and bookworm will never ship anything newer. Copying the runtime out of node:22-bookworm-slim gives Node 22, supported until April 2027, and keeps the version under Renovate's control like every other pinned image.

The catch: platform coverage

No Node image is published for linux/386, and from Node 24 on arm/v7 is gone too:

	amd64	arm/v7	arm64	386
node:26 / 25 / 24	✅	❌	✅	❌
node:22	✅	✅	✅	❌
Debian nodejs	✅	✅	✅	✅

Node 22 therefore covers three of the four platforms the full image was built for. Rather than carrying an apt fallback for the one remaining platform — which would pin it to Node 18 anyway — the full image stops being built for linux/386.

The minimal image is unaffected and keeps all four platforms, linux/386 included. It is built by a separate step (target: with-fhem) and contains no Node.js at all.

Two things that a COPY does not give you

/usr/local is not free real estate. The base image is perl:5.40.5-bookworm, and perl keeps its own installation there (/usr/local/bin/perl, /usr/local/lib/perl5, plus cpanm and cpm). A blanket COPY --from=node /usr/local /usr/local would wreck the perl runtime. Only /usr/local/bin/node and /usr/local/lib/node_modules are copied, and npm/npx are re-linked.

A COPY resolves no dependencies. Node links against libatomic on 32-bit arm. The deb used to pull that in automatically; without it, linux/arm/v7 fails at runtime:

/usr/local/bin/node: error while loading shared libraries:
libatomic.so.1: cannot open shared object file: No such file or directory

libatomic1 is now installed explicitly in that layer.

Verification

Built the copy against the real perl base image per platform:

platform	result
linux/arm64	node=v22.23.3 npm=10.9.9 perl=5.040005
linux/arm/v7	failed on libatomic, then node=v22.23.3 npm=10.9.9 perl=5.040005

And applied the new layer to the current full image to check nothing else broke:

node=v22.23.3  npm=10.9.9  npx=10.9.9
perl=5.038005  Python 3.11.2
  GD              OK
  Inline::Python  OK
  DBD::SQLite     OK
  pychromecast   OK

Inline::Python and pychromecast matter here: Python stays on apt precisely because Inline::Python is linked against Debian's libpython3.11.so.1.0 and the 41 C extensions in dist-packages are bound to that ABI. This PR does not touch the Python layer.

Both Dockerfiles pass docker buildx build --check with no warnings.

What is not verified

No full multi-platform image was built end to end from here — that only happens in CI. The optional npm packages (alexa-fhem, homebridge-fhem, gassistant-fhem, tradfri-fhem) are guarded by IMAGE_LAYER_NODEJS_EXT, which defaults to "0" and is never set by the workflow, so CI does not exercise them. Anyone building with that flag moves from Node 18 to Node 22 across two majors and should test those packages.

Pre-existing bug surfaced by this PR: unconfigured packages on arm/v7 threaded

The first CI run failed on linux/arm/v7 (threaded) with exit code: 100 in the nodejs layer — but not because of libatomic1. apt tried to finish configuring packages left over from the extended layer:

Iconv.c: loadable library and perl binaries are mismatched (got first handshake key 0xa500080, needed 0xa400080)
dpkg: error processing package x11-common (--configure):
 installed x11-common package post-installation script subprocess returned error exit status 1

PERL5LIB points at XS modules built for the image perl 5.40 in /usr/local. dpkg maintainer scripts run Debian's /usr/bin/perl 5.36, which on threaded arm/v7 has the same archname (arm-linux-gnueabihf-thread-multi-64int) and therefore loads the image's Text::Iconv. The extended layer only runs set -x without -e, so this has been silently swallowed. The currently published image is affected:

ghcr.io/fhem/fhem-docker:5-threaded-bookworm	arm/v7	amd64
x11-common	half-configured	installed
unconfigured	ffmpeg, mplayer, libsdl2, libavdevice59, libice6, libaudio2 …	—

The fix unsets PERL5LIB inside the three RUN blocks that call apt after it is set (extended, python, nodejs). ENV stays as it is, so FHEM still gets it at runtime.

Reproduced on linux/arm/v7 with the threaded perl base image plus the core lib from the published image:

VORHER  exit=100 Status: install ok half-configured | Iconv.c: loadable library and perl binaries are mismatched
NACHHER exit=0   Status: install ok installed       | audit=0

On the published image, dpkg --configure -a without PERL5LIB repairs every pending package and ffmpeg runs again.

The same leak applies to packages installed at container start through the deprecated APT_PKGS in entry.sh; that path is not changed here.

Note

Only the bookworm variants are changed; the bullseye images are legacy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TQUFMNHUonVQShZWDP3vA5

[github-actions]

CPAN Build Report

✅ All CPAN builds are fine — 6 of 6 image/platform combinations verified successfully.

Per image details

Image	Platform	Result	Details
-bookworm	386	✅ ok	–
-bookworm	arm/v7	✅ ok	–
-bookworm	arm64	✅ ok	–
-threaded-bookworm	386	✅ ok	–
-threaded-bookworm	arm/v7	✅ ok	–
-threaded-bookworm	arm64	✅ ok	–

Full inventories, logs and per-image reports are available as workflow artifacts of the workflow run.