Node 10 is no longer supported. Please update - Exiting now.
Please check your hardware can support the latest version of nodejs.
You can force an install of node 12 or 14 by using the --node12 or --node14 parameter
However doing so may break some nodes that may need re-installing manually.
You may also need to update the versions of 3rd party nodes.
Please backup your installation and flows before upgrading.
I wonder whether something stronger there might be a good idea. Maybe something like Generally it is recommended to upgrade all nodes to their latest versions before upgrading nodejs
unless the latest versions have other breaking changes. - but yes - good thought - we could run npm outdated to show what is behind. (assuming npm is installed). so how about this
Running Node-RED install for user pi at /home/pi on raspbian
Node 10 is no longer supported. Please update.
Please check your hardware can support the latest version of nodejs.
You can force an install of node 12 or 14 by using the --node12 or --node14 parameter
However doing so may break some nodes that may need re-installing manually.
Generally it is recommended to upgrade all nodes to their latest versions before upgrading.
Checking for outdated nodes in /home/pi
Package Current Wanted Latest Location
@tensorflow/tfjs-node 2.6.0 2.8.6 3.6.1
Please backup your installation and flows before upgrading. Exiting now.
Sorry, now I read it again I am also concerned by that statement. I am not sure how one would go about performing that check. Are there systems running Debian and derivatives that run nodejs 8 that will not run 14?
Sorry Gentlemen, here in the USA our TAX fiiling deadline is today, so I was quite busy yesterday doing the final submissions and will be a little busy with work this morning as we made some big changes to a few MS SQL and MS IIS servers that service factory production equipment. (despite exhaustive verificcations on Thur and Frid, I still expect to find non working applications, issues...) I'll contribute to this discussion a bit later this evening or tomorrow.
I did however submit the install log and flow that you all asked about.
Ok - serious update pushed to the v2 branch linked above...
It now leaves nodejs alone - (but can be forced) - Warns about old nodejs (but not if you set nodered version 1.x). Correctly errors if npm not available (but doesn't check version). has an update nodes option - but only within scope of updates allowed by package.json... (ie not necessarily to latest)
Regarding the likes of these Siemens IoT boxes... If they are still deployed and used in the field, one wouldn't expect to be able to upgrade to the lastest node.js, nor node-red... they would just remain on their last supported releases, plugging along doing what they were put in place to do? They can remain viable and continue to provide value, but they aren't the way forward and you shouldn't expect to be able to indefinitely expand on the capabilities of obsolete hardware/software.
It's anagolous to systems I work with in plants that need to stay on WindowsXP or Windows7. They have to stay. They still do their job...but there are limitations in what can be done with them.
The way forward is deploying hardware that is and will be supported in the near term.
I'm going to tackle deploying this again, but in a different order. I'll do a clean install of RaspberryPiOS, nodeRED with the --node14 option... Do a full restart. Install of the questionable nodes via Palette Manager... And then import a Flow that uses them.I'll report back my results later.
Just ran this on an older VM that i use for testng and development.
Originally started life as as a V16 Ubuntu VM and was then upgraded (in place) to V18 LTS
Been running fine for two years.
I use this usually to first install the latest NR versions on.
Ran the new script on this - initially it complained it could do nothing with NodeJS V10 and aborted.
Ran again and give it the -v12 switch and the install went through fine - BUT there was an error
"npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2"
Node-red-start then spits a heap of errors about EXPAT modules
So in for a penny in for a pound - i then ran the script again with the node14 option and it went through and did the upgrade but still the same errors when starting
I am logged in as a normal user (pi) , running the command as that user (no SUDO) from within the home directory for pi and the .nodered subdirectory
Starting as a systemd service.
Error loading settings file: /home/pi/.node-red/settings.js
Error: Could not locate the bindings file. Tried:
→ /home/pi/.node-red/node_modules/node-expat/build/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/build/Debug/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/build/Release/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/out/Debug/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/Debug/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/out/Release/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/Release/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/build/default/node_expat.node
→ /home/pi/.node-red/node_modules/node-expat/compiled/14.17.0/linux/x64/node_expat.node
at bindings (/home/pi/.node-red/node_modules/bindings/bindings.js:93:9)
at Object. (/home/pi/.node-red/node_modules/node-expat/lib/node-expat.js:4:32)
at Module._compile (internal/modules/cjs/loader.js:1068:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
at Module.load (internal/modules/cjs/loader.js:933:32)
at Function.Module._load (internal/modules/cjs/loader.js:774:14)
at Module.require (internal/modules/cjs/loader.js:957:19)
at require (internal/modules/cjs/helpers.js:88:18)
at Object. (/home/pi/.node-red/node_modules/xml2json/lib/xml2json.js:1:13)
at Module._compile (internal/modules/cjs/loader.js:1068:30) {
tries: [
'/home/pi/.node-red/node_modules/node-expat/build/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/build/Debug/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/build/Release/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/out/Debug/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/Debug/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/out/Release/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/Release/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/build/default/node_expat.node',
'/home/pi/.node-red/node_modules/node-expat/compiled/14.17.0/linux/x64/node_expat.node'
]
}
Any ideas ?
I have a snapshot of this machine i can roll back to prior to the upgrade so no biggie
Hi @craigcurtin Do you happen to know which node dragged in node-expat ?
and then which version of that is installed - and did you upgrade it before upgrading nodejs/node-red ?
And ideally can you PM me the original package-lock.json file that is in the version 1 format.. ? And indeed the npm-shrinkwrap.json - thanks
(It should just be safe to delete npm-shrinkwrap.json and just use package-lock.json instead if I can do that only when necessary that would be good
PS have added a line to try to fix - so also feel free to retry latest.
No idea what node-expat is used for or which other node dragged it in.
No i have not doneany node upgrades for about 3 months or so.
What i usually do on the machines is take a snapshot of the VM at the start of every quarter and then update all the nodes through pallette manager - if everything goes OK for a week or so i will then delete the snapshot and leavethe system running with the new nodes - so my next set of updates was due in a week or so.
Will send over the package-lock file now - where will i find the shrinkwrap file ?
I will do another snapshot now as well and run the update script and report back
node-red/linux-installers/v2/deb/update-nodejs-and-nodered)
This script will remove versions of Node.js prior to version 12.x, and Node-RED and
if necessary replace them with Node.js 12.x LTS (erbium) and the latest Node-RED from Npm.
It also moves any Node-RED nodes that are globally installed into your user
~/.node-red/node_modules directory, and adds them to your package.json, so that
you can manage them with the palette manager.
It also tries to run 'npm rebuild' to refresh any extra nodes you have installed
that may have a native binary component. While this normally works ok, you need
to check that it succeeds for your combination of installed nodes.
To do all this it runs commands as root - please satisfy yourself that this will
not damage your Pi, or otherwise compromise your configuration.
If in doubt please backup your SD card first.
Are you really sure you want to do this ? [y/N] ? y
Would you like to install the Pi-specific nodes ? [y/N] ? n
Running Node-RED update for user pi at /home/pi on ubuntu
This can take 20-30 minutes on the slower Pi versions - please wait.
Stop Node-RED ✔
Remove old version of Node-RED ✔
Node option not specified : --node12 or --node14
Leave existing Node.js : v14.17.0 Npm 6.14.13
Clean npm cache -
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it! existing nodes
Install Node-RED core ✔
mv: cannot stat 'npm-shrinkwrap.json': No such file or directory
Move global nodes to local -
Leave existing nodes -
Install extra Pi nodes -
Add shortcut commands ✔/nodered-install.log
Update systemd script ✔
Is that really the package-lock.json file from your ~/.node-red directory ? It doesn't seem to have any Node-RED nodes in. and it also starts with a line "lockfileVersion": 2, which is at odds with the version 1 error message.
If there is an npm-shrinkwrap.json file it would be in the .node-red directory also (assuming you have ever run npm shrinkwrap)
For the next test :-).... can you rename any package-lock file in your ~/.node-red directory then run the update - as npm will recreate it anyway based on the package.json it should be safe.
