Octopi read-only using raspi-config

Get Help
1

On an older version of OctoPrint, I set up the host Raspberry Pi's Raspbian OS as read-only. This meant that the operating system tmp and other files would not be written to the SD Card, greatly reducing wear on the card as well as preventing OS corruption and boot failures due to improper shutdowns such power failures. The rest of the card was still read-write so that files could be uploaded to OctoPrint and remain available after reboots. This setup was fairly involved to create, but worked great for years.

I see that newer versions of Raspbian, including the one under the latest Octopi, have a read-only setup in raspi-config in the advanced options. It makes switching between a read-only and read-write OS into a one or two click process. Impressive!

In playing around with it, I have found that it works with the Octopi/OctoPrint setup in that in read-only mode, you can still upload files to OctoPrint, see them in the file list, and print them as expected. However, when you reboot the RPi, the files are gone. That's because in read-only mode, they were written into a ramdisk and not persisted on the SD Card.

I almost never to reprint old uploads from the OctoPrint file list. So maybe this is a fine configuration to lose them on reboot. However, does anyone know how to configure the read-only mode to set up a writable partition for OctoPrint to use?

2

In Linux terms, there are several modes related to things scheduled. So initd, for example, might see different numbers-as-modes.

# /etc/init.d/sample.py
### BEGIN INIT INFO
# Provides:          sample.py
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

As you can see from an example, these numbers appear as triggers for when this example runs. Presumably then, modes zero, one & six are related to stopping the operating system. From this, one could write an init.d-stored script which does things at shutdown. The thought would be that files in some folder in the RAM drive would be persisted to the file system, proper. In theory, before persisting these files it would first be necessary to toggle the status:

sudo mount -o remount,rw /