Help Needed: Forcing a Volatile OverlayFS to Protect SD Card from Writes

Volumio Community Forums
1

Hello everyone,

I’m running Volumio 3.785-2024-12-16 on a Raspberry Pi4 and I’m trying to protect my SD card from permanent writes (to avoid corruption from abrupt power loss) by using OverlayFS to make all file system modifications volatile (i.e., stored in RAM and lost upon reboot).

What I’ve Tried So Far:

  1. Modifying /etc/fstab:
  • I added these lines to mount two directories in RAM using tmpfs:
tmpfs   /overlay/upper_ram   tmpfs   defaults,size=102400k,noatime   0 0
tmpfs   /overlay/work_ram    tmpfs   defaults,size=10240k,noatime    0 0
  • Then, I set up the overlay for the root file system by adding:
overlay  /  overlay  lowerdir=/mnt/static,upperdir=/overlay/upper_ram,workdir=/overlay/work_ram  0 0
  • After saving these changes, I updated the initramfs with sudo update-initramfs -u and rebooted.
  1. Testing the Configuration:
  • I created a test file using:
sudo touch /newtestfile
ls -l /

The file appeared as expected.

  • However, after rebooting, I found that /newtestfile was still present, which indicates that the overlay modifications are being preserved persistently.
  1. Observations:
  • Running mount | grep overlay shows:
overlay on / type overlay (rw,relatime,lowerdir=/mnt/static,upperdir=/mnt/ext/dyn,workdir=/mnt/ext/work)
tmpfs on /overlay/upper_ram type tmpfs (rw,noatime,size=102400k)
tmpfs on /overlay/work_ram type tmpfs (rw,noatime,size=10240k)
  • This output indicates that the overlay is still using /mnt/ext/dyn and /mnt/ext/work for the upper layer and work directory, instead of the desired /overlay/upper_ram and /overlay/work_ram.
  1. Additional Checks:
  • I ran searches for /mnt/ext/dyn in common startup directories (e.g., /etc/init.d/, /lib/systemd/system/, /volumio/scripts/), but no references were found.
  • I also checked /boot/cmdline.txt and did not find any options forcing the overlay configuration to use /mnt/ext/dyn.

My Question:

It appears that Volumio is overriding my /etc/fstab settings and forcing the overlay to mount with persistent directories (/mnt/ext/dyn and /mnt/ext/work). Has anyone encountered this issue?

  • Is there a hidden configuration (perhaps in the initramfs or in a Volumio-specific startup script) that forces this behavior?
  • How can I disable this default behavior and force the system to use my tmpfs directories so that all changes are volatile and the SD card is protected?

Any guidance or workaround would be greatly appreciated!

Thanks in advance!

2

Hi,
yes, overlayfs is created in initramfs and no, it cannot be customized for individual use. This is intended behavior and identical for all implemented platforms (PI, x86, community portings and incl. platforms from various volumio products).

3

Hey @oxyjo,

Understanding OverlayFS, SquashFS, and /etc/fstab in VolumioOS

VolumioOS uses OverlayFS and SquashFS to create a read-only root filesystem while allowing temporary modifications. This setup helps protect the SD card by minimizing writes.

1. Role of SquashFS (Read-Only Base Filesystem)

Volumio’s root filesystem is stored in a SquashFS image (/volumio_current.sqsh), which:

  • Is highly compressed for efficiency.
  • Is read-only to prevent corruption and unintended modifications.
  • Reduces SD card wear by avoiding direct writes.

Because SquashFS is immutable, any system modifications must be stored in an overlay.

2. Role of OverlayFS (Writable Layer)

OverlayFS is a union filesystem that allows changes to the read-only SquashFS. It consists of:

  • A lower read-only layer (SquashFS).
  • An upper writable layer, which can be:
    • Persistent storage (e.g., an ext4 partition on the SD card).
    • Volatile storage (tmpfs in RAM), where changes are discarded on reboot.

When a file is modified:

  • It is copied from SquashFS to the writable layer.
  • The system reads from the overlay instead of SquashFS.
  • If tmpfs is used, all changes are lost upon reboot.

3. Impact on /etc/fstab

Unlike traditional Linux systems, VolumioOS does not mount its root filesystem directly from /etc/fstab:

  • The root filesystem (/) is set up before /etc/fstab is read, using OverlayFS.
  • Modifications to /etc/fstab may be lost if the writable layer is not persistent.
  • USB drives, network shares, and additional mounts work as usual, but only if /etc/fstab is stored persistently.

If you make changes to /etc/fstab and they disappear after a reboot, it’s likely because the writable layer is volatile.

4. Overwriting on OTA (Over-the-Air) Upgrades

During an OTA update, VolumioOS:

  1. Downloads a new SquashFS image (/volumio_new.sqsh).
  2. Replaces the current image (/volumio_current.sqsh).
  3. Resets OverlayFS, discarding all non-persistent changes.
  4. Preserves /data/, which is the only persistent user-writable directory.

This means:

  • Any changes stored in OverlayFS (including /etc/fstab) are lost after an update.
  • System-level modifications need to be reapplied after each update unless they are stored in /data/ or an external script.

5. Theoretical - forcing a volatile OverlayFS (Protecting the SD Card)

To ensure all changes are not lost on reboot, theoretically you can (not planned to be implemented):

  1. Mount the writable layer as tmpfs instead of using the SD card.
  2. Modify init scripts to enforce a read-only root filesystem.
  3. Use a custom script to restore required settings after a reboot. Perhaps state handling plugin will be a good candidate.

Kind Regards,

4

Thank a lot for your info
Kind regards