Read-only root filesystem: why and how
A device that logs, caches and writes settings to its system partition will eventually be interrupted mid-write. A read-only root filesystem removes most of that risk.
Why do it
- Power-loss resilience. If nothing is being written to the system partition, a sudden power cut cannot corrupt it.
- Less flash wear. SD cards and eMMC have limited write endurance. Fewer writes means a longer life.
- Predictability. Every boot starts from the same known-good system.
- Integrity. A read-only image can be verified (for example with dm-verity) to detect tampering.
The usual pattern
- Build the system into a read-only image, often SquashFS or a normal filesystem mounted read-only.
- Give volatile data a home in RAM with tmpfs (
/tmp,/run, often logs). - Keep a small, separate writable partition for what must persist: settings, keys, application data.
- Optionally layer an OverlayFS so software sees a writable system while changes go to RAM or the data partition and the base stays untouched.
What breaks (check these)
- Logs. Send them to RAM or a remote collector; decide how much history to keep.
- DHCP leases, state files and caches under
/var— redirect to tmpfs or the data partition. - Time. Without a battery-backed RTC, the clock resets on every boot; use NTP.
- SSH host keys and other generated secrets — create them once on the data partition, not at every boot.
- Installing packages at runtime. With a read-only base you update by replacing the image (see OTA and A/B updates), not by installing on the device.
Test it properly
Pull the power repeatedly during activity — while writing settings, while booting — and confirm the device always comes back. If it needs fsck or a manual fix, your writable partition still needs work.
OpenWrt is built around this idea (a read-only base with a writable overlay); with Buildroot you choose and build it yourself.