How to Configure Ephemeral Volatile Root Filesystems in Ubuntu Using systemd-volatile-root

In secure kiosks, automated continuous integration test runners, public laboratory workstations, and stateless appliance clusters, administrators must guarantee that every system boot starts from a pristine baseline state. If a workstation is compromised, misconfigured, or polluted with temporary artifacts during runtime, rebooting the host should discard all modifications instantly without manual disk re-imaging. In systemd-based Linux distributions like Ubuntu, this stateless behaviour is implemented natively via the systemd-volatile-root.service and systemd-volatile-root-generator subsystems. Rather than mounting the underlying block device as a read-write filesystem, systemd mounts an ephemeral tmpfs RAM overlay above the immutable base image. Understanding how to configure volatile boot directives allows infrastructure teams to build resilient, self-healing Ubuntu environments.

Understanding Volatile Boot Modes and Overlay Execution

The systemd volatile root mechanism provides standardized kernel command-line parameters to control filesystem persistence during early user-space initialization in the initramfs:

• systemd.volatile=yes (Full Volatile Mode): Mounts the root filesystem completely in memory using a tmpfs overlay. The physical disk image is mounted strictly read-only. All modifications to system binaries, configurations in /etc, runtime data in /var, and user homes in /home are stored exclusively in volatile RAM and vanish upon reboot.
• systemd.volatile=state (Volatile State Mode): Mounts only the state directory (/var) as an ephemeral tmpfs filesystem, while leaving the root filesystem mounted according to standard /etc/fstab directives. This mode is ideal for operating systems where the operating system image is read-only but shared across multiple virtual machines.
• systemd.volatile=overlay: Explicitly synthesizes an overlayfs mount combining the pristine read-only base root partition as the lower directory (lowerdir) and a volatile memory buffer as the upper directory (upperdir).
• Early Boot Generator Execution: During initramfs execution, systemd-volatile-root-generator evaluates the kernel command line. If a volatile directive is present, it alters the target unit graph, inserting systemd-volatile-root.service before initrd-root-fs.target.

Configuring Volatile Boot Parameters in GRUB

To configure an Ubuntu machine to boot into volatile mode, append the systemd.volatile directive to the Linux kernel boot line via the GRUB bootloader configuration.

Open /etc/default/grub in a text editor with administrative elevation:

sudo nano /etc/default/grub

Locate the GRUB_CMDLINE_LINUX_DEFAULT configuration line and append systemd.volatile=yes:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash systemd.volatile=yes"

For headless test servers or virtual machines where persistent disk changes must be prevented during automated test runs:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 systemd.volatile=yes"

Recompile the GRUB configuration to update the active boot loader entries:

sudo update-grub

Testing Volatile Boots Ephemerally via the GRUB Menu

Rather than permanently modifying /etc/default/grub, engineers can test volatile execution interactively during a single boot cycle:

1. Restart the Ubuntu machine.
2. At the GRUB selection menu, highlight the default Ubuntu kernel entry and press e to edit kernel parameters.
3. Navigate to the line beginning with linux and append systemd.volatile=yes to the end of the argument list.
4. Press Ctrl + X or F10 to boot the system with the volatile overlay active.

Verifying Ephemeral Mount State and Memory Backing

Once the operating system boots, confirm that the root filesystem is backed by an ephemeral memory layer rather than directly bound to persistent storage.

Inspect active mounts using findmnt:

findmnt /

On a successfully booted volatile system, findmnt reports overlay as the filesystem type (FSTYPE) for the root target (/), with options showing an ephemeral upper directory:

TARGET SOURCE  FSTYPE  OPTIONS
/      overlay overlay rw,relatime,lowerdir=/sysroot,upperdir=/sysroot-volatile/upper,workdir=/sysroot-volatile/work

Query the status of the systemd-volatile-root service unit:

systemctl status systemd-volatile-root.service

Check the available RAM allocation assigned to the volatile root tmpfs buffer:

df -h /

The reported capacity reflects available physical memory rather than physical partition size, ensuring that all disk writes reside safely in RAM.

Testing Persistence Erasure Across Reboots

To verify that disk writes are completely discarded upon reboot, conduct a file persistence validation test:

# Create a canary test file and simulate a configuration change
echo "Volatile test session: $(date)" | sudo tee /etc/canary-test.txt
sudo touch /root/ephemeral-marker

# Verify file presence
cat /etc/canary-test.txt
ls -l /root/ephemeral-marker

Reboot the workstation:

sudo reboot

After the system boots up, attempt to locate the canary file:

ls -l /etc/canary-test.txt /root/ephemeral-marker

The command returns No such file or directory, proving that all modifications made during the previous session were purged from memory without affecting the underlying disk image.

Troubleshooting Volatile Boot Limitations

When engineering stateless Ubuntu infrastructure, evaluate these operational limitations:

• RAM Exhaustion (OOM Hazards): Because all modified blocks, downloaded packages, and log files are stored in tmpfs, aggressive disk writes can consume system RAM. On memory-constrained nodes, configure a dedicated swap partition or monitor memory pressure with free -m.
• Persistent Logging Solutions: Because /var/log is volatile, system crashes and kernel panics leave no local diagnostic trails. Forward journal logs to a remote collector by configuring systemd-journal-remote or a centralized syslog daemon.
• Package and Security Updates: Operating system updates executed within a volatile session do not persist. To update volatile golden images, boot the machine once without systemd.volatile=yes (in maintenance mode), apply apt upgrade, and reboot back into volatile mode.

By leveraging systemd-volatile-root in Ubuntu, system administrators establish reliable, immutable operating system environments ideal for security kiosks, automated testing harnesses, and resilient stateless edge infrastructure.