I have Rasbian Stretch Lite set up in read only mode and installed NodeRED with the script (as per the website).
Using manage pallet to install the dashboard works fine. But after a reboot NodeRED does not start.
sudo journalctl -f -u nodered -o cat
returns:
at Object.saveNodeList (/usr/lib/node_modules/node-red/red/runtime/nodes/registry/registry.js:134:25)
at /usr/lib/node_modules/node-red/red/runtime/nodes/registry/loader.js:376:29
at tryCatchReject (/usr/lib/node_modules/node-red/node_modules/when/lib/makePromise.js:845:30)
at runContinuation1 (/usr/lib/node_modules/node-red/node_modules/when/lib/makePromise.js:804:4)
at Fulfilled.when (/usr/lib/node_modules/node-red/node_modules/when/lib/makePromise.js:592:4)
at Pending.run (/usr/lib/node_modules/node-red/node_modules/when/lib/makePromise.js:483:13)
at Scheduler._drain (/usr/lib/node_modules/node-red/node_modules/when/lib/Scheduler.js:62:19)
at Scheduler.drain (/usr/lib/node_modules/node-red/node_modules/when/lib/Scheduler.js:27:9)
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)
We have an open pull-request from @dceejay to refine how we report running on a read-only filesystem without the readOnly flag having been set. It's a scenario we hadn't tested for a while, so wasn't been handled as gracefully as it was previously.
Are you sure it is not to do with it being a later version of node-red?
Presumably the file system was not read-only when you installed the dashboard, or when you deploy flows. It is only a guess but I think it may only do that backup when things have changed so you could try making the file system readable and start node-red a couple of times. It may well be that if you make it ro again then successive restarts will then be ok.
Otherwise one of the gurus will no doubt respond.
You'll have to give us a bit more information to help us understand what you are doing.
In your original post, you say you have it setup in read-only mode. You then say you installed the dashboard via the manage palette option. Was that with the file-system still in read-only mode? If so, that is a very odd thing because installing a node involves writing files.
You have not answered whether you have readOnly set in your settings file.
If you don't have readOnly mode set in the settings file then node-red will happily try to write files and, as I mentioned, it doesn't currently handle a failure as gracefully as it once did, and we have a PR working towards a fix on that.
So the right answer should be for you to ensure you have readOnly set in your settings file. But you mention if creates a new flow when you have that set. If that's the case, that is a bug that must be fixed. Are you using the Projects feature?
If you have readOnly set to true in your settings file, then Node-RED will not try writing any files, regardless of the state of the filesystem. That is why it appears to revert when you restart Node-RED.
I think we used to reject the Deploy in this scenario to make it explicit - but clearly something has unintentionally changed (probably back in 0.17 when Projects was introduced). I will look at fixing that - so deploy's are properly rejected when readOnly is set.
I never had an issue trying to write to a read only file system (without readOnly set). Always got an error and things kept working.
The issue for this thread is NodeRED does not start on a read-only file system after installing nodes on a read-write file system (readOnly not defined in settings.js).
Starting NodeRED once with the file system in read-write mode fixes the issue.
Yup - and that is one of the scenarios the PR will handle. But the question is whether it is an error condition or not - should it be a warning or a fatal error (as it is today, just with a more meaningful message). Is it an error to be running Node-RED on a read-only filesystem without having set the readOnly flag in the settings file?
I would rather stop NR running on a R/O filesystem if readOnly is not set, then have a user complain all their work was lost because they thought they were running on a r/w filesystem.
For my application having to change the readOnly flag for every deploy would make things cumbersome.
Here is a typical scenario:
I create a flow
try to deploy
get a message that the deploy failed because the file system is read only
set the file system to read write
deploy
set file system to read only
NodeRED has never crashed on me so I am happy to work like this.
I might feel differently if I lost my work x% of the time because I forget to set the file system to read write before clicking deploy.
Then again I should "know what I am doing" and would eventually learn.
In every case, I am not a fan of stopping NR if readOnly is not set and file system is RO.
2 cents...
In your situation I would write a couple of simple scripts, one to set ro in settings and to make the file system ro, and another to reverse it. Then it is not cumbersome.
May I ask why are you running ro during development?
We already have a script for the file system. I guess you are right - we can extend it to modify settings.js. Sounds like that is what NR would prefer.
Raspberry Pi is in read only to protect the SD card.
Power can "accidentally" get pulled - especially on the test bench.
That is interesting, it had not occurred to me that one could do that. I feel some googling on how to do it coming on. It would only be appropriate on systems that don't need to write anything but I do have some that it might be useful for. One couldn't have mosquitto for example, at least not with retained properties.
