Upgrading RPi4 to 64-bit - Node-Red Bombs

Just a wild guess - could this be from a Node using native binaries that requires a rebuild? You could try running npm rebuild under your .node-red folder if you haven't already.

1 Like

At this point I'll try anything – I have a perfectly working 32-bit NR with 1.x influx – but if I move to 64 bit Raspbian, even before attempting anything with Influ, I have a dead NR. I'll try that now… (lights out)…

SO, powerup the RPI, stop node-red, npm rebuild from the .node-red directory (no obvious errors), reboot to be safe…..

AARCH64 RPI powers up… prompt… node-red-stop just to be safe…..

pi@rpi419buster:~:12:11[0]> node-red

3 Aug 12:12:04 - [info]

Welcome to Node-RED

It failed even faster? Does a clean NR with nothing added work?

I think I would be looking to follow Dave's sugggestion

Clean? - I have TONS of code in NR and a shedload of noeds - clean install would not do me any good.

I've tried every suggestion in here. I ran Dave's script with the --node14 flag to force a re-install. No discernable difference....

I don't think you have have installed the aarch64 version of nodejs. I don't think anyone here knows how to do that, or they would have replied. Googling for nodejs aarch64 pi does find some possible hits.

After a clean install if you copy the .node-red folder from your backups (except the node_modules folder) and run npm install in that folder then that should install all the required nodes for you.

to be clear here - are you talking aboug getting a clean install by just deleting the .NR folder? A clean Raspbian install is a non-starter as I have FAR moer than just NR on that system - Alexa and other speech systems, utilities etc all installed using "the script" which takes quite some time and needing lots of usernames and passwords :slight_smile:

It was @ristomatti that suggested that. I don't know what he had in mind.

However, another thought. uninstall nodejs by sudo apt remove nodejs and also remove the file /etc/apt/sources.list.d/nodesource.list
Run sudo apt update and then run the script again to see if it installs the aarch64 version. Though I don't hold out much hope.
Having done that what is in the nodesource.list file?

Doing that right now - exactly say you say....

(gap of 10 minutes while the script runs)

and the new nodesource.list says:
deb [signed-by=/usr/share/keyrings/nodesource.gpg] Index of /node_14.x/ buster main
deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] Index of /node_14.x/ buster main

Nope - sadly - exactly the same result.

Bare Node-RED runs just fine on 64bit ARM (I've been running it 64bit containers for ages)

My best guess is one of the nodes you have installed with a native component is doing pointer arithmetic and ending up with something that isn't properly aligned (one of the reasons for a SIGBUS)

I suggest you enable core dumps (run ulimit -c unlimited iirc) before starting node-red from the same shell session. Then fire up gdb to get the stack trace from the core file, it should at a minimum tell you which library/binary the access came from which will point to the node at fault.

Is that running on a true 64 bit OS or raspbian with the edit in the boot config file to tell it to run the 64 bit kernel? I believe that the userland stuff is still 32 bit but I don't know enough about it to fully understand the setup.

Ahh, I'd missed that from the start

I'm using the proper full 64bit Raspberry Pi OS builds (Index of /raspios_lite_arm64/images)

Just swapping in a 64bit kernel is not a path I would even bother to entertain.

I would have no idea how to upgrade RPI to 64 bits other than the rpi-update route and changing config.txt.

Surely thats the point of rpi-update?

My understanding is that the config.txt mod changes the mode the kernel is running under to 64 bit so that memory management and suchlike runs faster. User apps still run in 32 bit however. To run in true 64 bit mode you would have to start again and burn the 64 bit version of Raspbian to the card. Then you would have to install 64 bit versions of any apps you wanted, or use multiarch to run the 32 bit versions.

1 Like

Which of course is fine for someone playing with the Pi and with far too much spare time on their hands - enough to go searching out programs and credentials to re-install - but not for the many users with long-term in-use application bases set up with credentials they may barely remember.

Oh well, it was a good idea. Unless anyone knows better, I'll stick with Influx 1.8 and my 32-bit Raspbian - even in here with people who know their stuff, this conclusion took a while - best recommendation for existing users seems to be to stay with 32 bit.

My current istallation has upgraded with me since JESSIE without having to start from scratch - is currently at the 32-bit Raspberry PI OS - I'm running Node-REd from a few fays ago and InfluxDB 1.8.6 and Grafana 8.0.6 - all work perfectly so you can see my reluctance to start from scratch - and thats only part of it - the PI is my VPN server and serves up Amazon speech.

Presumably one could build influx 2.0 on the pi, or possibly the next raspbian will include it in the repository.

Personally, I have no intention of moving to influx 2.0 at the moment. I suspect it is still in a state of flux ( sorry ). As I do new stuff I am using the flux query language with 1.8 in order to simplify the migration if I do eventually switch.

You;ve hit the nail on the head, Colin - the RPI team, given the popularity of 32 bit RPI should make a build for it for the latest Influx. That makes more sense than me re-inventing the wheel - but do the RPi team give two hoots about non-educational uses? I don't think so from experience so far. One can only hope.

You're miles ahead of me on the influx query language - up to now, all I've done - in NR is to convert msg.topic into msg.measurement and fire that off (payloads have to be numbers- important apparently) to Grafana so I can hav a shedload of statistics about my system (historically too - another reason not to start from scratch) - temperatures, battery and solar voltages, humidity, light levels - and so on.

If you get bored, do point me to using the flux query language with 1.8....

In any case this thread might be useful to anyone else who thinks (thought) like me that upgrading to 64 bit Pi should be easy.

Values in influx don't have to be numbers, but if you want to plot them with Grafana then they do. You can't plot strings on a graph, only numeric values.

In the latest influxdb config node you can say that you want to use flux with 1.8.

Sorry, my mind set is InfluxDB and Grafana as a unit.

Ok, I will – but for now – enough for one day – ta.