I have for some time stopped running NR directly on Pi devices below Model 3, for various reasons. But I still test NR on lower end Pi devices from an interest perspective. I just created a ARM v6 based build image that has NR with node 16 via --node16 install script option. Yes this is a pitfall, for a number of reasons.
When I run NR, I get the following error over and over:
#FailureMessage Object: 0xbef88ec8
Liftoff bailout should not happen. Cause: Armv6 not supported
As I understand it, this stems from the fact that official node builds don't support ARM v6 since v12 or before? So the NR script uses unofficial builds where applicable, right? I believe I have seen references to this in this forum on the subject.
So now it appears the unofficial node 16 build fails on Pi Zeros and such that are ARM v6 based. A few google references state that the following node start option, "--no-expose-wasm" was a possible workaround.
When I tried this, I revised the following line in the nodered.service unit file, "Environment="NODE_OPTIONS=--max_old_space_size=256 --no-expose-wasm". Is this the correct place to try such?
If so, I still get the error as noted above. If the bottom line is for the older Pi devices I just need to stay a v12, ok. But being curious, I wanted to confirm what I did in theory was correct for passing options to node per the nodred.service unit file.
Moreover, does masking WebAssembly, i.e. '--no-expose-wasm' break NR anyway? I have also found a few references about this option is ignored or not longer valid... but maybe that is different issue anyway.
I run Node-red on multiple Pi0W's (ARM v6) with node 16 and do not have this issue. When starting this is the output:
pi@pi:~ $ node-red-start
Start Node-RED
Once Node-RED has started, point a browser at http://10.0.0.222:1880
On Pi Node-RED works better with the Firefox or Chrome browser
Use node-red-stop to stop Node-RED
Use node-red-start to start Node-RED again
Use node-red-log to view the recent log output
Use sudo systemctl enable nodered.service to autostart Node-RED at every boot
Use sudo systemctl disable nodered.service to disable autostart on boot
To find more nodes and example flows - go to http://flows.nodered.org
Starting as a systemd service.
21 Feb 21:19:32 - [info]
Welcome to Node-RED
===================
21 Feb 21:19:33 - [info] Node-RED version: v2.1.4
21 Feb 21:19:33 - [info] Node.js version: v16.11.1
21 Feb 21:19:33 - [info] Linux 5.10.63+ arm LE
21 Feb 21:19:42 - [info] Loading palette nodes
21 Feb 21:20:10 - [info] Dashboard version 3.1.5 started at /ui
21 Feb 21:20:12 - [info] Settings file : /home/pi/.node-red/settings.js
21 Feb 21:20:12 - [info] Context store : 'default' [module=memory]
21 Feb 21:20:12 - [info] User directory : /home/pi/.node-red
21 Feb 21:20:12 - [warn] Projects disabled : editorTheme.projects.enabled=false
21 Feb 21:20:12 - [info] Flows file : /home/pi/.node-red/flows.json
21 Feb 21:20:13 - [info] Server now running at http://127.0.0.1:1880/
21 Feb 21:20:15 - [info] Starting flows
21 Feb 21:20:26 - [info] Started flows
21 Feb 21:20:27 - [info] [mqtt-broker:bb3f9356a464bace] Connected to broker: mqtt://10.0.0.111:1883
I am doing some more testing, I am not sure my issue is repeatable. So I will post more information soon. I have re-imaged a few SD cards, to just the point where NR is installed, easy to do with the automation I have. I am going to then watch the process in detail. This maybe something the automation has generated, when it applies the newer versions of node and npm.
The odd thing is, I have found several posts via Google that reference the same error message, but outline different details on how it was resolved. I did confirm one thing, when installed node 14 (unofficial version) on the image build exhibiting the error, the error disappeared, so that defined the scope as related to node 16, and on that point the various Google posts are consistent.
Yeah, I dropped back to 14. Works. Did not have home bridge, but that was one of the google references I did find in researching the issue. And, this is a simple setup, only node installation is that established by NR standard script as well as only the one instance of npm. One of the things I was looking for, was if the automation had deployed more than one version of node or npm instance on the given the device. I have validated thus far that should not happen per the automation tasking. The issue was discovered after the NR install was done and at a later point Node as upgraded from default 12 to 16.
