Qubes OS live mode. dom0 in RAM. Non-persistent Boot. Protection against forensics. Tails mode. Hardening dom0 revisions

Go back to topic: Qubes OS live mode. dom0 in RAM. Non-persistent Boot. Protection against forensics. Tails mode. Hardening dom0

  1. v33 anchor; v33 full version
  2. v32 anchor; v32 full version
  3. v31 anchor; v31 full version
  4. v30 anchor; v30 full version
  5. v29 anchor; v29 full version
  6. v28 anchor; v28 full version
  7. v27 anchor; v27 full version
  8. v26 anchor; v26 full version
  9. v25 anchor; v25 full version
  10. v24 anchor; v24 full version
  11. v23 anchor; v23 full version
  12. v22 anchor; v22 full version
  13. v21 anchor; v21 full version
  14. v20 anchor; v20 full version
  15. v19 anchor; v19 full version
  16. v18 anchor; v18 full version
  17. v17 anchor; v17 full version
  18. v16 anchor; v16 full version
  19. v15 anchor; v15 full version
  20. v14 anchor; v14 full version
  21. v13 anchor; v13 full version
  22. v12 anchor; v12 full version
  23. v11 anchor; v11 full version
  24. v10 anchor; v10 full version
  25. v9 anchor; v9 full version
  26. v8 anchor; v8 full version
  27. v7 anchor; v7 full version
  28. v6 anchor; v6 full version
  29. v5 anchor; v5 full version
  30. v4 anchor; v4 full version
  31. v3 anchor; v3 full version
  32. v2 anchor; v2 full version

Revision #33

Edited on
2026-02-09
Edited by user
linuxuser1
# qubes_dom0-root Qubes_Root=$(findmnt -n -o SOURCE /)
fi Qubes_Root=$(findmnt -n -o SOURCE /) fi

Revision #32

Edited on
2026-02-09
Edited by user
linuxuser1
fi fi Qubes_Root=$(findmnt -n -o SOURCE /)
mount -o ro /dev/mapper/qubes_dom0-root /mnt mount -o ro $Qubes_Root /mnt

Revision #31

Edited on
2026-02-09
Edited by user
linuxuser1
**+ Step 1. Make New Directorys for Dracut Automation Modules:** **Step 1. Make New Directorys for Dracut Automation Modules:**
**+ Step 2. Make Two Dracut Script Files module-setup.sh:** **Step 2. Make Two Dracut Script Files module-setup.sh:**
**+ Step 3. Make New Dracut Script File overlay-mount.sh:** **Step 3. Make New Dracut Script File overlay-mount.sh:**
** +Step 4. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.** **Step 4. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.**
cat > /etc/dracut.conf.d/ramboot.conf << EOF cat > /etc/dracut.conf.d/ramboot.conf << 'EOF'
> (Create `/usr/lib/dracut/modules.d/01ramboot/zram-mount.sh`, Update **Dracut**, Edit `40_custom` file, update **GRUB**)
**+ Step 5. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **Step 5. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**

Revision #30

Edited on
2026-02-09
Edited by user
linuxuser1
> :loudspeaker: Don’t worry about installing these modes - doing so won’t affect the default Qubes boot. The new GRUB options are added to `/etc/grub.d/40_custom` (so it don’t modify your `/etc/default/grub`), and the new dracut modules only run when the additional GRUB parameters are supplied (these parameters aren’t present in the default boot). You are not editing the default `/etc/default/grub`. Default Qubes boot won’t be affected even if the new modes encounter problems in the future, such as after dom0 updates. I created this scenario to be as safe as possible and isolated from the default Qubes boot. > :loudspeaker: Don’t worry about installing these modes - doing so won’t affect the default Qubes boot. I created this scenario to be as safe as possible and isolated from the default Qubes boot. The new GRUB options are added to `/etc/grub.d/40_custom` (so it don’t modify your `/etc/default/grub`), and the new dracut modules only run when the additional GRUB parameters are supplied (these parameters aren’t present in the default boot). Default Qubes boot won’t be affected even if the new modes encounter problems in the future, such as after dom0 updates.
`chmod 755 /usr/lib/dracut/modules.d/90ramboot/module-setup.sh`
`chmod 755 /usr/lib/dracut/modules.d/90overlayfs-root/module-setup.sh`
`chmod 755 /usr/lib/dracut/modules.d/90overlayfs-root/overlay-mount.sh`
Press `Ctrl + X` to exit nano editor. **+ Step 4. Make New Dracut Config File ramboot.conf:** `sudo touch /etc/dracut.conf.d/ramboot.conf` `sudo nano /etc/dracut.conf.d/ramboot.conf` add: ``` add_drivers+=" zram " add_dracutmodules+=" ramboot " ``` Press `Ctrl + O` to save file.
****+Step 5. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.** ** +Step 4. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.**
cat > /etc/dracut.conf.d/ramboot.conf << EOF add_drivers+=" zram " add_dracutmodules+=" ramboot " EOF
**+ Step 6. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **+ Step 5. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**

Revision #29

Edited on
2026-02-08
Edited by user
linuxuser1
:green_circle: If you’re worried about entering something incorrectly, use the fully automated live‑mode setup via a [simple script](https://forum.qubes-os.org/t/qubes-os-live-mode-dom0-in-ram-non-persistent-boot-protection-against-forensics-tails-mode-hardening-dom0/38868/2)

Revision #28

Edited on
2026-02-08
Edited by user
linuxuser1
mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,noatime,nodiratime tmpfs /cow mount -n -t tmpfs -o mode=0755,size=70%,nr_inodes=500k,noexec,nodev,nosuid,noatime,nodiratime tmpfs /cow
`sudo /usr/local/bin/grub-custom.sh` `sudo /usr/local/bin/grub-custom.sh` > If you want to add your custom GRUB parameters for live modes, do so in `/etc/grub.d/40_custom`

Revision #27

Edited on
2026-02-08
Edited by user
linuxuser1
> :loudspeaker: Don’t worry about installing these modes - doing so won’t affect the default Qubes boot. The new GRUB options are added to `/etc/grub.d/40_custom` (so it don’t modify your `/etc/default/grub`), and the new dracut modules only run when the additional GRUB parameters are supplied (these parameters aren’t present in the default boot). > :loudspeaker: Don’t worry about installing these modes - doing so won’t affect the default Qubes boot. The new GRUB options are added to `/etc/grub.d/40_custom` (so it don’t modify your `/etc/default/grub`), and the new dracut modules only run when the additional GRUB parameters are supplied (these parameters aren’t present in the default boot). You are not editing the default `/etc/default/grub`. Default Qubes boot won’t be affected even if the new modes encounter problems in the future, such as after dom0 updates. I created this scenario to be as safe as possible and isolated from the default Qubes boot.
**+ Step 1. Disable Dom0 Swap:** ``` sudo nano /etc/fstab ``` Using nano, type a **#** character in front of the line with word “**swap**” in the middle (**usually the last line**). Like this: `#UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx swap defaults,x-systemd.device-timeout=0 0 0` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. That will permanently disable your Dom0 Swap after restart, which is likely best for operating Qubes Dom0 in live mode. ``` sudo swapoff -a ``` **+ Step 2. Edit GRUB:** `sudo nano /etc/default/grub` Edit line `GRUB_TIMEOUT=5` to `GRUB_TIMEOUT=30` (change 5 seconds to 30 seconds). Within the `GRUB_CMDLINE_XEN_DEFAULT` line, make a partial modification of this line, from dom0_`mem=max:4096M` to now be `dom0_mem=max:10240M` → Just change the text “`4096M`” to “`10240M`” (without quotes). Press `Ctrl + O` to save grub file. Press `Ctrl + X` to exit nano editor. > :exclamation: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish. **+ Step 3. Make New Directorys for Dracut Automation Modules:** `sudo mkdir /usr/lib/dracut/modules.d/01ramboot` **+ Step 1. Make New Directorys for Dracut Automation Modules:** `sudo mkdir /usr/lib/dracut/modules.d/90ramboot`
**+ Step 4. Make Two Dracut Script Files module-setup.sh:** `sudo touch /usr/lib/dracut/modules.d/01ramboot/module-setup.sh` `sudo nano /usr/lib/dracut/modules.d/01ramboot/module-setup.sh` **+ Step 2. Make Two Dracut Script Files module-setup.sh:** `sudo touch /usr/lib/dracut/modules.d/90ramboot/module-setup.sh` `sudo nano /usr/lib/dracut/modules.d/90ramboot/module-setup.sh`
**+ Step 5. Make New Dracut Script File overlay-mount.sh:** **+ Step 3. Make New Dracut Script File overlay-mount.sh:**
**+ Step 6. Make New Dracut Config File ramboot.conf:** **+ Step 4. Make New Dracut Config File ramboot.conf:**
****+Step 7. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.** ****+Step 5. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.**
DOM0_MAX_MB=$(( DOM0_MAX_KB / 1024 )) DOM0_MAX_MB=$(( (DOM0_MAX_KB * 70) / (1024 * 100) ))
cat > /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh << EOF cat > /usr/lib/dracut/modules.d/90ramboot/zram-mount.sh << EOF
chmod 755 /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh chmod 755 /usr/lib/dracut/modules.d/90ramboot/zram-mount.sh
grub2-mkconfig -o /boot/grub2/grub.cfg grub2-mkconfig -o /boot/grub2/grub.cfg # Disable Dom0 Swap: sed -i '/[[:space:]]\+swap[[:space:]]\+/s/^/#/' "/etc/fstab" swapoff -a
**+ Step 8. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **+ Step 6. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**

Revision #26

Edited on
2026-01-31
Edited by user
linuxuser1
**If you have limited memory, use this guide:** https://forum.qubes-os.org/t/really-disposable-ram-based-qubes/21532**If you have limited memory, use this guide:** https://forum.qubes-os.org/t/really-disposable-ram-based-qubes/21532 :sunglasses: **Also use these guides to hide traces of VPN/Tor connections and for external system shutdown and memory clearing for maximum paranoid security:** [Installation of AmneziaVPN: effective circumvention of internet blocks via DPI](https://forum.qubes-os.org/t/installation-of-amneziavpn-effective-circumvention-of-internet-blocks-via-dpi-for-china-russia-belarus-turkmenistan-and-iran-vpn-with-xray-reality/39005) [USB Kill Switch for Qubes OS](https://forum.qubes-os.org/t/usb-kill-switch-for-qubes-os-physical-security-enhancement/35541)

Revision #25

Edited on
2026-01-31
Edited by user
linuxuser1
> You can make backups in live mode (I’ve done it many times using a tmpfs setup). > You can make backups in live mode (I’ve done it many times using a Overlay-Live Mode).

Revision #24

Edited on
2026-01-31
Edited by user
linuxuser1
mount -o nodev,nosuid,noatime,nodiratime,nobarrier,commit=60,data=writeback /dev/zram0 /sysroot mount -o nodev,nosuid,noatime,nodiratime /dev/zram0 /sysroot

Revision #23

Edited on
2026-01-31
Edited by user
linuxuser1
This guide combines the best practices from this topic https://forum.qubes-os.org/t/qubes-in-tmpfs/11127 and it adds new options and capabilities for launching Qubes in RAM. (The old topic’s founder and one of its main contributors are no longer active on forum)
![g|689x434](upload://nTmXgMRh1RnxQ9Ry3mekJVULijo.jpeg) This guide solves the old problem of [ implement live boot by porting grub-live to Qubes - amnesia / non-persistent boot / anti-forensics](https://github.com/QubesOS/qubes-issues/issues/4982). This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. It will extend the lifespan of your SSD. > :mega: **Overlay-Live Mode** (used by native kicksecure/Whonix) is more secure and fast: > 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. Overlay is much closer to a real Tails OS (a read‑only image). :shield: I added [some additional flags to Overlay-Live Mode to strengthen the security](https://forum.qubes-os.org/t/qubes-os-live-mode-dom0-in-ram-non-persistent-boot-protection-against-forensics-tails-mode-hardening-dom0/38868/3). It makes the dom0 more hardened. > :loudspeaker: **Zram‑Live Mode** works by copying (`cp -a`) root to zram0 - it is a significantly less secure and slower scenario. Also not recommended to update dracut and GRUB while in Zram‑Live Mode - doing so could cause the system to break after a reboot! :gear: But it saves RAM usage dramatically (~ 2x Overlay-Live Mode). This mode is suitable for running Standalone Live VMs that require a lot of disk space. ![g|689x434](upload://nTmXgMRh1RnxQ9Ry3mekJVULijo.jpeg) :shield: Both modes significantly increase dom0 security - the default root runs in read‑only mode, and operations take place within a hardened copy of the system. This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. It will extend the lifespan of your SSD. > Overlay‑Live Mode is very fast and maximally (paranoid) secure. Zram‑Live Mode starts slowly, uses more CPU power, but saves RAM dramatically (~ 2× compared to Overlay‑Live). This guide solves the old problem of [ implement live boot by porting grub-live to Qubes - amnesia / non-persistent boot / anti-forensics](https://github.com/QubesOS/qubes-issues/issues/4982).
**Make a backup before you start working!** > :loudspeaker: Don’t worry about installing these modes - doing so won’t affect the default Qubes boot. The new GRUB options are added to `/etc/grub.d/40_custom` (so it don’t modify your `/etc/default/grub`), and the new dracut modules only run when the additional GRUB parameters are supplied (these parameters aren’t present in the default boot). **But Make a backup before you start working :slightly_smiling_face:**
mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,relatime tmpfs /cow mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,noatime,nodiratime tmpfs /cow
mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions,relatime overlay $NEWROOT mount -t overlay -o noatime,nodiratime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions,relatime overlay $NEWROOT
mount /dev/mapper/qubes_dom0-root /mnt mount -o ro /dev/mapper/qubes_dom0-root /mnt
mount /dev/zram0 /sysroot mount -o nodev,nosuid,noatime,nodiratime,nobarrier,commit=60,data=writeback /dev/zram0 /sysroot
> :exclamation: You can update templates in live modes, **but update dom0 in persistent mode!** **Avoid experimenting with dom0 in Zram‑Live Mode** - it can break the system! For dom0 experiments, use only **Overlay‑Live Mode**. > :exclamation: You can update templates in live modes, **but update dom0 in persistent mode!** .

Revision #22

Edited on
2026-01-30
Edited by user
linuxuser1
**+Step 7. Creating a script to automatically edit** `/etc/grub.d/40_custom`. ****+Step 7. Creating a script to automatically create zram-mount.sh and edit /etc/grub.d/40_custom.**
**Run** `grub-custom.sh` ****Run** grub-custom.sh**
**+ Step 7. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **+ Step 8. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**

Revision #21

Edited on
2026-01-30
Edited by user
linuxuser1
> :exclamation: **Overlay-Live Mode** (used by native kicksecure/Whonix) is more secure and fast: > :mega: **Overlay-Live Mode** (used by native kicksecure/Whonix) is more secure and fast:
Overlay is much closer to a real Tails OS (a read‑only image). I added some additional flags to overlay‑tmpfs to strengthen the security of the live mode. > **Zram‑Live Mode** works by copying (`cp -a`) root to zram0 - it is a significantly less secure and slower scenario. But it saves RAM usage dramatically (~ 2x Overlay-Live Mode). Overlay is much closer to a real Tails OS (a read‑only image). :shield: I added [some additional flags to Overlay-Live Mode to strengthen the security](https://forum.qubes-os.org/t/qubes-os-live-mode-dom0-in-ram-non-persistent-boot-protection-against-forensics-tails-mode-hardening-dom0/38868/3). It makes the dom0 more hardened. > :loudspeaker: **Zram‑Live Mode** works by copying (`cp -a`) root to zram0 - it is a significantly less secure and slower scenario. Also not recommended to update dracut and GRUB while in Zram‑Live Mode - doing so could cause the system to break after a reboot! :gear: But it saves RAM usage dramatically (~ 2x Overlay-Live Mode). This mode is suitable for running Standalone Live VMs that require a lot of disk space.
> :exclamation: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish. ****!! Important:** If you set more than 10 GB of dom0_mem=max, also change ram-disk size in Step 6 line** `echo 10G > /sys/block/zram0/disksize` > :exclamation: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish.
**+ Step 6. Make New Dracut Script File zram-mount.sh:** `sudo touch /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh` `sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh` `sudo nano /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh` add: ``` #!/bin/sh . /lib/dracut-lib.sh if ! getargbool 0 rootzram ; then return fi mkdir /mnt umount /sysroot mount /dev/mapper/qubes_dom0-root /mnt modprobe zram echo 10G > /sys/block/zram0/disksize /mnt/usr/sbin/mkfs.ext2 /dev/zram0 mount /dev/zram0 /sysroot cp -a /mnt/* /sysroot exit 0 ``` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. **+ Step 7. Make New Dracut Config File ramboot.conf:** **+ Step 6. Make New Dracut Config File ramboot.conf:**
Press `Ctrl + X` to exit nano editor. **+ Step 8. Regenerate with New Dracut Automation Module:** `sudo dracut --verbose --force` **+Step 9. Creating a script to automatically edit** `/etc/grub.d/40_custom`. Press `Ctrl + X` to exit nano editor. **+Step 7. Creating a script to automatically edit** `/etc/grub.d/40_custom`.
Add: Add:
# Max memory dom0 DOM0_MAX_KB=$(xenstore-read /local/domain/0/memory/hotplug-max 2>/dev/null \ || xenstore-read /local/domain/0/memory/static-max 2>/dev/null \ || echo 0) if [ "$DOM0_MAX_KB" -gt 0 ]; then DOM0_MAX_MB=$(( DOM0_MAX_KB / 1024 )) DOM0_MAX_GB=$(( DOM0_MAX_MB / 1024 )) DOM0_MAX_GBG="${DOM0_MAX_GB}G" DOM0_MAX_RAM="dom0_mem=max:${DOM0_MAX_MB}M" else DOM0_MAX_RAM="dom0_mem=max:10240M" DOM0_MAX_GB="10" fi cat > /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh << EOF #!/bin/sh . /lib/dracut-lib.sh if ! getargbool 0 rootzram ; then return fi mkdir /mnt umount /sysroot mount /dev/mapper/qubes_dom0-root /mnt modprobe zram echo $DOM0_MAX_GBG > /sys/block/zram0/disksize /mnt/usr/sbin/mkfs.ext2 /dev/zram0 mount /dev/zram0 /sysroot cp -a /mnt/* /sysroot exit 0 EOF chmod 755 /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh # Update INITRAMFS dracut --verbose --force
multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M $DOM0_MAX_RAM ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts}
multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M $DOM0_MAX_RAM ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts}
# Update Grub # Update GRUB
Edit `40_custom` file and update **GRUB**: **Run** `grub-custom.sh` > (Create `/usr/lib/dracut/modules.d/01ramboot/zram-mount.sh`, Update **Dracut**, Edit `40_custom` file, update **GRUB**)
**+ Step 10. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **+ Step 7. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**
> :exclamation: You can update templates in live modes, **but update dom0 in persistent mode!** Now if dom0 updates kernels, just run `sudo /usr/local/bin/grub-custom.sh` and the live modes will work with the new kernels. > :exclamation: You can update templates in live modes, **but update dom0 in persistent mode!** **Avoid experimenting with dom0 in Zram‑Live Mode** - it can break the system! For dom0 experiments, use only **Overlay‑Live Mode**. > > Now if dom0 updates kernels or If you’ve changed `dom_mem=max` in GRUB, just run `sudo /usr/local/bin/grub-custom.sh` and the live modes will work with the new kernels, and max memory settings.

Revision #20

Edited on
2026-01-29
Edited by user
linuxuser1
**+ Step 2. Edit GRUB to Increase Dom0's Max RAM:** **+ Step 2. Edit GRUB:**
Within the `GRUB_CMDLINE_XEN_DEFAULT` line, make a partial modification of this line, from dom0_`mem=max:4096M` to now be `dom0_mem=max:10240M` → Just change the text “`4096M`” to “`10240M`” (without quotes). Edit line `GRUB_TIMEOUT=5` to `GRUB_TIMEOUT=30` (change 5 seconds to 30 seconds). Within the `GRUB_CMDLINE_XEN_DEFAULT` line, make a partial modification of this line, from dom0_`mem=max:4096M` to now be `dom0_mem=max:10240M` → Just change the text “`4096M`” to “`10240M`” (without quotes).
****!! Important:** also change ram-disk size in Step 8 line** `echo 10G > /sys/block/zram0/disksize` ****!! Important:** If you set more than 10 GB of dom0_mem=max, also change ram-disk size in Step 6 line** `echo 10G > /sys/block/zram0/disksize`

Revision #19

Edited on
2026-01-29
Edited by user
linuxuser1
**+Step 3. Creating a script to automatically edit** `/etc/grub.d/40_custom`. `sudo touch /usr/local/bin/grub-custom.sh` `sudo chmod 755 /usr/local/bin/grub-custom.sh` `sudo nano /usr/local/bin/grub-custom.sh` Add: ``` #!/bin/bash #BOOT_UUID BOOT_UUID=$(findmnt -n -o UUID /boot 2>/dev/null || echo "AUTO_BOOT_NOT_FOUND") if [ "$BOOT_UUID" = "AUTO_BOOT_NOT_FOUND" ]; then BOOT_UUID=$(blkid -s UUID -o value -d $(findmnt -n -o SOURCE /boot 2>/dev/null)) fi # LUKS_UUID LUKS_DEVICE=$(blkid -t TYPE="crypto_LUKS" -o device 2>/dev/null | head -n1 || echo "") if [ -n "$LUKS_DEVICE" ]; then LUKS_UUID=$(sudo cryptsetup luksUUID "$LUKS_DEVICE" 2>/dev/null) else LUKS_UUID="AUTO_LUKS_NOT_FOUND" fi # Latest XEN_PATH XEN_PATH=$(ls /boot/xen*.gz 2>/dev/null | sort -V | tail -1 | xargs basename 2>/dev/null || echo "/xen-4.19.4.gz") # Latest kernel/initramfs LATEST_KERNEL=$(ls /boot/vmlinuz-*qubes*.x86_64 2>/dev/null | grep -E 'qubes\.fc[0-9]+' | sort -V | tail -1 | xargs basename) LATEST_INITRAMFS=$(echo "/initramfs-${LATEST_KERNEL#vmlinuz-}.img") cat > /etc/grub.d/40_custom << EOF #!/usr/bin/sh exec tail -n +3 \$0 menuentry 'Qubes Overlay-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootovl quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } menuentry 'Qubes Zram-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootzram quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } EOF # Update Grub grub2-mkconfig -o /boot/grub2/grub.cfg ``` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. Edit `40_custom` file and update **GRUB**: `sudo /usr/local/bin/grub-custom.sh` **+ Step 4. Make New Directorys for Dracut Automation Modules:** **+ Step 3. Make New Directorys for Dracut Automation Modules:**
**+ Step 5. Make Two Dracut Script Files module-setup.sh:** **+ Step 4. Make Two Dracut Script Files module-setup.sh:**
**+ Step 6. Make New Dracut Script File overlay-mount.sh:** **+ Step 5. Make New Dracut Script File overlay-mount.sh:**
**+ Step 7. Make New Dracut Script File zram-mount.sh:** **+ Step 6. Make New Dracut Script File zram-mount.sh:**
**+ Step 8. Make New Dracut Config File ramboot.conf:** **+ Step 7. Make New Dracut Config File ramboot.conf:**
**+ Step 9. Regenerate with New Dracut Automation Module:** **+ Step 8. Regenerate with New Dracut Automation Module:**
**+Step 9. Creating a script to automatically edit** `/etc/grub.d/40_custom`. `sudo touch /usr/local/bin/grub-custom.sh` `sudo chmod 755 /usr/local/bin/grub-custom.sh` `sudo nano /usr/local/bin/grub-custom.sh` Add: ``` #!/bin/bash #BOOT_UUID BOOT_UUID=$(findmnt -n -o UUID /boot 2>/dev/null || echo "AUTO_BOOT_NOT_FOUND") if [ "$BOOT_UUID" = "AUTO_BOOT_NOT_FOUND" ]; then BOOT_UUID=$(blkid -s UUID -o value -d $(findmnt -n -o SOURCE /boot 2>/dev/null)) fi # LUKS_UUID LUKS_DEVICE=$(blkid -t TYPE="crypto_LUKS" -o device 2>/dev/null | head -n1 || echo "") if [ -n "$LUKS_DEVICE" ]; then LUKS_UUID=$(sudo cryptsetup luksUUID "$LUKS_DEVICE" 2>/dev/null) else LUKS_UUID="AUTO_LUKS_NOT_FOUND" fi # Latest XEN_PATH XEN_PATH=$(ls /boot/xen*.gz 2>/dev/null | sort -V | tail -1 | xargs basename 2>/dev/null || echo "/xen-4.19.4.gz") # Latest kernel/initramfs LATEST_KERNEL=$(ls /boot/vmlinuz-*qubes*.x86_64 2>/dev/null | grep -E 'qubes\.fc[0-9]+' | sort -V | tail -1 | xargs basename) LATEST_INITRAMFS=$(echo "/initramfs-${LATEST_KERNEL#vmlinuz-}.img") cat > /etc/grub.d/40_custom << EOF #!/usr/bin/sh exec tail -n +3 \$0 menuentry 'Qubes Overlay-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootovl quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } menuentry 'Qubes Zram-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootzram quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } EOF # Update Grub grub2-mkconfig -o /boot/grub2/grub.cfg ``` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. Edit `40_custom` file and update **GRUB**: `sudo /usr/local/bin/grub-custom.sh`

Revision #18

Edited on
2026-01-29
Edited by user
linuxuser1

Revision #17

Edited on
2026-01-29
Edited by user
linuxuser1
This guide combines the best practices from this topic https://forum.qubes-os.org/t/qubes-in-tmpfs/11127. It offers two live‑mode options in a single convenient menu. The old topic’s founder and one of its main contributors are no longer active on forum. I created this guide so users don’t have to read through the entire topic of almost 100 comments looking for a final solution. I’ve been using this guide for four months. You will get two ways to launch **dom0** in RAM for protection against forensics: 1. [dom0 in zram0](https://forum.qubes-os.org/t/qubes-in-tmpfs/11127/30) 2. dom0 in overlay-tmpfs [(Kicksecure/Whonix live mode)](https://www.kicksecure.com/wiki/Live_Mode#HOST_specifics_(Kicksecure_as_host_OS)) This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. It will extend the lifespan of your SSD. This guide also solves the old problem of [porting grub‑live to Qubes](https://github.com/QubesOS/qubes-issues/issues/4982). > :exclamation:The second scenario (overlay in tmpfs), used by native kicksecure/Whonix, is more secure: This guide combines the best practices from this topic https://forum.qubes-os.org/t/qubes-in-tmpfs/11127 and it adds new options and capabilities for launching Qubes in RAM. (The old topic’s founder and one of its main contributors are no longer active on forum) This guide adds two new options to the GRUB menu for safely launching live modes. You will get two ways to launch **dom0** in RAM for protection against forensics: 1. **Qubes Overlay-Live Mode** 2. **Qubes Zram-Live Mode** ![g|689x434](upload://nTmXgMRh1RnxQ9Ry3mekJVULijo.jpeg) This guide solves the old problem of [ implement live boot by porting grub-live to Qubes - amnesia / non-persistent boot / anti-forensics](https://github.com/QubesOS/qubes-issues/issues/4982). This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. It will extend the lifespan of your SSD. > :exclamation: **Overlay-Live Mode** (used by native kicksecure/Whonix) is more secure and fast:
> 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 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.
> The only advantage of working with zram0 is memory savings. You will need: at least 16 GB RAM for **zram0 mode** and at least 24 GB RAM for **overlayfs on tmpfs mode** for comfortably launching several qubes in live mode. > **Zram‑Live Mode** works by copying (`cp -a`) root to zram0 - it is a significantly less secure and slower scenario. But it saves RAM usage dramatically (~ 2x Overlay-Live Mode). You will need: at least 16 GB RAM for **Zram-Live Mode** and at least 24 GB RAM for **Overlay-Live Mode** for comfortably launching several qubes in live mode.
Regenerate with New GRUB Configuration: *If you are using Qubes 4.2 / 4.3, you should run this single command:* `sudo grub2-mkconfig -o /boot/grub2/grub.cfg` **+ Step 3. Make New Directorys for Dracut Automation Modules:** **+Step 3. Creating a script to automatically edit** `/etc/grub.d/40_custom`. `sudo touch /usr/local/bin/grub-custom.sh` `sudo chmod 755 /usr/local/bin/grub-custom.sh` `sudo nano /usr/local/bin/grub-custom.sh` Add: ``` #!/bin/bash #BOOT_UUID BOOT_UUID=$(findmnt -n -o UUID /boot 2>/dev/null || echo "AUTO_BOOT_NOT_FOUND") if [ "$BOOT_UUID" = "AUTO_BOOT_NOT_FOUND" ]; then BOOT_UUID=$(blkid -s UUID -o value -d $(findmnt -n -o SOURCE /boot 2>/dev/null)) fi # LUKS_UUID LUKS_DEVICE=$(blkid -t TYPE="crypto_LUKS" -o device 2>/dev/null | head -n1 || echo "") if [ -n "$LUKS_DEVICE" ]; then LUKS_UUID=$(sudo cryptsetup luksUUID "$LUKS_DEVICE" 2>/dev/null) else LUKS_UUID="AUTO_LUKS_NOT_FOUND" fi # Latest XEN_PATH XEN_PATH=$(ls /boot/xen*.gz 2>/dev/null | sort -V | tail -1 | xargs basename 2>/dev/null || echo "/xen-4.19.4.gz") # Latest kernel/initramfs LATEST_KERNEL=$(ls /boot/vmlinuz-*qubes*.x86_64 2>/dev/null | grep -E 'qubes\.fc[0-9]+' | sort -V | tail -1 | xargs basename) LATEST_INITRAMFS=$(echo "/initramfs-${LATEST_KERNEL#vmlinuz-}.img") cat > /etc/grub.d/40_custom << EOF #!/usr/bin/sh exec tail -n +3 \$0 menuentry 'Qubes Overlay-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootovl quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } menuentry 'Qubes Zram-Live Mode (latest kernel)' --class qubes --class gnu-linux --class gnu --class os --class xen \$menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root $BOOT_UUID echo 'Loading Xen ...' if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi insmod multiboot2 multiboot2 /$XEN_PATH placeholder console=none dom0_mem=min:1024M dom0_mem=max:10240M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 \${xen_rm_opts} echo 'Loading Linux $LATEST_KERNEL ...' module2 /$LATEST_KERNEL placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=$LUKS_UUID rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb rootzram quiet usbcore.authorized_default=0 echo 'Loading initial ramdisk ...' insmod multiboot2 module2 --nounzip $LATEST_INITRAMFS } EOF # Update Grub grub2-mkconfig -o /boot/grub2/grub.cfg ``` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. Edit `40_custom` file and update **GRUB**: `sudo /usr/local/bin/grub-custom.sh` **+ Step 4. Make New Directorys for Dracut Automation Modules:**
**+ Step 4. Make Two Dracut Script Files module-setup.sh:** **+ Step 5. Make Two Dracut Script Files module-setup.sh:**
inst_simple "$moddir/tmpfs.sh" "/usr/bin/tmpfs" inst_hook cleanup 00 "$moddir/pass.sh" inst_simple "$moddir/zram-mount.sh" inst_hook cleanup 00 "$moddir/zram-mount.sh"
**+ Step 5. Make New Dracut Script File overlay-mount.sh:** **+ Step 6. Make New Dracut Script File overlay-mount.sh:**
#!/bin/sh # make a read-only nfsroot writeable by using overlayfs # the nfsroot is already mounted to $NEWROOT #!/bin/sh
modprobe overlay # a little bit tuning mount -o remount,nolock,noatime $NEWROOT # Move root modprobe overlay mount -o remount,nolock,noatime $NEWROOT
umount $NEWROOT # Create tmpfs umount $NEWROOT
mount -n -t tmpfs -o mode=0755,size=100% tmpfs /cow mkdir /cow/work /cow/rw # Merge both to new Filesystem mount -t overlay -o noatime,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions overlay $NEWROOT # Let filesystems survive pivot mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,relatime tmpfs /cow mkdir /cow/work /cow/rw mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions,relatime overlay $NEWROOT
**+ Step 6. Make New Dracut Script File pass.sh:** `sudo touch /usr/lib/dracut/modules.d/01ramboot/pass.sh` `sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/pass.sh` `sudo nano /usr/lib/dracut/modules.d/01ramboot/pass.sh` Add: ``` #!/usr/bin/bash command -v ask_for_password >/dev/null || . /lib/dracut-crypt-lib.sh PROMPT="Enter boot mode: t-tmpfs, z-zram, s-ssd" CMD="/usr/bin/tmpfs" TRY="3" ask_for_password --cmd "$CMD" --prompt "$PROMPT" --tries "$TRY" --ply-cmd "$CMD" --ply-prompt "$PROMPT" --ply-tries "$TRY" --tty-cmd "$CMD" --tty-prompt "$PROMPT" --tty-tries "$TRY" --tty-echo-off ``` Press `Ctrl + O` to save file. Press `Ctrl + X` to exit nano editor. > > :exclamation:You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like. :warning: If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)! But keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password! **+ Step 7. Make New Dracut Script File tmpfs.sh:** `sudo touch /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh` `sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh` `sudo nano /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh` **+ Step 7. Make New Dracut Script File zram-mount.sh:** `sudo touch /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh` `sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh` `sudo nano /usr/lib/dracut/modules.d/01ramboot/zram-mount.sh`
read line case "${line:-Nn}" in [Tt]* ) . /lib/dracut-lib.sh modprobe overlay mount -o remount,nolock,noatime $NEWROOT mkdir -p /live/image mount --bind $NEWROOT /live/image umount $NEWROOT mkdir /cow mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,relatime tmpfs /cow mkdir /cow/work /cow/rw mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions,relatime overlay $NEWROOT mkdir -p $NEWROOT/live/cow mkdir -p $NEWROOT/live/image mount --bind /cow/rw $NEWROOT/live/cow umount /cow mount --bind /live/image $NEWROOT/live/image umount /live/image ;; [Zz]* ) . /lib/dracut-lib.sh if ! getargbool 0 rootzram ; then return fi
;; [Ss]* ) exit 0 ;; * ) exit 1 ;; esac
> :exclamation:Don't add templates to **varlibqubes** - templates don't retain any session data in an appVM (that's the point of Qubes' isolation). So, in live mode it's sufficient that only the **private** and **volatile** storages are active. You can inspect all template metadata yourself and verify that none of them contain artifacts from sessions in appVM. :exclamation:You can update templates in live modes, but update dom0 in persistent mode (ssd)! **Then Restart Qubes OS and Test Qubes live modes :wink:** My boot menu version (I just type the first letter of each mode at boot :slightly_smiling_face:) ![1|658x456](upload://ipYZM4Uc8mmiipzqm9cefnhqqes.png) > zram0 mode saves a lot of memory (you can run roughly twice as many qubes in live mode!), but it takes longer to start (about 30–40 seconds more) and is slightly less secure than overlay-tmpfs. > overlay in tmpfs loads quickly and is maximally secure, but it requires more memory. > :exclamation:Don't add templates to **varlibqubes** - templates don't retain any session data in an appVM (that's the point of Qubes' isolation). So, in live mode it's sufficient that only the **private** and **volatile** storages are active. You can inspect all template metadata yourself and verify that none of them contain artifacts from sessions in appVM. **Restart Qubes OS and Test Qubes live modes :wink:** ![g|689x434](upload://nTmXgMRh1RnxQ9Ry3mekJVULijo.jpeg) > Zram-Live Mode takes longer to start (about 30–40 seconds more). > :exclamation: You can update templates in live modes, **but update dom0 in persistent mode!** Now if dom0 updates kernels, just run `sudo /usr/local/bin/grub-custom.sh` and the live modes will work with the new kernels.

Revision #16

Edited on
2026-01-28
Edited by user
linuxuser1
Overlay is much closer to a real Tails OS (a read‑only image). Overlay is much closer to a real Tails OS (a read‑only image). I added some additional flags to overlay‑tmpfs to strengthen the security of the live mode.
mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions ,relatime overlay $NEWROOT mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions,relatime overlay $NEWROOT

Revision #15

Edited on
2026-01-28
Edited by user
linuxuser1
# a little bit tuning
# Move root
# Create tmpfs
mount -n -t tmpfs -o mode=0755,size=100% tmpfs /cow #mount /dev/zram0 /cow mount -n -t tmpfs -o mode=0755,size=95%,nr_inodes=500k,noexec,nodev,nosuid,relatime tmpfs /cow
# Merge both to new Filesystem mount -t overlay -o noatime,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions overlay $NEWROOT # Let filesystems survive pivot mount -t overlay -o noatime,volatile,lowerdir=/live/image,upperdir=/cow/rw,workdir=/cow/work,default_permissions ,relatime overlay $NEWROOT

Revision #14

Edited on
2026-01-27
Edited by user
linuxuser1
> :exclamation:Don't add templates to **varlibqubes** - templates don't retain any session data in an appVM (that's the point of Qubes' isolation). So, in live mode it's sufficient that only the **private** and **volatile** storages are active. You can inspect all template metadata yourself and verify that none of them contain artifacts from sessions in appVM. > :exclamation:Don't add templates to **varlibqubes** - templates don't retain any session data in an appVM (that's the point of Qubes' isolation). So, in live mode it's sufficient that only the **private** and **volatile** storages are active. You can inspect all template metadata yourself and verify that none of them contain artifacts from sessions in appVM. :exclamation:You can update templates in live modes, but update dom0 in persistent mode (ssd)!
> You can update templates in live mode, but update dom0 in persistent mode.

Revision #13

Edited on
2026-01-27
Edited by user
linuxuser1
PROMPT="Enter boot mode: t-tmpfs, z-zram0, s-ssd" PROMPT="Enter boot mode: t-tmpfs, z-zram, s-ssd"
> :exclamation:You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like (but keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password). If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)! > :exclamation:You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like. :warning: If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)! But keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password!

Revision #12

Edited on
2026-01-27
Edited by user
linuxuser1
:flashlight: You can use this terminal theme so can see which mode you’re currently in: :flashlight: You can add a “System Monitor” widget to the XFCE panel and configure it to run command `findmnt -n -o SOURCE /`. This widget will display which mode you’re currently in: ![1|461x130](upload://1JsKPliPTxLCSHyQYukusxHa2Mn.png) You can also use this terminal theme so can see which mode you’re currently in:

Revision #11

Edited on
2026-01-27
Edited by user
linuxuser1
> The second scenario (overlay in tmpfs), used by native kicksecure/Whonix, is more secure: > Root filesystem is effectively read‑only > :exclamation:The second scenario (overlay in tmpfs), used by native kicksecure/Whonix, is more secure: > Root filesystem is effectively read‑only.
> Note: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish. > :exclamation: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish.
> You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like (but keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password). If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)! > :exclamation:You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like (but keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password). If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)!
> Since only dom0 runs in live mode, you have to start the VMs from the pool in dom0. You can use the default pool `varlibqubes` or [create a new pool](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-pool.html). > :exclamation:Since only dom0 runs in live mode, you have to start the VMs from the pool in dom0. You can use the default pool `varlibqubes` or [create a new pool](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-pool.html).
> :exclamation:Don't add templates to **varlibqubes** - templates don't retain any session data in an appVM (that's the point of Qubes' isolation). So, in live mode it's sufficient that only the **private** and **volatile** storages are active. You can inspect all template metadata yourself and verify that none of them contain artifacts from sessions in appVM.

Revision #10

Edited on
2026-01-27
Edited by user
linuxuser1
> The only advantage of working with zram0 is memory savings. You will need: at least 16 GB RAM for **zram0 mode** and at least 32 GB RAM for **overlayfs on tmpfs mode** for comfortably launching several qubes in live mode. > The only advantage of working with zram0 is memory savings. You will need: at least 16 GB RAM for **zram0 mode** and at least 24 GB RAM for **overlayfs on tmpfs mode** for comfortably launching several qubes in live mode.
![1|401x186](upload://zV00csxFTZHRbiSxbkLF1z2BtU9.png)

Revision #9

Edited on
2026-01-27
Edited by user
linuxuser1
Launching requires a lot of memory: at least 16 GB for **zram0 mode** and at least 32 GB for **overlayfs on tmpfs 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. Overlay is much closer to a real Tails OS (a read‑only image). > The only advantage of working with zram0 is memory savings. You will need: at least 16 GB RAM for **zram0 mode** and at least 32 GB RAM for **overlayfs on tmpfs mode** for comfortably launching several qubes in live mode.

Revision #8

Edited on
2026-01-26
Edited by user
linuxuser1
> You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like (but keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password). If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 8)! > You will need to press one of three letters during the Qubes startup. You can edit the line "Enter boot mode: t-tmpfs, z-zram, s-ssd" however you like (but keep in mind that the letter used to launch a mode must not match the first letter of your password! Otherwise, one of the modes will start automatically after you enter the password). If you want to use different letters to launch the modes, then specify those same letters in the next script (Step 7)!

Revision #7

Edited on
2026-01-26
Edited by user
linuxuser1
That will permanently disable your Dom0 Swap after restart, which is likely best for operating Qubes Dom0 in live mode. If you still want to frequently use Qubes in Persistent mode and have Dom0 Swap enabled, then you can alternatively skip this permanent disable step, and rather temporarily disable Dom0 Swap when you startup Qubes Live by remembering (each and every time) to manually run the following Dom0 command… That will permanently disable your Dom0 Swap after restart, which is likely best for operating Qubes Dom0 in live mode.

Revision #6

Edited on
2026-01-26
Edited by user
linuxuser1
This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. This guide also solves the old problem of [porting grub‑live to Qubes](https://github.com/QubesOS/qubes-issues/issues/4982). launching requires a lot of memory: at least 16 GB for **zram0 mode** and at least 32 GB for **overlayfs on tmpfs mode**. This also works great for experiments in Qubes or for beginners who want to learn without fear of breaking anything - all changes disappear after a reboot. It will extend the lifespan of your SSD. This guide also solves the old problem of [porting grub‑live to Qubes](https://github.com/QubesOS/qubes-issues/issues/4982). Launching requires a lot of memory: at least 16 GB for **zram0 mode** and at least 32 GB for **overlayfs on tmpfs mode**.

Revision #5

Edited on
2026-01-25
Edited by user
linuxuser1
Using nano, type a **#** character in front of the line containing “`/dev/mapper/qubes_dom0-swap`”, to comment it out and disable it, like this: ``` #/dev/mapper/qubes_dom0-swap ... ``` Using nano, type a **#** character in front of the line with word “**swap**” in the middle (**usually the last line**). Like this: `#UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx swap defaults,x-systemd.device-timeout=0 0 0`
In the Qube Manager click **Clone Qube**, then in **Advanced** select a pool in dom0 (not `vm‑pool`). If you have a lot of memory, you can run all appVMs (sys, dvm, appVM) in live mode. > Since only dom0 runs in live mode, you have to start the VMs from the pool in dom0. You can use the default pool `varlibqubes` or [create a new pool](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-pool.html). > Since only dom0 runs in live mode, you have to start the VMs from the pool in dom0. You can use the default pool `varlibqubes` or [create a new pool](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-pool.html). In the Qube Manager click **clone qube**, then in **Advanced** select a pool in dom0 (`varlibqubes` or your new pool. **not vm‑pool**). If you have a lot of memory, you can run all appVMs (sys, dvm, appVM) in live mode.

Revision #4

Edited on
2026-01-25
Edited by user
linuxuser1
It offers two live‑mode options in a single convenient menu. The topic’s founder and one of its main contributors are no longer active on forum. I created this guide so users don’t have to read through the entire topic of almost 100 comments looking for a final solution. I’ve been using this guide for four months. It offers two live‑mode options in a single convenient menu. The old topic’s founder and one of its main contributors are no longer active on forum. I created this guide so users don’t have to read through the entire topic of almost 100 comments looking for a final solution. I’ve been using this guide for four months.
But launching requires a lot of memory: at least 16 GB for **zram0 mode** and at least 32 GB for **overlayfs on tmpfs mode**. launching requires a lot of memory: at least 16 GB for **zram0 mode** and at least 32 GB for **overlayfs on tmpfs mode**.
****!! Important:** also change the ram-disk size in Step 8 line** `echo 10G > /sys/block/zram0/disksize` ****!! Important:** also change ram-disk size in Step 8 line** `echo 10G > /sys/block/zram0/disksize`
**Step 3. Make New Directorys for Dracut Automation Modules:** **+ Step 3. Make New Directorys for Dracut Automation Modules:**
# --move does not always work. Google >mount move "wrong fs"< for # details
PROMPT="Enter boot mode: t-tmpfs, z-zram, s-ssd" PROMPT="Enter boot mode: t-tmpfs, z-zram0, s-ssd"

Revision #3

Edited on
2026-01-25
Edited by user
linuxuser1
**+ Step 3. Regenerate with New GRUB Configuration:** If you are using Qubes 4.2 / 4.3, you should run this single command: Regenerate with New GRUB Configuration: *If you are using Qubes 4.2 / 4.3, you should run this single command:*
**Step 4. Make New Directorys for Dracut Automation Modules:** **Step 3. Make New Directorys for Dracut Automation Modules:**
**+ Step 5. Make Two Dracut Script Files module-setup.sh:** **+ Step 4. Make Two Dracut Script Files module-setup.sh:**
**+ Step 6. Make New Dracut Script File overlay-mount.sh:** **+ Step 5. Make New Dracut Script File overlay-mount.sh:**
**+ Step 7. Make New Dracut Script File pass.sh:** **+ Step 6. Make New Dracut Script File pass.sh:**
**+ Step 8. Make New Dracut Script File tmpfs.sh:** **+ Step 7. Make New Dracut Script File tmpfs.sh:**
**+ Step 9. Make New Dracut Config File ramboot.conf:** **+ Step 8. Make New Dracut Config File ramboot.conf:**
**+ Step 10. Regenerate with New Dracut Automation Module:** **+ Step 9. Regenerate with New Dracut Automation Module:**
**+ Step 11. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0** **+ Step 10. Clone dangerous qubes (dvm‑template, appVMs) into a pool in dom0**

Revision #2

Edited on
2026-01-25
Edited by user
linuxuser1
That will permanently disable your Dom0 Swap after restart, which is likely best for operating Qubes Dom0 in Stateless mode. If you still want to frequently use Qubes in Persistent mode and have Dom0 Swap enabled, then you can alternatively skip this permanent disable step, and rather temporarily disable Dom0 Swap when you startup Qubes Stateless by remembering (each and every time) to manually run the following Dom0 command… That will permanently disable your Dom0 Swap after restart, which is likely best for operating Qubes Dom0 in live mode. If you still want to frequently use Qubes in Persistent mode and have Dom0 Swap enabled, then you can alternatively skip this permanent disable step, and rather temporarily disable Dom0 Swap when you startup Qubes Live by remembering (each and every time) to manually run the following Dom0 command…
> Note: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish. > Note: If you have something like 32GB of RAM or greater in your system, and you want to run several fully stateless user qubes within Dom0 RAM space, then you may want to consider increasing this “10240M” Dom0 RAM maximum value, in order to allow for more Dom0 RAM space where you can store more user qubes as fully stateless. For example, with 32GB of system RAM, you may choose to allocate “20480M” (20GB) or even greater if you wish. ****!! Important:** also change the ram-disk size in Step 8 line** `echo 10G > /sys/block/zram0/disksize`
If you have limited memory, use this guide: https://forum.qubes-os.org/t/really-disposable-ram-based-qubes/21532**If you have limited memory, use this guide:** https://forum.qubes-os.org/t/really-disposable-ram-based-qubes/21532