A Raspberry Pi with its system on an SD card has one weakness: a cold power-off (pulling the plug) can corrupt the file system mid-write. The device then fails to boot. The answer is to mount the root and the other file systems read-only and redirect writes into memory.
possibly outdated More than two years have passed since publication. The content may no longer hold.
Principle
At boot the system mounts the root read-only. Everything that needs to be written at runtime (/tmp, /var/log, runtime state) is redirected into tmpfs in memory, which is created empty at boot. After the plug is pulled there is nothing to corrupt – nothing on the card changes at runtime.
Procedure
- Read-only root in
/etc/fstab– theroflag on the root and the other partitions:
PARTUUID=xxxxxxxx-02 / ext4 ro,noatime 0 1
- Writable directories to tmpfs:
tmpfs /tmp tmpfs nosuid,nodev 0 0 tmpfs /var/log tmpfs nosuid,nodev 0 0 tmpfs /var/tmp tmpfs nosuid,nodev 0 0
- Disable swap and write-heavy services that would fail on a read-only system or try to write to the card (swap, state saving, periodic log flushes to disk).
- Handle the parts that expect to write – redirect them to tmpfs with a symlink or a bind mount, so the system still boots and runs.
Master image and mass deployment
Once one unit works, it becomes the template:
- create an image (a bit-for-bit copy) from the working card;
- clone the image onto dozens of cards;
- on each unit fill in only what is specific to that location – typically the URL the device is meant to display.
Deployment on site is then trivial: insert the card, switch it on, deal with nothing else.
Things to watch out for
- Updating or changing the configuration requires temporarily switching the root to read-write (
mount -o remount,rw /) and back toroafterwards. - Anything that must survive a reboot has to live on the read-only part – tmpfs is wiped at every boot.