Qubes in tmpfs 🤫

[deeplow]

As peoppe use the forum they gain more capabilities. @qstateless was pretty much in Trust Level 2 (missing only giving one like). I’ve upgraded you know.

So you should now be able to edit posts up to 30 days I hope that helps

[qubesuser1234]

@qstateless I think i have to delete the folder and files inside efi/qubes and then try to run “sudo grub2-mkconfig -o /boot/grub2/grub.cfg” and “sudo grub2-mkconfig -o /boot/efi/EFI/grub.cfg”

But i’m wondering if it will break my system ? Can someone tell me what will happen if i try to do this ?

[qstateless]

@deeplow

I’ve upgraded you know.

So you should now be able to edit posts up to 30 days I hope that helps

Thanks @deeplow and @gonzalo-bulnes! It looks like I can edit that past post now. That helps!

I will plan on updating the step-by-step instructions post with proper straight-quote (") characters, as well as some file hash verification steps.

@qubesuser1234

@qstateless I think i have to delete the folder and files inside efi/qubes and then try to run “sudo grub2-mkconfig -o /boot/grub2/grub.cfg” and “sudo grub2-mkconfig -o /boot/efi/EFI/grub.cfg”

But i’m wondering if it will break my system ? Can someone tell me what will happen if i try to do this ?

@qubesuser1234 - DO NOT delete your EFI or EFI/qubes folders. There are other Xen files in there, and your system might not boot if you did that. No to deleting folders here.

The matter just comes down to what path your EFI grub.cfg file should be located at. As mentiond…

My EFI grub.cfg in Qubes 4.1.X is specifically located at:

/boot/efi/EFI/grub.cfg

Buy you said that your EFI grub.cfg in your Qubes 4.1.X is specifically located at:

/boot/efi/EFI/qubes/grub.cfg

I wonder if you also have another grub.cfg at /boot/efi/EFI/grub.cfg ?

To check for these grub.cfg files, run the following commands and see if any grub.cfg files are present in one or both of these locations:

sudo ls /boot/efi/EFI
sudo ls /boot/efi/EFI/qubes

I believe the grub2-mkconfig command generates the grub.cfg file and places it at whatever path one specifies in the -o parameter.

I would not think that having an extra grub.cfg file within both of the /boot/efi/EFI and /boot/efi/EFI/qubes directories would interfere with the boot, as the system would probably just only use one of them.

After updating your /etc/default/grub file in Step #2, you could probably generate a grub.cfg in all three locations, like this:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg
sudo grub2-mkconfig -o /boot/efi/EFI/grub.cfg

In my step-by-step instructions, the only thing that’s changed in GRUB is the Max Dom0 memory, which should not prevent stateless booting itself.

Since Dom0 system files are being altered, it is highly advisable that one first performs a full backup all of their qubes and data, in case the worst case scenario happens and your system won’t boot.

[qubesuser1234]

Running sudo ls command give me this :

yukz@dom0 ~> sudo ls /boot/efi/EFI
BOOT fedora grub.cfg qubes
yukz@dom0 ~> sudo ls /boot/efi/EFI/qubes
fonts grub.cfg grubx64.efi initramfs-6.1.12-1.qubes.fc32.x86_64.img xen-4.14.6.efi xen.efi

@qstateless

Buy you said that your EFI grub.cfg in your Qubes 4.1.X is specifically located at:

/boot/efi/EFI/qubes/grub.cfg

Yes but why my grub.cfg is inside a qubes folder by default ? I do not understand why it’s not like you but like i said i think this is the problem your script can’t work properly on my system because of this

[qstateless]

FYI: I just updated the step-by-step instructions to correct the malformed quote characters. Will plan to still add some additional verification steps in another update.

@qubesuser1234

Running sudo ls command give me this :

yukz@dom0 ~> sudo ls /boot/efi/EFI
BOOT fedora grub.cfg qubes
yukz@dom0 ~> sudo ls /boot/efi/EFI/qubes
fonts grub.cfg grubx64.efi initramfs-6.1.12-1.qubes.fc32.x86_64.img xen-4.14.6.efi xen.efi

So you do have 2 separate grub.cfg files, one in both of those different directories.

@qubesuser1234

Yes but why my grub.cfg is inside a qubes folder by default ?

Not sure why. Are you sure it was in there by default? Could you have possibly accidentally mistyped a command or file path and caused an extra one to be put into the qubes sub-directory?

xuy’s original instructions from last year, during the Qubes 4.1.X era, used the same path that my own system’s EFI grub.cfg file is in (/boot/efi/EFI/grub.cfg).

A clean install of 4.1.X could tell you what the default location of the grub.cfg files are for certain, if you are determined to find that out.

In Qubes 4.2, the multiple grub.cfg files situation for EFI and legacy boot was unified into one single grub.cfg file location, so it is a bit simpler in Qubes 4.2.

@qubesuser1234

but like i said i think this is the problem your script can’t work properly on my system because of this

I don’t think this would be the case, as explained in my previous replies.

Have you re-checked the hashes of your script files since I posted the hashes?

Run:

sudo sha1sum /usr/lib/dracut/modules.d/01ramboot/*
sudo sha1sum /etc/dracut.conf.d/ramboot.conf

Should match these hashes:

@qstateless

In the meantime, here are the believed correct file hashes I have:

sha1sum

105190ac916968e49f85911fd3ca2e29909ae327  /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
8ea26fb215217c67c6806b40d760b57f24025047  /usr/lib/dracut/modules.d/01ramboot/pass.sh
f9155e309af3a0a776b3a5b0f8ec2951f1178ff1  /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
1ed767101974b65db6fb30346e96030a78d89567  /etc/dracut.conf.d/ramboot.conf

[qubesuser1234]

yukz@dom0 ~> sudo sha1sum /usr/lib/dracut/modules.d/01ramboot/*
105190ac916968e49f85911fd3ca2e29909ae327 /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
8ea26fb215217c67c6806b40d760b57f24025047 /usr/lib/dracut/modules.d/01ramboot/pass.sh
f9155e309af3a0a776b3a5b0f8ec2951f1178ff1 /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
yukz@dom0 ~> sudo sha1sum /etc/dracut.conf.d/ramboot.conf
1ed767101974b65db6fb30346e96030a78d89567 /etc/dracut.conf.d/ramboot.conf

As you can see we have the same hashes but it’s doesn’t work i will try to reinstall Qubes 4.1.2 and see if it’s working.

@qstateless

Not sure why. Are you sure it was in there by default? Could you have possibly accidentally mistyped a command or file path and caused an extra one to be put into the qubes sub-directory?

Just for be sure i will reinstall the system and give you some feedback i will see if it was there by default

[qstateless]

I just updated the Qubes Stateless step-by-step instructions. Enjoy!

This update includes the addition of a Disable Dom0 Swap step and file verification sub-steps.

Edit Updates thus far:

#1. 2023-11-11

• Corrected malformed curly/angled-quotes to now be plain straight-quote characters ("), by removing improper HTML code tags that did not work well with Qubes Forum software (Discourse), which was preventing the stateless boot software from running properly if users had copied the malformed quote characters verbatim.
• Added Qubes 4.1 GRUB commands.
• Added user backup warning/recommendation.
• Minor Edits

#2. 2023-11-12

• Added Disable Dom0 Swap step
• Added file verification sub-steps
• Minor Edits

[Bob3]

Thanks a lot @qstateless and @xuy . You came up with a big breakthrough for Qubes IMHO. I am a big noob and I am concerned that I might mess up or misunderstand something, so as a good noob I went to a language model and asked to make a script based on the instructions of @qstateless .

#!/bin/bash

# Check if the script is running as root
if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

# Step 0: Create a Save Qube (optional)
echo "Creating a Save Qube..."
qvm-create -l blue --prop=netvm= save

# Step 1: Disable Dom0 Swap
echo "Disabling Dom0 Swap..."
sudo swapoff -a

# Step 2: Edit GRUB to Increase Dom0's Max RAM
echo "Editing GRUB Configuration..."
sed -i 's/dom0_mem=max:4096M/dom0_mem=max:10240M/' /etc/default/grub

# Step 3: Regenerate with New GRUB Configuration
echo "Updating GRUB Configuration..."
if [ -d /boot/efi/EFI/grub.cfg ]; then
    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    sudo grub2-mkconfig -o /boot/efi/EFI/grub.cfg
else
    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
fi

# Step 4: Make New Directory for Dracut Automation Module
echo "Creating Dracut Automation Module directory..."
sudo mkdir -p /usr/lib/dracut/modules.d/01ramboot

# Step 5: Create Dracut Script File module-setup.sh
echo "Creating module-setup.sh..."
cat <<EOF > /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
#!/usr/bin/bash
check() {
    return 0
}
depends() {
    return 0
}
install() {
    inst_simple "\$moddir/tmpfs.sh" "/usr/bin/tmpfs"
    inst_hook cleanup 00 "\$moddir/pass.sh"
}
EOF
sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/module-setup.sh

# Step 6: Create Dracut Script File pass.sh
echo "Creating pass.sh..."
cat <<EOF > /usr/lib/dracut/modules.d/01ramboot/pass.sh
#!/usr/bin/bash
command -v ask_for_password >/dev/null || . /lib/dracut-crypt-lib.sh
PROMPT="Boot to RAM? (y/n)"
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
EOF
sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/pass.sh

# Step 7: Create Dracut Script File tmpfs.sh
echo "Creating tmpfs.sh..."
cat <<EOF > /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
#!/usr/bin/bash
read line
case "\${line:-Nn}" in
[Yy]* )
    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
    ;;
[Nn]* )
    exit 0
    ;;
esac
EOF
sudo chmod 755 /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh

# Step 8: Make New Dracut Config File ramboot.conf
echo "Creating ramboot.conf..."
cat <<EOF > /etc/dracut.conf.d/ramboot.conf
add_drivers+=" zram "
add_dracutmodules+=" ramboot "
EOF

# Step 9: Regenerate with New Dracut Automation Module
echo "Regenerating Dracut..."
sudo dracut --verbose --force

echo "Setup completed. Please manually shut down and restart your system to test Qubes Stateless."

Is this any good? Would it work just moving it to dom0 and executing it as root?

[Bob3]

I have tried to follow all of the instructions as well, I have checked that all of the hashes match and they do. But it is not working for me .

The system boots again but without asking if I want to boot in RAM or not.

[qstateless]

Major Update: I just updated the Qubes Stateless step-by-step instructions.

CODE ERROR DETECTED AND CORRECTED!

I found the slight code error that is the culprit preventing your Qubes Stateless from running on boot.

There indeed was a code error preventing a successful run within the tmpfs.sh file.

The case logic in my posted tmpfs.sh file ended like this:

[Nn]* )
exit 0
;;
esac

However, it should have ended like this:

[Nn]* )
exit 0
;;
* )
exit 1
;;
esac

It was missing this slight portion of code near the end:

* )
exit 1
;;

This was causing the stateless “Boot to RAM? (y/n)” prompt not to show and be automatically skipped.

Somehow, between my development computer and my test computer, a code regression occurred, where my test computer received the good working code but my development computer was showing the bad non-working code making me misbelieve it was good.

Error is fixed now. Should be fully working. My apologies for the frustration.

@qubesuser1234 and @Bob3 and everyone else… Please feel free to retry the Qubes Stateless step-by-step instructions again and confirm that Qubes Stateless is now successfully working for you.

Also, here are the new believed correct file hashes I have (which I matched in the updated instructions):

sha1sum

105190ac916968e49f85911fd3ca2e29909ae327  /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
8ea26fb215217c67c6806b40d760b57f24025047  /usr/lib/dracut/modules.d/01ramboot/pass.sh
9c8309dc808204d4eccee0da55d592a6cc320834  /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
1ed767101974b65db6fb30346e96030a78d89567  /etc/dracut.conf.d/ramboot.conf

sha256sum

cb3e802e9604dc9b681c844d6e8d72a02f2850909ede9feb7587e7f3c2f11b8a  /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
a2750fa31c216badf58d71abbc5b92097e8be21da23bbae5779d9830e2fdd144  /usr/lib/dracut/modules.d/01ramboot/pass.sh
d9e85c06c3478cc0cf65a4e017af1a4f9f9dd4ad87c71375e8d4604399f5217d  /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
60d69ee8f27f68a5ff66399f63a10900c0ea9854ea2ff7a77c68b2a422df4bef  /etc/dracut.conf.d/ramboot.conf

sha512sum

8a1551a0d9fdb6fe543ef302a89f085de6c3e4dfb1648795fa73f6096277e5d9e2e108fcb4756549f4ab1544c6950a86c76f05701156b229325e592447972bae  /usr/lib/dracut/modules.d/01ramboot/module-setup.sh
3a890a4055bd8cad1b790ad2092c3f481ed512d7082d491951f2b474f519124c086cc38b8a3055914938cab223e496a1c101cc79d415cb5cf57010d6e6ef2fb6  /usr/lib/dracut/modules.d/01ramboot/pass.sh
e95af846c48d7cf6e0fd659af5296aa532cbd1fb1d337d05c2a69251429e17b47471d4476ad31fe93f96b17703bf38e1eb20306a3875aef973592103c40f20e8  /usr/lib/dracut/modules.d/01ramboot/tmpfs.sh
86d4ff45c86c4cee0ac5e92f8ed52183fa2e8445154f963bfe3cd91ced390a488a926e3627c55b9c6fd598e8105088638c0b90a838a403c4acaefe6519758a05  /etc/dracut.conf.d/ramboot.conf

[qstateless]

@Bob3

Thanks a lot @qstateless and @xuy . You came up with a big breakthrough for Qubes IMHO.

Yeah, big thanks to @xuy for researching and delivering the innovation to us. I’ve been using it since last year and it is a game changer. I hope my step-by-step instructions can now make it accessible for more people in the Qubes community.

@Bob3

I am a big noob and I am concerned that I might mess up or misunderstand something, so as a good noob I went to a language model and asked to make a script based on the instructions of @qstateless .

Is this any good? Would it work just moving it to dom0 and executing it as root?

Couldn’t be sure without testing. A lot of it looks ok at a glance, but not sure.

I may be thinking of developing an automated Qubes Stateless installer script in the upcoming future to make this system even more easy.

@Bob3

I have tried to follow all of the instructions as well, I have checked that all of the hashes match and they do. But it is not working for me .

The system boots again but without asking if I want to boot in RAM or not.

Yes! My fault. Error found and corrected. See my prior post for explanation.

Qubes Stateless step-by-step instructions have been updated and should be fully working now.

Enjoy being stateless!

[Bob3]

I am really eager to complete this and build my system around it so I already made the changes you suggested.

I get asked if I want to boot to RAM after inserting the decryption pass, but I tried to open a new tab in firefox on the personal domain and after restarting and booting selecting n I find the tab where it was . So I either did not understand how this works or something went wrong and the system is not running in RAM.

[qstateless]

@Bob3 - Good to hear that the “Boot to RAM? (y/n)” prompt is showing up for you now.

Your stateless system is likely working now and there’s probably just a slight misunderstanding on how the system works…

If your personal qube was created in the Normal Persistent mode, then it will save anything written to it on your storage drive, even while using that personal qube during Stateless mode.

With the Qubes Stateless implementation, it is specifically the Dom0 environment that runs in RAM.

Your storage drive will still be accessible and writable, along with any pre-existing TemplateQubes, AppQubes, data files, etc that were created in the Normal Persistent mode.

Any AppQubes you create purely while in Stateless mode using the “varlibqubes” storage pool will only exist in RAM and be fully gone and wiped after restart, along with their data fully gone and wiped, unless you otherwise persistently save such data somewhere else (like a persistent “save” qube) while in a stateless session.

If you don’t want any changes saved within an AppQube, then you likely need to consider creating such qubes while in Stateless mode using the “varlibqubes” storage pool, which places them within Dom0 while running in RAM, which is fully wiped upon restart. Note the RAM-based storage space for “varlibqubes” is only limited to your free Dom0 memory.

The current implementation of Qubes Stateless is a “hybrid” environment, where Dom0 is running in RAM but what pre-exists on your storage drive is still accessible and writable (including any persistently created qubes). This is different than a full blown Qubes Live system, where everything is non-persistent in RAM by default for Qubes Live. There are some tradeoffs to each type of system, Qubes Stateless vs Qubes Live, but with some strategic configuration, you can likely make Qubes Stateless act how you want it to.

More info on these topics has been previously explored somewhat throughout this thread.

Feel free to ask further questions and provide further thoughts.

[Bob3]

Thanks a lot for replying so quickly.

As far as I understood then I can create a “stateless qube” using “varlibqubes” storage pool while using the non stateless mode, set it up as I wish and them use the qube for daily work, everything that was done in that qube will be deleted at reboot every time I boot into “stateless mode”.

Did I understand correctly?

[qstateless]

@Bob3

Thanks a lot for replying so quickly.

As far as I understood then I can create a “stateless qube” using “varlibqubes” storage pool while using the non stateless mode, set it up as I wish and them use the qube for daily work, everything that was done in that qube will be deleted at reboot every time I boot into “stateless mode”.

Did I understand correctly?

@Bob3 - Cheers… I believe you are correct.

I haven’t personally made use of that approach, but I think it should work.

My understanding…

• 1. Create work qube using “varlibqubes” storage pool in Normal Persistent mode. This work qube will persistently exist as a file-backed qube in Dom0 within /var/lib/qubes.
     
     
• 2. Boot into Stateless mode. The work qube and its persistent files/configurations will load just as they were in your last Persistent mode session, but in RAM during your Stateless mode session.
     
     
• 3. Shutdown Stateless mode. Any and all changes in the work qube will be fully wiped and it will entireley revert back to its previous state from before your Stateless mode session began.

The “varlibqubes” storage pool is a file-backed (stored as traditional files) in Dom0 within the /var/lib/qubes directory. Since Dom0 loads into RAM during Stateless mode, all your file-backed qubes that use “varlibqubes” should not be able to persist any state from their operations in Statless mode.

A small caveat: If that work AppQube is based on a persistent TemplateQube and that persistent TemplateQube is updated or changed while in Stateless mode, then those TemplateQube changes will persist for all qubes that use this template, including the “stateless” work qube. However, template updates/changes usually are only for application packages, where your “Home” folder’s data files and app configurations should not be affected in the work qube itself. You can go deeper and customize just about anything to work non-typical in Qubes OS, but typical use of TemplateQubes should not likely interfere with your “stateless” work qube plans.

Different combinations of when, how, where you create & use various types of qubes & data can have different state outcomes. So, yeah, Qubes Stateless is an “advanced hybrid state system” like that.

Testing and confirming your expectations is always the key!

Hope that is clear and helps.

[qstateless]

To those interested in fully stateless (anti-forensic) use of Qubes Stateless, this is an important update.

@Bob3 et al…

I did some further digging into and testing of Qubes Stateless operations.

It seems there are some lingering issues & caveats with achieving fully stateless (anti-forensic) use of Qubes Stateless.

1. Dom0 Still Swaps to Storage Drive

More info here on Wikipedia for those not familiar with what swap is.

It appears that Dom0 Swap is still enabled with each system restart, and that @xuy’s recommended command sudo swapoff -a in post #18 for turning off Dom0 Swap is only temporary for any given Persistent mode session or Stateless mode session, but doesn’t last beyond restart (or maybe even a logoff?).

@xuy

And that is true, tmpfs can be swapped to disk. Therefore the swap desirable to be disabled. If you leave the swap enabled, some 𝚝𝚖𝚙𝚏𝚜 (root fs) data may be saved on swap. This data may contain a names of your AppVMs and other 𝚌𝚘𝚗𝚏𝚒𝚍𝚎𝚗𝚝𝚒𝚊𝚕 𝚒𝚗𝚏𝚘𝚛𝚖𝚊𝚝𝚒𝚘𝚗.

The simplest solution:

sudo swapoff -a

No swap, no problem.

We need to come up with a persistent way to disable Dom0 Swap. I haven’t researched this yet.

In the meantime, you should run the temporary command in the Dom0 Terminal at the beginning of every new Qubes Stateless session…

sudo swapoff -a

2. AppQubes Typically Created in ‘varlibqubes’ Still Partially Using Storage Drive

While testing in Qubes 4.2-RC4, I discovered that creating an AppQube that is based on a TemplateQube and setting the storage pool to ‘varlibqubes’ stores everything in Dom0’s /var/lib/qubes directory, EXCEPT for one thing I’ve found…

Running in Dom0 Terminal:

lsblk

lsblk | grep YOURQUBENAME

…reveals that your AppQube is still storing its ‘root’ volumes on your storage drive.

Here, you can clearly see volumes named ‘qubes_dom0-vm--YOURQUBENAME--root--snap’.

These ‘root’ volume can write sensitive data during your Qubes Stateless session to your persistent storage drive, which could potentially be recovered from the storage drive.

For a fully stateless workaround with AppQubes, see the approaches in “4. Workarounds for Fully Stateless AppQubes & DisposableQubes”.

3. DisposableQubes in Stateless Mode are Typically Not Fully Stateless

You should be aware that typical default configurations of DisposableQubes while in Stateless mode are not fully stateless and store their data on your storage drive.

For a fully stateless workaround with DisposableQubes, see specific approah “c” in “4. Workarounds for Fully Stateless AppQubes & DisposableQubes”.

4. Workarounds for Fully Stateless AppQubes & DisposableQubes

Thankfully, there seems to be a fully stateless workaround for the issues I described in “2. AppQubes Typically Created in ‘varlibqubes’ Still Partially Using Storage Drive” and “3. DisposableQubes in Stateless Mode are Typically Not Fully Stateless”, although quite costly in some RAM space…

You can take a few different approaches to resolve this fully stateless issue now:

• a. Instead of using AppQubes based on TemplateQubes, you could alternatively create StandaloneQubes in the ‘varlibqubes’ storage pool, which appear to store ALL data in traditional image files within Dom0’s ‘/var/lib/qubes’ directory. This is very costly in Dom0 RAM, as it copies your entire TemplateQube’s OS into Dom0 RAM space for each StandaloneQube you make, whether it is actively running or not, which is usually multiple extra GBs per qube, in addition to the RAM it takes to store any user files and the RAM it takes to run and operate the qube’s OS & apps.
  
  
• b. You could create a new TemplateQube from the previous TemplateQube you want to use, but store that new TemplateQube in the ‘varlibqubes’ storage pool. Then create a new AppQubes based on this new TemplateQube, and store this new AppQube in the ‘varlibqubes’ storage pool too. Now, when you use this new AppQube, it appears to store ALL data in traditional image files within Dom0’s ‘/var/lib/qubes’ directory. This is as costly as the other method for the first AppQube, but you do not have to copy & store the entire TemplateQube OS root filesystem for every AppQube you want to make with it, so this saves a lot of RAM space for using more than one qube.
  
  
• c. Like “b”, you could create a new TemplateQube from the previous TemplateQube you want to use, but store that new TemplateQube in the ‘varlibqubes’ storage pool. Then create a Disposable Template by creating new AppQubes based on this new TemplateQube, and store this new AppQube in the ‘varlibqubes’ storage pool too. After creation, in the settings of this AppQube, under the “Advanced” tab, you can check to turn on “Disposable template” and after applying also select “Default disposable template” to either be “(none)” or that very same AppQube itself. Now, you can use both this TemplateQube and Disposable Template AppQube to create new AppQubes and DisposableQubes fully within the ‘varlibqubes’ storage pool. This is likely to generally be the most desirable approach for most people.

Here is an example implementation of approach “c”:

Let’s say you want to base some of your fully stateless qubes on the ‘debian-12-xfce’ persistent template.

• 1. In Persistent mode: Create & Configure a new TemplateQube named ‘debian-12-xfce-stateless’ based on ‘debian-12-xfce’ and choose to store it in storage pool ‘varlibqubes’ (Advanced tab).
     
     
• 2. In Persistent mode: Create & Configure a new AppQube named ‘debian-12-xfce-stateless-dvm’ based on ‘debian-12-xfce-stateless’ and choose to store it in storage pool ‘varlibqubes’ (Advanced tab).
     
     
• 3. In Persistent mode: After creation, for the AppQube ‘debian-12-xfce-stateless-dvm’, change the ‘Advanced’ tab setting ‘Disposable template’ to be checked as turned on (click Apply), then the ‘Default disposable template’ to either be ‘(none)’ or ‘debian-12-xfce-stateless-dvm’ itself.
     
     
• 4. In Persistent mode: Create & Configure any new AppQubes based on ‘debian-12-xfce-stateless’ that you want to exist across multiple stateless boot sessions and choose to store them in storage pool ‘varlibqubes’ (Advanced tab).
     
     
• 5. In Stateless mode: You are free to now use any AppQubes based on ‘debian-12-xfce-stateless’ and DisposableQubes based on ‘debian-12-xfce-stateless-dvm’, which appear to remain fully stateless by storing ALL data in traditional image files within Dom0’s ‘/var/lib/qubes’ directory (that directory gets wiped and reset back to match the state of your last persistent session once your stateless session is powered down).

One may need to think about re-creating more or all of their system’s various types of qubes to be fully stateless like this, if needing such levels of statelessness. It should be possible to make every single qube on one’s system be fully stateless in ‘varlibqubes’ storage pool.

With higher fully stateless RAM space demands, you may need a computer with higher amounts of hardware RAM and an increase to the ’ dom0_mem=max:10240M’ setting in my Qubes Stateless step-by-step instructions to be set meaningfully higher than ‘10240M’.

5. The Pull Out Method

One approach I experimented with last year was to boot from a USB drive, and once Qubes Stateless was at the login screen, I just pulled out the USB drive, and the system seemed to continue working fine.

I haven’t done further testing on this approach yet, but it could be a powerful hardware enforced method for ensuring you are fully stateless.

@qstateless

When booting the drive with write access, I was able to pull out the USB drive once Dom0 booted up to the user login screen, seemingly without encountering any unexpected errors after that.

Qubes Stateless is an advanced hybrid state system, so controlling your level of statelessness can be a complex thing to manage, if desiring to be fully stateless.

Feel free to ask questions and provide further thoughts.

[qubesuser1234]

Hey thanks you !! Your script is working correctly without trouble

[qstateless]

You’re welcome @qubesuser1234. Glad it’s working out for you and others. Awesome that you’re running a stateless Qubes OS Dom0 now! Super thanks to @xuy!

A couple updates to come soon. Stay tuned.

[qstateless]

Hi @deeplow and @gonzalo-bulnes - It looks like we are beyond 30 days now, but I was hoping to update my step-by-step instructions post to make some important changes for anyone relying upon the post.

Is there anyway my account can be adjusted so I can edit that post beyond the 30 day limit?

Rather than continually “spamming” this thread with new big, long, repetitively new step-by-step instruction posts whenever there may be an instructions update, it seems more clean & correct to be able to edit the single instructions post and then make a brief notification/explanation post with a link to the “canonical” instructions post for those who may be further interested.

Thanks!

[gonzalo-bulnes]

I made that post a wiki, does that help @qstateless ?

Would it be worth splitting the topic so that it becomes a guide on its own (still a wiki, but as the first post of its own topic)?