ptx2 / gymnasticon

Make obsolete and/or proprietary exercise bikes work with popular cycling training apps like Zwift, TrainerRoad, Rouvy and more.

Home Page:https://ptx2.net/posts/unbricking-a-bike-with-a-raspberry-pi

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Raspberry Pi in read-only mode

chriselsen opened this issue · comments

Given that the average user will install Gymnasticon on a Raspberry Pi once, configure it, power it up and then leave it running, I'm wondering if it makes sense to place the SD-card into read-only mode.

Benefits would be:

  • The SD-card isn't worn out by writes
  • Reduce the risk of corrupted file systems during sudden power disconnects

Besides log files there isn't really anything written to the device that is of interest and even log files are only useful for troubleshooting, mostly during development.

Which mode would make the most sense?

  • Raspberry Pi image is by default enabled for read-only. Mode can be disabled by placing "no-readonly" file into boot partition of SD-card.
  • Raspberry Pi image is by default in read-write mode (like today). Read-only mode can be enabled by placing "readonly" file into boot partition of SD-card.
  • Raspberry Pi image is by default enabled for read-only. Mode cannot be disabled, by command-line shortcuts to remount filesystem into read-write exist.

I'm in favor of read-only and making the standard SD install method an "appliance" for durability reasons. Option 1 to me makes the most sense.

makes sense. Now that the Keiser bike is gonna be supported shortly, I expect a large# of people getting interested as the alternative is a bluetooth connector from Keiser which they sell for 130 and is notoriously unstable. Likely, a lot of them won't know much about raspberry pi's ;-)

In this case, auto-detection of the bike may be required though rather than using a config file?

commented

I agree this would be a nice feature!

There is already an option in raspi-config to use OverlayFS. Turning it on/off requires a reboot but the average user hopefully would not have a need to do that.

@tompijls Good point about the config files. Maybe all we need to do is modify the startup files to cp the config files from /boot instead of mv.

We already don't have swap enabled so that's taken care of.

Anything else to consider?

@ptx2 Yes, using cp instead of move on the config file would be a good start. I'll also open another issue for extending the auto bike mode to the two new bike types. That should reduce the need for a config file quite a bit.

We might also want to disable the syslog service ( sudo systemctl disable syslog.service) as it could otherwise eat up all the RAM via the overlayfs. You can still use journalctl to look at logs during runtime.

Also with the overlayfs support built into raspi-config, you can't activate/deactivate it via CLI, which stands in the way of making this user friendly.
But the script that raspi-config uses under the hood can also be found here. That script (or an adaptation thereof) could be used here for gymnasticon. The only element that I see in the script which requires Internet access is the installation of initramfs-tools, which can be taken care of via pi-gen.

Depending of whether we want to make the use of overlayfs the default or not, this could either become part of the pi-gen process or be invoked as a first-boot service after checking for the readonly / no-readonly file in /boot.

Also this approach comes with the script overctl that can be used to enable / disable overlayfs afterwards.

Imho, we should make the read-only mode the default mode. That would mean incorporating overlayfs.sh into the pi-gen process.

Turns out that you can actually can call raspi-config functions via CLI. See here.
Looks like all that's needed is to save that bash script in /usr/local/sbin and then call it via overctl -r. It should be possible to do all that from the current pi-gen process.

Create pull request #58 for this.