Read Only SD Card

[asprunt]

Though not flawless (the boot logs are not error free and the hardware clock doesn’t quite work), I think I’ve successfully implemented OpenSprinklerPi on a read-only SD card. The motivation is that I feel that I’ve had more than my fair share of SD card failures.

The main “weird” thing is that I’m using Arch instead of Debian. I started off with Debian Jessie, but it seems to occupy a no-man’s land between System V and Systemd, and consequently suffers from a couple of bugs (1 & 2) that made lots of trouble for me. I eventually had something that worked, but the boot sequence felt fragile. For the curious, I worked from these instructions (which I think must have been for wheezy). I did not see this until I’d already switched to Arch.

While trying to work through the Debian issues, I found myself reading a lot about systemd and much of what I was reading was Arch documentation, which seemed like it might be a hint.

Arch setup was pretty smooth:
1. Download and install the image
2. Perform initial setup following the Beginner’s Guide and this page
3. Setup the watchdog
4. Setup the RTC with a combination of this and this, but you can probably skip this because though the clock is accessible something is preventing the timekeeping system from properly taking advantage of it.
5. Setup the Pi to mount your NAS as writeable storage (optional, mine was at /mnt/nas/ospi).
6. Clone the OpenSprinkler unified firmware git repository, build for ospi, but decline to have the software start at boot.

To start the OpenSprinkler software at boot, I wrote a little systemd service file (/etc/systemd/system/OpenSprinkler.service)

[Unit]
Description=Open Sprinkler (Unified) Raspberry Pi
After=remote-fs.target
RequiresMountsFor=/mnt/nas/ospi

[Service]
ExecStart=/home/alarm/OpenSprinklerGen2/OpenSprinkler
Type=simple

[Install]
WantedBy=multi-user.target

Specifying “remote-fs.target” and “RequiresMountsFor” is probably redundant, but it doesn’t seem to hurt anything. If you use something other than a NAS, those conditions will not be necessary. With the service file written:

1. Tell systemd the service file exists: systemctl daemon-reload
2. Test the service by starting it manually from the command line: systemctl start OpenSprinkler.service
3. If it started from the command line (check by browsing to the web interface and with systemctl status OpenSprinkler.service), enable the service on startup with systemctl enable OpenSprinkler.service

Many links are available for writing these systemd service files. I liked this one. My experience has been that systemd is much less fussy than the bash scripts associated with System V.

Proper functioning (logging watering, modifying station names, tweaking programs, etc.) of the OpenSprinkler firmware requires writing data somewhere. I’m using a NAS (hence my sensitivity to one of the Debian bugs), but I expect you could also use a USB thumb drive or equivalent.

Since I cloned the firmware repository onto the SD card, I created symbolic links from select files and the logs directory in the repository directory to a folder on my NAS (that’s mounted by the Pi at boot):

cp /home/alarm/OpenSprinklerGen2/logs /mnt/nas/ospi/logs
cp /home/alarm/OpenSprinklerGen2/nvm.dat /mnt/nas/ospi/nvm.dat
cp /home/alarm/OpenSprinklerGen2/stns.dat /mnt/nas/ospi/stns.dat
ln -s /mnt/nas/ospi/logs /home/alarm/OpenSprinklerGen2/logs
ln -s /mnt/nas/ospi/nvm.dat /home/alarm/OpenSprinklerGen2/nvm.dat
ln -s /mnt/nas/ospi/stns.dat /home/alarm/OpenSprinklerGen2/stns.dat

Note that your paths will vary depending on where you clone the repository and where you mount the read-write storage and that symbolic links require absolute paths (I think). I may have been able to get by with linking just “logs” and “nvm.dat” but throwing in stns.dat doesn’t seem to hurt. I suppose I also could have cloned the repository itself onto the NAS…

At this point, I’d suggest exercising the OpenSprinkler software a bit (name zones, create programs, do manual runs) to make sure that everything is working. The date stamps for the targets of the symbolic links should advance as these files are written to for various events.

I never got into really big trouble during the Arch setup, but based on my experience trying this with Debian, you can find yourself in a bad place (networking not initializing properly, SSH service not starting) quickly when transitioning to read-only mode, so I’d recommend having the Pi plugged into a monitor and external keyboard.

With that done, I just followed the instructions here to move to a read-only SD card. Note the commands for remounting in read-write mode for system updates, tweaks, etc.

Thus far, everything (aside from some boot log complaints and the RTC issue) works. I’ve written these instructions from my notes – hopefully I’ve not omitted anything important.

[Author]

Posts