systemd-volatile-root.service turns your root filesystem into a tmpfs for exactly one boot, with nothing to undo afterwards. Full volatile mode drops you onto a tmpfs root while the real, non-volatile /usr/ stays mounted inside it read-only. Anything you write under /etc/, /var/ or elsewhere directly below the root disappears the moment the machine shuts down.
Allow about twenty minutes including one reboot. The examples use the installed Ubuntu package systemd 255.4-1ubuntu8.17; they do not change the boot loader permanently.
Warning: This mode is deliberately disruptive. Do not use it on a machine that must retain logs, package changes, generated state or configuration written during the test. Save anything you need before rebooting.
Run the read-only checks first; none of them need elevated privileges on a normally configured host:
$ systemctl --version
systemd 255 (255.4-1ubuntu8.17)
$ systemctl cat systemd-volatile-root.service
$ systemctl is-enabled systemd-volatile-root.service
static
The exact version and unit text vary by distribution. Here the unit is static, has no ordinary enablement symlink, and runs in the initrd before the host root is handed over. Its service command is an internal invocation of /usr/lib/systemd/systemd-volatile-root; do not run that helper by guessing arguments. The switch you actually use is the kernel command-line setting below.
Checkpoint: If systemctl cat reports that the unit is missing, stop. Installations without the matching systemd package cannot use this guide as written.
The service is selected from the kernel command line, not by running systemctl enable. For one test boot, edit the existing boot entry in your boot loader and append:
systemd.volatile=yes
With GRUB, that usually means highlighting the normal entry, pressing e, finding the line that starts with linux, adding the setting at the end, then booting with Ctrl+x or F10. The edit is temporary. Firmware menus and other boot loaders use different keys, so follow what the machine shows you rather than editing a persistent configuration file for a one-off test.
systemd.volatile=yes selects full volatile mode specifically. Do not substitute systemd.volatile=state if your goal is a volatile root: the manpage is explicit that state mode keeps the root directory non-volatile, so this service is not the one behind it.
Safety warning: Remove the setting or select the normal boot entry if you change your mind before starting the boot. Once the volatile system is running, writes made there are expected to disappear at shutdown.
Once the system starts, confirm the setting actually reached the running kernel:
$ tr '\0' ' ' < /proc/cmdline; printf '\n'
... systemd.volatile=yes ...
The surrounding arguments are machine-specific; what matters is the presence of systemd.volatile=yes, not an exact line match.
Then inspect the root mount itself. This is read-only and needs no sudo:
$ findmnt -no SOURCE,FSTYPE,OPTIONS /
tmpfs tmpfs rw,...
$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /usr
/usr ... ro,...
Output formatting and the tmpfs source label can differ between systems. You are checking two properties only: the root file system is tmpfs, and /usr is mounted read-only. If either is absent, do not treat the boot as a successful full-volatile test.
Ask systemd for the unit state and the current boot's journal:
$ systemctl status systemd-volatile-root.service --no-pager
$ journalctl -b -u systemd-volatile-root.service --no-pager
The service runs in the initrd, so a host-side status display may look completed, inactive or otherwise abbreviated depending on how the initrd journal is exposed. The mount checks above are the decisive verification; a missing status line here is not proof that the mode was skipped.
Do not run systemctl enable systemd-volatile-root.service. The unit is meant to be selected by the volatile-mode boot parameter, and enabling a static initrd unit is not the supported workflow.
Create a marker only if you are comfortable losing it, then check it during the same boot:
$ printf 'volatile test marker\n' | sudo tee /etc/volatile-root-test >/dev/null
$ sudo cat /etc/volatile-root-test
volatile test marker
This step needs elevated privileges, because writing under /etc changes the running system even though the change is temporary. Do not store a password, key or other secret in the marker. Reboot back into the normal entry and the file should be gone, since the normal root is in use again:
$ test ! -e /etc/volatile-root-test && echo 'marker absent on persistent boot'
marker absent on persistent boot
If that command prints nothing, you are either still in volatile mode, the marker was never created, or the normal root already had a file with that name. Use a more distinctive path if you repeat the test.
Reboot normally, then confirm the kernel command line no longer carries the temporary setting:
$ sudo systemctl reboot
$ tr '\0' '\n' < /proc/cmdline | grep '^systemd\.volatile=' || echo 'no volatile setting'
no volatile setting
$ findmnt -no FSTYPE /
ext4
ext4 is only an example; your persistent root may use a different file system. What matters is a non-tmpfs root matching your ordinary installation, plus the absence of the one-boot kernel argument. If the machine keeps returning to volatile mode, check the boot loader's persistent configuration and remove systemd.volatile=yes from the default command line.
If the volatile boot fails outright, use the boot loader's normal entry or edit the parameter out at the next boot. If the machine is remote and unreachable, fall back to its console or recovery procedure. Do not assume files written during a failed volatile boot survived.
systemctl cat and systemctl --version before touching the boot loader.systemd.volatile=yes argument, not systemd.volatile=state./ a tmpfs, /usr read-only./etc and /var as disposable for the length of the test.