Read-only rootfs: Theory and Practice
summary
Argues that a read-only rootfs plus separate nonvolatile user-data and tmpfs volatile areas reduces flash wear, avoids filesystem corruption and simplifies image updates and factory reset. Uses /proc/diskstats and block_dump to identify writers and shows concrete culprits: dropbear SSH keys, /dev/urandom seed, udev cache and MOTD all write on first boot. Demonstrates fixes on a Yocto/Poky image: add a data partition (/sl_data), symlink or bind-mount changing files into it, use tmpfs for /run and /tmp, or overlayfs; notes Yocto’s read-only image lacks nonvolatile placement so extra package work is required.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 0:52Readonly rootfs
- 2:10Why readonly
- 3:12Image updates
- 4:05Mount rootfs
- 4:38Memory areas
- 5:43Stateless
- 7:50Enlightenment
- 9:50Example
- 11:10Blockdump
- 12:11Journaling
- 13:13Verta
- 14:25Path names
- 15:09Problems on first boot
- 19:43Log files
- 20:59Random seed
- 22:12Dropout
- 22:59First boot
- 23:32Android
- 25:49Conclusion
- 26:39QA
- 30:22Advantages and Disadvantages
- 31:37symlinks
- 33:35mount
- 35:17systemd
- 37:37volatilepast
related talks
11mImmutable Linux systems and how they work
01h 05mImmutable and Stateless Systems with systemd
42mSecuring Filesystem Images for Unprivileged Containers
38mEROFS, an Introduction and our Smartphone Practice
01h 45mDebootstrapping Embedded Linux Root Filesystems - Building and Optimization for the...
57mEROFS: Past, Present, and Future
33mCreating Your Own Tiny Linux Distribution Using Yocto: Keeping it Small With
11mEROFS as a replacement for EXT4 and Squashfs