` columns cannot be `none` on type-`l` records, even though symlinks have no real ownership. The script silently skips such entries with `Undefined users:` in the build log. Use `root root 0755`.
The recipe is minimal:
`meta-rwdata/recipes-extras/rwdata-volatile-binds/rwdata-volatile-binds_1.0.bb`:
```auto
SUMMARY = "Volatile (tmpfs-backed) mount points"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://99_rwdata"
S = "${WORKDIR}"
do_install() {
install -d ${D}${sysconfdir}/default/volatiles
install -m 0644 ${S}/99_rwdata ${D}${sysconfdir}/default/volatiles/99_rwdata
}
FILES:${PN} = "${sysconfdir}/default/volatiles/99_rwdata"
RDEPENDS:${PN} += "initscripts"
```
`RDEPENDS:${PN} += "initscripts"` is what guarantees `populate-volatile.sh` is on the image; without it, the fragment file would be installed but nothing would consume it.
Pull the recipe into the image:
```auto
IMAGE_INSTALL += "rwdata-volatile-binds"
```
### Verification
Regardless of which path you took, after booting you should see:
```auto
$ ls -l /var/lib/rwdata-cache
lrwxrwxrwx ... /var/lib/rwdata-cache -> /var/volatile/rwdata-cache
$ mount | grep '/var/volatile'
tmpfs on /var/volatile type tmpfs (rw,relatime)
$ echo hello > /var/lib/rwdata-cache/runtime-only && cat /var/lib/rwdata-cache/runtime-only
hello
```
(Under the systemd path, the first line will show a regular directory and a bind mount rather than a symlink; the third line behaves identically.) After a reboot the file is gone, which is the entire point.
## Step 6: build and verify
Lets pull it together. Build:
```auto
bitbake core-image-rwdata
```
And lets boot it under qemu. We point `runqemu` at the qemuboot.conf directly rather than at the image name: on some hosts the shortcut form’s internal `bitbake -e` lookup misses `IMAGE_LINK_NAME` and aborts, so the explicit form is more reliable:
```auto
runqemu build/tmp/deploy/images/qemuarm64/core-image-rwdata-qemuarm64.rootfs.qemuboot.conf nographic slirp
```
Log in as `root` (no password; `EXTRA_IMAGE_FEATURES = "debug-tweaks"` is set in `local.conf`). Exit qemu with `Ctrl-A x`.
Lets do some checks:
```auto
$ cat /proc/cmdline
root=/dev/vda1 ro mem=256M ip=dhcp console=ttyAMA0 console=hvc0 swiotlb=0
$ mount | grep ' on / '
/dev/root on / type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)
$ mount | grep ' on /persistent '
/dev/vda2 on /persistent type ext4 (ro,relatime)
$ touch /should-fail 2>&1; echo exit=$?
touch: /should-fail: Read-only file system
exit=1
$ touch /persistent/should-also-fail 2>&1; echo exit=$?
touch: /persistent/should-also-fail: Read-only file system
exit=1
$ ls -l /etc/hostname
lrwxrwxrwx 1 root root 24 Apr 5 2011 /etc/hostname -> /persistent/etc/hostname
$ cat /etc/hostname
qemuarm64
$ ls -l /persistent/.rwdata-initialized
-rw-r--r-- 1 root root 0 May 7 07:28 /persistent/.rwdata-initialized
$ ls -l /var/lib/rwdata-cache
lrwxrwxrwx 1 root root 26 May 7 07:29 /var/lib/rwdata-cache -> /var/volatile/rwdata-cache
$ mount | grep '/var/volatile'
tmpfs on /var/volatile type tmpfs (rw,relatime)
$ echo hello > /var/lib/rwdata-cache/runtime-only && cat /var/lib/rwdata-cache/runtime-only
hello
```
And here we go: `/` is erofs and read-only, `/persistent` is ext4 and read-only, and writes to either fail. `/etc/hostname` is a symlink onto `/persistent` and resolves successfully because the first-boot seeder ran. `/var/lib/rwdata-cache` is a symlink baked into the read-only rootfs that points at a tmpfs directory recreated on every boot.
## So what about runtime writes?
The first-boot seeder in Step 4 quietly ships an important pattern: `mount -o remount,rw /persistent`, do the writes, `mount -o remount,ro /persistent`. Two lines, one for each direction. And nothing stops us from doing the same thing at runtime, every time the application genuinely needs to write.
In a tightly controlled embedded system, you usually know when persistent state actually changes: a user pushes a config update, a calibration routine finishes, a log rotation rolls over. The total time per day that the system genuinely writes to `/persistent`, summed up, is often a handful of seconds. So why was `/persistent` mounted rw for the other 86,400?
The pattern is: `/persistent` boots read-only. The first write request triggers `mount -o remount,rw /persistent` and arms a short grace-period timer (ten seconds is a reasonable starting point). Every subsequent write inside the grace window re-arms the timer, coalescing bursts. When the timer elapses, `mount -o remount,ro /persistent` fires and we are back to read-only steady state.
Most of the day, you are protected by exactly the property this article built. A power loss during the small rw window is still bad; a power loss during the 99.99% of the day that is not the rw window is fine. That ratio is the entire point. As a bonus, once writes carry an explicit cost (a remount, a timer arm, a privileged operation), developers stop writing things speculatively. Logs no one reads, state files updated every second: they all become visible and easy to push back on.
Two architectural notes for the follow-up article. First, the application and the code that owns the remount belong in **separate processes** : the remount needs `CAP_SYS_ADMIN` and should live in a small auditable watchdog daemon. Inlining `mount -o remount` into the application is the kind of decision you regret the day a misbehaving process leaves `/persistent` rw forever. Second, the watchdog has to remount back to ro on `SIGTERM`, `SIGINT`, and on its own crash recovery path, or the design fails closed in the wrong direction.
A working implementation with the writer, watchdog, signal handling and timer logic is the subject of the follow-up article, built on top of the same image we just constructed.
## Conclusion
Thats it, were done! We have a poky image where the rootfs is structurally read-only, persistent factory configuration lives on a labelled ext4 `/persistent` partition reached via `/etc` symlinks, and runtime-writable scratch space comes from a tmpfs bind set up at rootfs build time.
Three patterns generalise far beyond this small example:
- Anything in `/etc` that needs to be per-device persistent gets a symlink onto `/persistent` plus a factory copy seeded on first boot.
- Anything that needs to be writable at runtime but does not need to persist across reboots goes onto tmpfs, via `volatile-binds` under systemd or a `/etc/default/volatiles/` fragment under sysvinit.
- The two non-obvious runqemu knobs (`QB_FSINFO = "wic:no-kernel-in-fs"` and an explicit `ro` in `QB_KERNEL_ROOT`) are the difference between “boots read-only as designed” and “boots read-write while you stare at the recipe wondering why”.
The cool-down timer pattern from the previous section is the logical next step on top of this image, and a complete implementation is the subject of a follow-up article. The `meta-rwdata` layer in this build directory contains the full unedited recipes for anyone who wants to clone and reproduce.
## More resources:
- Esa Jääskelä’s [Yocto Hardening: Read-Only Rootfs](https://ejaaskel.dev/yocto-hardening-read-only-rootfs/) covers the same area from a security-hardening angle and is well worth reading alongside this article.
- The [Yocto Project Reference Manual](https://docs.yoctoproject.org/ref-manual/index.html) section on `IMAGE_FEATURES`.
- The [wic plugin source](https://git.yoctoproject.org/poky/tree/scripts/lib/wic/plugins/imager/direct.py) for partition-table edge cases.
- `poky/meta/classes-recipe/rootfs-postcommands.bbclass` for what `read-only-rootfs` actually does at build time.
---
### Author:  [@lukehatpadl](https://hub.mender.io/u/lukehatpadl)
#### Post date: [May 15, 2026, 11:05pm UTC](https://hub.mender.io/t/read-only-filesystems-with-yocto/8266/2 "2026-05-15T23:05:22Z")
Very cool ideas here! Another alternative to symlinks is bind mounts, caveat being the source file needs to exist in the image.
Also in a brief test here, switching to erofs actually increased the OTA update size vs ext4 gzipped. But sounds like it may be worthwhile regardless.
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [May 21, 2026, 2:12pm UTC](https://hub.mender.io/t/read-only-filesystems-with-yocto/8266/3 "2026-05-21T14:12:25Z")
Hi @lukehatpadl,
Yes indeed, it always depends on which requirements a project has. Designing storage is one of those cases where a couple of “best practises” are known, but no silver bullet has been found yet.
On bind mounts, what do you mean? Binding a mutable directory into the RO filesystem is a common technique too for sure. A classic “trick” in that regard is to populate the binding target directory with sensible default data, and upon first boot, copy that into the directory to bind, and only enable the binding then. `systems` offers a bunch of really neat tricks to have conditional operations for such.
Greetz,
Josef
---
### Author:  [@lukehatpadl](https://hub.mender.io/u/lukehatpadl)
#### Post date: [May 21, 2026, 9:18pm UTC](https://hub.mender.io/t/read-only-filesystems-with-yocto/8266/4 "2026-05-21T21:18:40Z")
Also, you can use bind mounts at the file level instead of symbolic links (trade offs either way). That’s what we’re using for `/etc/hostname` and `/etc/machine-info`:
```auto
# mount|grep /etc
tmpfs on /etc/machine-id type tmpfs (ro,size=1600312k,nr_inodes=819200,mode=755)
/dev/mmcblk0p4 on /etc/hostname type ext4 (rw,relatime,x-systemd.requires=/data)
/dev/mmcblk0p4 on /etc/machine-info type ext4 (rw,relatime,x-systemd.requires=/data)
```