You just have to write a second script like this […]
In XFCE I simply create desktop launchers with the command calling the script directly like this:
ram-qube -p template=... -p netvm=... -p -c ...
When ram-qube (or whatever name you use for the script) has exec permission for the user, there is no need to call it with bash ram-qube.
The cleanup script should be run in dom0 console.
Updated.
script 1: improved checks, now pool names match custom qube name (e.g. ram_pool_myqube).
script 2: now finds more logs, added qube name colorization in log file paths.
Updated ram-qube script:
New feature: automatic label based on netvm value. Custom label is still possible.
Added process locking to prevent 2+ instances trying to create the same qube.
For those of us coming in late here, where can the (updated) scripts be accessed?
the OP has all the final edits, just scroll to the top.
On the top right you can also click the pencil and see the edit history, right next to the age of the post.
Thanks, but I’m not sure that is ideal, particularly for someone coming in here at a later date. Suggest this get added to a github page somewhere and linked?
Thanks, but I’m not sure that is ideal, particularly for someone coming in here at a later date.
The ideal thing is to have a checkbox “Run qube entirely in RAM” and not have to deal with any of this. 
As for the code, it is easier to see the actual thing first when opening the thread, rather than try to find the latest version among many posts.
Suggest this get added to a github page somewhere and linked?
If necessary, this will happen some day. To avoid making any mistakes myself, for the moment, it is just a forum thread.
Updated.
Fixed a bug with auto labeling (it used to fall back to red).
For me, everything works perfectly with your new scripts. The fact remains that rdispXXXX is not disappearing from the ram if it is not closed BEFORE the laptop is closed and ram_pool_rdispXXXX stay “alive”.
Do you think there might be a way to “tell” Dom0 to turn off the rdispXXX BEFORE shutting down? Something to edit directly in a Dom0 file that has nothing to do with your script… To be honest, I don’t know the Closing Procedure of qubes-os at all 
I’m not sure to be clear! lol
I tried to create a service linked to a bash script waiting 8s before shutdown the computer in dom0 like this :
sleep 8
qvm shutdown --quiet --force X-ram-qube
But this doesn’t work when i reboot my computer the ram qube script didn’t clean and delete the ram qube even if you tell to your system wait 8s before shutdown. The clean aspect of qubist script is only working if you manually shutdown every ram qube before shutdown your computer. I don’t know if you will understand what i’m saying sorry english is not my first language 
Like me 
When I want to shut down my computer with a shutdown -h, I put a shutdown -h in the rdispXXXX and in dom0 with an extra minute. Sometimes it work sometimes not. I think it must depend on the number of AppVMs to be shut down before Qubes-OS shuts down (more or less time)… And in our case, as is directly in the ram, it doesn’t turn it off.
Anyway, I think delaying the shutdown of Qubes-OS by just a few seconds is useless.
Don’t you want to put the sleep command AFTER shutting down the qube?
Oh nice idea ! Thanks you i didn’t think about that i will try this and give some feedback 
EDIT : It’s not working. I’ve tested to add "systemd-inhibit --why=“Wait for this script to finish bash script.sh” it’s not working too. The script don’t clear anything when the system shutdown. By the way i think it’s just impossible like qubist said the script itself cannot do that. When the system shutdown my script (qvm-shutdown --force X-ram-qube) close every ram qube and that’s all. The script is not waiting for clear events…
Your specific issue is not something the script itself can (or should attempt) to fix.
The fact remains that rdispXXXX is not disappearing from the ram if it is not closed BEFORE the laptop is closed and ram_pool_rdispXXXX stay “alive”.
The question is what exactly happens when you close the lid. Does the laptop go into sleep/hibernate? Does it shutdown? If it shuts down, everything disappears from RAM (even if remnants remain on the file system).
To my (non-expert) mind, you have 2 options:
qvm-kill for all RAM qubes at specific power state events (standby/shutdown). Maybe acpid could help you with that, however, that would require installing the package in dom0 and running the service.or
Another possibility is to use a named RAM disposable. This way, you will always have the same name for logs and pool, which would at least save you some confirmations when you use the cleanup script after rebooting.
Perhaps you could open a separate thread where others may suggest how to approach this. As soon as you find a solution, feel free to share a link to it.
What is the purpose of the sleep command?
If the idea is to prolong the shutdown process, thus allowing the script to complete, that may not work for reasons like:
You don’t know when and how the OS terminates various processes. It may kill the sleep just like any other command.
Even if the OS waits for that particular sleep, that is just a delay before or after the qvm-shutdown. It does not give additional time to the qvm-shutdown process itself, or the cleanup process after it (which is the actual goal).
To control the shutdown process you need a process with proper conditions and permissions.
In /usr/lib/systemd/system/qubes-core.service you can see that the OS will shutdown all qubes, so there is no need for additional script doing that:
ExecStop=/usr/bin/qvm-shutdown -q --all --wait
If this works as expected, then right after the RAM qube receives the shutdown signal, it will continue with the cleanup procedure and complete it. The big question is: will the OS wait for that too?
AFAIK, on shutdown, systemd sends SIGTERM to all processes (asking them to end gracefully), waits for some time, then kills them forcefully through SIGKILL. The script traps the SIGTERM but it is not possible to trap the SIGKILL. So, it all comes down to what happens after the RAM qube shuts down.
IOW, if you create a custom service, it should rather have an ExecStop sending a SIGTERM to the script itself (e.g. ExecStop=/usr/bin/kill <path-to-script>/ram-qube) with proper timeout and making sure this service is not blocked by something with a higher priority.
Yes it was the idea !
He’s not waiting for cleaning anything even with the sleep command. I tried to prolong the shutdown process by 60 s it’s doesn’t work. The system is only waiting for shutdown qube that’s all not for cleanup ram qube process.
I don’t understand why the shutdown process don’t read the cleanup ram qube process it look like shutdown process ignore that
Hi @qubist
Sorry if I wasn’t specific enough, english is not my first language, I wanted to say, when my laptop is shutdown.
I tried to create a.service to terminate the script with the command ExecStop=/usr/bin/kill <path-to-script>/ram-qube, it seems that during the shutdown, qubes fails to umount the rdispXXX, so the qvm-pool command cannot delete the ram_pool_rdispXXXX file because rdispXXX is always mounted in the tmp/ folder. (what is strange because volatile.img as disappear but rdispXXX is always present in the qubes-manager 
)
So to sum up:
qvm-pool remove doesn’t work, so file ram_pool_rdispXXXX isn’t remove at reboot.Precision: I’m not an expert or a programmer or anything else. I just try to help and to find to give some leads because i’m a fan of qubes-os if you want i shut up or if what i say doesn’t help you, just tell me and i will…
- it seems umount command fails so
qvm-pool removedoesn’t work, so file ram_pool_rdispXXXX isn’t remove at reboot.
As you can see in the script itself, it works the other way around:
qvm-pool remove ...sudo umount ...so umnounting does not prevent pool removal. You need to dig deeper. Did you open another thread to understand the shutdown process and how to do what you want? That may attract the proper experts to explain how to do it.
- at reboot, volatile.img as disappaer but dispXXXX is always in qubes-manager.
Everything in a tmpfs mount disappears on unmounting. That’s part of the idea of having it in RAM.
Precision: I’m not an expert or a programmer or anything else.
Neither am I.
@Tezeria, I have something that might work for you.
This is how you can create a regular but still RAM based disposable:
In dom0, add the following line to your /etc/fstab (size is up to you):
tmpfs /ram_pool tmpfs mode=1777,strictatime,nosuid,nodev,size=5G 0 0
It will create a global RAM drive mount on each boot.
Then, after having that mounted, add a pool:
user@dom0:~ > qvm-pool add ram_pool file --option revisions_to_keep=1 --option dir_path=/ram_pool
This pool will be preserved across reboots too.
Then, just create a regular named disposable in the traditional way, just remember to click the Advanced tab and set Storage pool to ram_pool.
Now you have a RAM based disposable which will shutdown correctly like any other qube. You can remove it’s remnants with the second script if you need that. If you don’t - no problem. After rebooting, you will simply have a clean RAM pool which you can use for other things.
What other things?
It seems to me this can be used for having sys-* disposables in RAM (with enough RAM and a big enough ram_pool), thus probably having gaining performance and saving the SSD from writes (with disabled swapping).
This is also a convenient way to have very fast “Open in VM” with named disposables which auto start on boot.
WARNING: I am not aware whether this may have any security consequences due to the fact that many VMs can run on the same pool. I don’t think there should be any, since all other qubes do run on the same pool too, just on persistent storage. This still needs to be confirmed by an expert though (which I am not).
Hi @qubist thanks for all your time you put into this RAM VM project.
Indeed, it would be nice if a Qubes Pro could go through your script, your previous post and comment or verify your work.