Fixing Node-RED Palette Install Errors on Siemens IOT2050

Problem Summary

On a Siemens SIMATIC IOT2050 gateway running Node-RED, the Manage Palette install of nodes such as node-red-dashboard fails with a native compilation error, even though the same Node-RED and Node.js versions install the same palette without issue on an engineering laptop (e.g. Siemens PG M6 with an x86_64 CPU). The failure presents only on the IOT2050 and the log typically shows a node-pre-gyp, prebuild-install, or node-gyp error during the npm install stage triggered by the palette manager.

The two visible symptoms in the Node-RED log panel are:

1. Prebuilt binary lookup warning: prebuild-install WARN install No prebuilt binaries found (target=arm64 runtime=node arch=arm64 libc=glibc platform=linux) followed by an attempt to fall back to a local source build.
2. Native build failure inside the node-gyp step: gyp ERR! stack Error: not found: make or gyp ERR! find Python, terminating with make: *** [Release/obj.target/...] Error 1 and npm ERR! code ELIFECYCLE.

The issue is not a Node-RED core bug and not a problem with the target package's JavaScript source - it is an architecture / toolchain mismatch specific to the IOT2050's ARM64 image.

Root Cause: ARM64 vs x86_64 Prebuilt Binaries

Many Node-RED contrib nodes are not pure JavaScript. They depend on native modules such as:

• node-sqlite3, better-sqlite3
• bcrypt, argon2
• @serialport/bindings-cpp
• canvas, sharp
• node-rdkafka, node-zookeeper-client

These native modules are normally distributed as prebuilt binaries through the node-pre-gyp or prebuild-install services. The published manifest on the npm registry lists binaries for linux-x64, darwin-x64, darwin-arm64, win32-x64, but rarely for linux-arm64 unless the maintainer explicitly enables it. When no matching prebuilt is found, the install script falls back to a node-gyp source build, which requires:

• A C/C++ toolchain (build-essential, make, gcc, g++)
• Python 3 (or Python 2 on legacy nodes)
• Correct node-gyp version matching the installed Node.js
• Header files for the target Node.js version

The Siemens IOT2050 ships with a TI Sitara AM6528 / AM6548 SoC (dual or quad ARM Cortex-A53 cores, 64-bit, aarch64). When the example image or the IndustrialOS is used, the toolchain may be missing or the package's binding.gyp may be authored for x86_64. The build either fails because make is not present, or because the generated Makefile references x86_64-only flags. The same node-red-dashboard package on the engineer's Intel laptop finds a prebuilt for linux-x64 and the source-build path is never exercised - that is why "the same version" works on the laptop but not on the IOT2050.

Affected Hardware: Siemens SIMATIC IOT2050 Family

The condition is reproducible across the IOT2050 product family. Confirm the specific variant before applying the fix:

Reference the official product page on the Siemens Industry Online Support portal: SIMATIC IOT2050 product support and the corresponding Siemens Industry Online Support manuals (search the IOT2050 MLFB for the bundled Operating Instructions and Example Image Description). Hardware architecture, image versions, and the precise CPU stepping are documented in those PDFs.

Diagnostic Verification Steps

Run the following commands over SSH on the IOT2050 to confirm the architecture and the missing toolchain pieces before changing anything:

1. Confirm CPU and OS architecture
   uname -m → expected output aarch64
node -p process.arch → expected output arm64
cat /etc/os-release → record PRETTY_NAME and version (Example Image 1.x.x is Debian-based; IndustrialOS is a Siemens-managed image).
2. Confirm Node.js and Node-RED versions
   node -v
npm -v
node-red -v (or read ~/.node-red/package.json)
3. Confirm npm target architecture
   npm config get target_arch should return arm64
npm config get target_platform should return linux
4. Confirm the toolchain
   which make gcc g++ python3 → if any of these return nothing, the source build will fail.
5. Reproduce the failure from CLI
   cd ~/.node-red
npm install node-red-dashboard --no-audit --foreground-scripts 2>&1 | tee /tmp/nrd.log
   The full stack trace shows whether the failure is in prebuild-install or in node-gyp.

Resolution Method 1: Confirm Which Image is Installed

Siemens ships two different images for the IOT2050:

• Example Image - a Debian-based image with the full development toolchain (build-essential, python3, git, node-gyp). Source builds succeed on this image.
• IndustrialOS - a hardened, footprint-optimised image with no compiler toolchain. Source builds will fail because make, gcc and headers are not present.

Run dpkg -l | grep -E 'build-essential|gcc|make' on the device. If the packages are absent you are on IndustrialOS or a slimmed-down Example Image. This single fact determines which of the methods below will succeed.

Resolution Method 2: Install the ARM64 Build Toolchain

If you are on the full Example Image, install the missing pieces:

1. Refresh the package list:
   sudo apt-get update
2. Install the toolchain and Python:
   sudo apt-get install -y build-essential python3 make g++ libssl-dev
3. Install node-gyp globally so it matches the Node.js version shipped with the image:
   sudo npm install -g node-gyp
4. Rebuild any previously failed native modules:
   cd ~/.node-red
npm rebuild --build-from-source
5. Retry the palette install from the Node-RED UI or from CLI:
   npm install node-red-dashboard --no-audit

The official Node-RED documentation describes the build prerequisites in Adding nodes to your palette and the Node-RED FAQ covers the canonical answer to "my install fails - why?". For npm semantics, see npm install in the official npm CLI documentation.

Resolution Method 3: Force Native Compilation with --build-from-source

When the package's prebuilt is only available for linux-x64 and the postinstall script unconditionally tries to download it, override the prebuilt path and force a source build. This is the cleanest fix when the toolchain is present but the prebuilt is wrong:

1. Stop Node-RED:
   systemctl --user stop nodered (or kill the running process)
2. Run the install with the override:
   cd ~/.node-red
npm_config_target_arch=arm64 npm_config_build_from_source=true npm install <package> --build-from-source --foreground-scripts
3. Verify the resulting binary was compiled for ARM64:
   file ~/.node-red/node_modules/<package>/build/Release/*.node
   Expected: ELF 64-bit LSB shared object, ARM aarch64, ...
4. Restart Node-RED and confirm the new node appears in the palette.

Resolution Method 4: Use Architecture-Agnostic Nodes

For nodes that are pure JavaScript and have no native dependencies (most node-red-contrib-* packages, node-red-dashboard, node-red-node-ui-table, node-red-contrib-s7comm), the install succeeds regardless of architecture. For nodes that do pull native code, prefer either:

• The Node-RED "recommended" alternative that uses a different backend (e.g. node-red-node-sqlite for node-sqlite3), or
• A community fork that publishes linux-arm64 prebuilts - check the package's dist tags in the npm registry: npm dist-tag documentation.

Before installing, inspect a node's dependency tree for any of the native modules listed in the Root Cause section above:

Resolution Method 5: Use the Siemens Example Image (Recommended for New Devices)

For first-batch or unprovisioned IOT2050 units, Siemens historically delivered the device with a pre-installed Example Image that included the full toolchain and a working Node-RED. Newer firmware drops (post-Example Image 1.0.x) and the IndustrialOS deliver a slimmer image. The recommended path on a new device is:

1. Download the latest Example Image for the IOT2050 variant from the Siemens Industry Online Support portal (search the IOT2050 MLFB and look under Downloads → Firmware/Image).
2. Flash the image to a microSD card using the procedure in the bundled Operating Instructions PDF.
3. Boot the IOT2050, log in, confirm uname -m returns aarch64 and that build-essential is present.
4. Install Node-RED globally as documented in Node-RED local installation and the palette installation guide.
5. Retry the failing palette install.

The Example Image and its version history are documented in the Siemens Industry Online Support portal - search for the IOT2050 MLFB and the Example Image Description PDF.

Verification and Acceptance Test

After applying any of the above remediations, run the full acceptance sequence:

1. Package install completes with no errors:
   cd ~/.node-red
npm install node-red-dashboard --no-audit
   Expected: ends with added N packages in Ys and zero npm ERR! lines.
2. Native binary is ARM64 (only relevant if the package contains one):
   file ~/.node-red/node_modules/<package>/build/Release/*.node
   Expected: ELF 64-bit LSB shared object, ARM aarch64, ...
3. Node-RED loads the new node:
   Start Node-RED (node-red or systemctl --user start nodered), open http://<iot2050-ip>:1880, and confirm the new node is present in the left palette. Watch the boot log for node-red-contrib-<name> registered.
4. Module loads at runtime:
   In Node-RED, drop the new node onto a flow, deploy, and check the browser console and Node-RED log for module-load errors such as Error: /lib/x86_64-linux-gnu/libc.so.6: cannot open shared object file - the presence of that string means a prebuilt x86_64 binary is still on disk and needs to be rebuilt.
5. Persistent across reboot:
   sudo reboot, wait for the IOT2050 to come back, confirm Node-RED auto-starts (if using systemd unit) and that the palette still contains the previously installed node.

Troubleshooting Matrix

Engineering Notes and Edge Cases

• Same version, different CPU. Node-RED and Node.js versions are not the variable - the architecture and the published prebuilt manifests are. Always compare node -p process.arch and npm -v on both machines, not just the Node-RED version.
• IndustrialOS users. The IndustrialOS image on the IOT2050 is intended for production use and does not include a compiler. Adding build-essential to a production device is generally not recommended - prefer a dev image for build, then deploy a pre-built node_modules directory to the production unit. See Siemens' IOT2050 documentation on the Siemens Industry Online Support portal for the supported update path.
• npm registry behind a proxy. Many factory networks proxy HTTPS traffic. If npm install times out, configure npm config set proxy <URL> and npm config set https-proxy <URL> as described in the npm config documentation.
• Node-RED docker images. If Node-RED is run inside a container on the IOT2050, the same architecture rules apply. Use node-red/node-red-docker tags whose base image matches the device (e.g. -slim-v8 runs on ARM64; the older latest tag may not). See the Node-RED Docker image tags listing for available variants.
• Cross-compiling. For very large projects it is faster to build on an x86_64 build host with an ARM64 cross-toolchain (gcc-aarch64-linux-gnu) and copy the resulting node_modules to the IOT2050. This avoids touching the IOT2050 image.