nodered/node-red:3.0.0 does not run on raspberry pi / Raspbian #319
Comments
|
Same happens for But |
|
What version of docker are you running? also can you confirm you are running a 32bit version of the Raspberry Pi OS? |
|
Probable duplicate of #296 |
|
same problem after update... |
|
Does adding |
work! thanks! |
|
@DanielWeigl & @snkku Can you run the following please:
And update with the output and also see if you can work out what version of libseccomp you have installed Also check for any OS updates |
|
I don't know if this will be useful but the screen shot is from a Pi4 running Buster with See
|
yes, its 32bit: It still fails after installing seccompt and setting clock_gettime64 But this works, as already noted by others: |
|
The correct solution is upgrade to Bullseye, install the back port mentioned above or run with |
|
Ah, thx - i see. After installing seccomp2 via it works - so i guess its nothing you can fix on your side, or? If so, we can close this issue. Or maybe at least a hint in the main readme so its easier to find? |
|
@hardillb it may be worth pinning this issue in GitHub to hopefully speed up any others finding the fix. |
|
Over two years and this is still broken. That's crazy. Well, at least I'm not the only one. I was ready to try jumping to a different OS, but I'm glad I didn't waste time with that. |
|
@Dubz I don't know what you mean, if you are running a up to date (not end of life) version of Raspbian and latest Node-RED docker containers then everything works just fine. The route cause of this was Alpine Linux moving to a 64bit field for measuring time, the fix is to ensure you are running a supported version of Raspbian and the work around is to add |
What about on 32-bit systems then? |
|
@Dubz time can now be represented by a 64bit number even on 32bit OS systems (this is because the old 32bit version will overflow in 2038) and the Alpine base image for the NR containers requires this support. But to be honest, you probably should not be deploying anything new on NR 3.0.2 or versions of Raspberry Pi OS that don't support the 64bit format time for many reasons, but mainly because both are no longer receiving any security updates. |
|
I agree with @hardillb about there being no barrier to running Node-RED 3 on Raspberry Pi. I am running Node-RED 3 on both 64-bit Bullseye and 64-bit Bookworm, and I am not using To the best of my knowledge, you only need to patch libseccomp2 on Buster systems. I think you need to patch all Buster systems, whether they are full 32-bit, mixed mode (32-bit user mode, 64-bit kernel mode) or full 64-bit. My own Pi journey began with 32-bit Buster and, for a time, I ran mixed-mode Bullseye but it was somewhere around the end of 2021 (or maybe early 2022) when I committed to full 64-bit, first for Bullseye, now Bookworm. Neither 64-bit Bullseye nor 64-bit Bookworm have ever had any issues running Node-RED 3. Ditto other containers (eg Mosquitto) that chucked-up 64-bit date problems along the way. Perhaps try running your system in mixed-mode? Append "arm_64bit=1" to More generally, I am not aware of any reason why you would want to run a Pi with a 32-bit OS. Granted, I only have Pi 4s and Zero2W; if your hardware isn't in the supported list, so be it. As far as I can see, 32-bit binaries run just fine in a 64-bit OS. Ditto armhf containers if an arm64 variant isn't available. But, if you are running some package in the belief that it will only work on a 32-bit OS, I'd advise re-confirming that. Basically, if you can't prove to your own satisfaction that you really must run a 32-bit OS, I'd suggest rebuilding on top of 64-bit Bookworm. I don't think you'll regret it. |
|
You are correct, the OS is the main culprit and needing updated to a more appropriate, supported OS. My apologies. I'm glad to know I can finally get back into this once time allows. |
I updated my nodered on my RaspberryPi to
latestand now it doe not does not run anymore:Steps to reproduce:
Image info:
System info:
The text was updated successfully, but these errors were encountered: