You can add two scenarios to your script, as described: Qubes OS live mode. dom0 in RAM (zram0, overlay in tmpfs). Protection against forensics. Tails mode
The second scenario (overlay in tmpfs), used by native kicksecure/Whonix, is more secure:
Root filesystem is effectively read‑only
The system runs on an overlay: the original root is mounted as lowerdir=/live/image (read‑only view), and all changes go into upperdir=/cow/rw on tmpfs. This makes it hard for malware to persist on the real disk, since any modifications live only in the volatile upper layer.
Overlay in tmpfs does not create and format new block devices nor copy the entire root filesystem at runtime. There are fewer points where an attacker could hook into disk‑level operations or tamper with filesystem creation and bulk copying.
A separate mkfs and bulk copying with cp ‑a is a much more vulnerable scenario than creating an overlay.
The only advantage of working with zram0 is memory savings.
Both scenarios need to use appVM in varlibqubes or new pool inside dom0. It’s sufficient to run only the appVM, templates don’t retain session metadata. It’s also preferable that new qubes be created in the varlibqubes pool and destroyed after shutdown. Otherwise this qubes will remain on disk but become inaccessible to dom0 after a reboot.