@qubist
Thank you for your quick feedback. I have been using Qubes since 2012, but I don’t know what you mean by OP. I’m sorry that I have to ask you again.
1 Like
OP = original post. If you scroll to the top you will find the updated script.
If you click the pencil icon on the top right next to the date you can also see the edits the page has gone through.
2 Likes
@hypercube
Thank you for clarifying this.
1 Like
Is the cleanup remnants script and just removing remnants in general still working after 4.2? When I close a ram based qube it says remnants cleared but I still see an entry in /.config/menus/applications-merged/. Also when running the cleanup script it spams me with a bunch of Qube user-qubes-dispvm-directory_rdispXXXX does not exist No files found. Did I delete something I shouldn’t have or is this working as intended?
1 Like
I have just upgraded to 4.2 and I am still re-configuring things, so please give me some time.
Is the cleanup remnants script and just removing remnants in general still working after 4.2?
Generally, it seems to work.
When I close a ram based qube it says remnants cleared but I still see an entry in /.config/menus/applications-merged/.
Noted.
Also when running the cleanup script it spams me with a bunch of Qube user-qubes-dispvm-directory_rdispXXXX does not exist No files found.
Same here. In my TODO list.
Did I delete something I shouldn’t have or is this working as intended?
I have not looked into it yet but if no files are found, there is just nothing to delete. As a whole, the script is made to confirm every single deletion explicitly.
Stay tuned for updates (but don’t hold your breath).
2 Likes
Earlier I wrote:
And if the pool stores more than one volatile volumes (general case), then having the pool with ephemeral_volatile=True will make all these volatile volumes ephemeral.
and you confirmed:
That’s right.
I have some questions in regards to that:
Scenario:
Two VMs - A and B.
Volumes A:volatile and B:volatile are in the same pool.
That pool is configured with ephemeral_volatile=True.
- Does that mean both volumes will be encrypted with the same ephemeral key? If yes, what are the security implications of that?
I am trying to evaluate if there is any actual (not theoretical) security benefit from having a separate pool for each volume or all can reside in the same pool.
The other thing is:
I notice that usage of the volatile volume of any AppVM always increases when the VM is in use, regardless of the ‘rw’ flag being set to the root volume or not. IOW, it seems to me that there is no actual difference between rw=True and rw=False.
- So, what is the point of setting rw=False for the root volume? And of what use is that flag at all, considering the above?
When the volatile volume is on tmpfs, it actually resides in dom0’s RAM. This means the VM, to which it belongs, writes to dom0’s RAM and reads from it (of course, not in the direct sense, but the point is - this still happens there).
Might there be any security implications as a result of that? If yes - what exactly?
1 Like
I have updated the main script and the cleanup one to work correctly in 4.2. Sorry for the slowness, too much work recently.
Let me know if everything checks.
3 Likes
Everything appears to be working great, just have to be careful not to delete desktop right click menu entries that still exist. For example:
Delete /home/xxxxx/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu shows up even though the actual vm is named personal-dvm and deleting it removes the desktop right click menu entry.
Thanks for taking the time to update this.
1 Like
Everything appears to be working great, just have to be careful not to delete desktop right click menu entries that still exist.
Hm. I don’t quite understand.
Desktop shortcuts are named *.desktop, not *.menu.
Or what right clicks do you mean?
1 Like
No. ephemeral_volatile really doesn’t do anything more than set the default value for the ephemeral property of ‘volatile’ volumes in the pool, and ephemeral volumes do not share keys with each other (no matter whether they are in the same pool or not, or what mechanism was used to set the property).
That’s expected, because the ‘volatile’ volume is also used for in-VM swap.
1 Like
That’s expected, because the ‘volatile’ volume is also used for in-VM swap.
In my particular case it is unexpected because I have disabled swap (through vm.swappiness=0) and I can see that free shows 0 bytes of swap used. Considering this, what adds to the ‘volatile’ volume?
1 Like
I mean the application menu that shows up when you right click the desktop and go to applications. If I delete /home/xxxxxx/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu it removes the qube entry from the applications menu that shows up when you right click the desktop. Is it supposed to be listed as personal_ddvm even though the vm is called personal_dvm?
1 Like
Meant to say the qube is called personal-dvm. Since it said personal_dvm doesn’t exist I tried renaming it. It seems if I rename the qube to personaldvm it no longer says it doesn’t exist.
Edit: Sorry for not editing the previous post just realized my browser was hiding the edit icon.
1 Like
If I delete /home/xxxxxx/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu it removes it from the applications menu that shows up when you right click the desktop.
I think this is expected.
Is it supposed to be listed as personal_ddvm even though the vm is called personal_dvm?
I am reading this as 2 different names: _ddvm and _dvm. See which one of these qubes you actually have. If any of them does not exist, see if the cleanup scripts removes its .menu files. If it doesn’t, please provide exacts steps to reproduce, so I can test locally.
1 Like
The qube that I have is called “personal-dvm”. This is a functioning qube and not a left behind entry. It comes up as personal_ddvm when I run the script, and deleting this removes the qube I still have from the application menu that comes up when I right click on the desktop. If I get rid of the “-” and name it “personaldvm” it no longer says that it doesn’t exist when I run the script.
Its not that its failing to remove files from qubes that don’t exist, its that it is removing application menu qube entries for still existing qubes unless they are named as one word from what I can tell. I did a clean install when I updated to 4.2 and restored everything from a backup except for dom0. I can reproduce this by making an app qube based on fedora 38 with no net vm(not sure if this matters). For example if I make a qube named “a-my-new-qube” it shows up when I run the script as “a_dmy_dnew_dqube” and selecting yes deletes it from the application menu on the desktop (but not the top left corner menu) even though the qube still exists.
1 Like
For some reason the menu shortcuts convert every dash to “_d” in 4.2. They didn’t do that in 4.1, and this unexpected (and inexplicable) change bit me in the hindquarters, hard, when I upgraded.
2 Likes
My test:
user@dom0:~ > qvm-create personal-dvm --label red
user@dom0:~ > find ~ -regextype posix-egrep -regex '.*personal(.*)dvm.*'
/home/user/.local/share/desktop-directories/qubes-vm-directory_personal_ddvm.directory
/home/user/.local/share/qubes-appmenus/personal-dvm
/home/user/.local/share/qubes-appmenus/personal-dvm/apps.icons
/home/user/.local/share/qubes-appmenus/personal-dvm/apps.icons/firefox.png
/home/user/.local/share/qubes-appmenus/personal-dvm/apps
/home/user/.local/share/qubes-appmenus/personal-dvm/apps/qubes-vm-directory_personal_ddvm.directory
/home/user/.local/share/qubes-appmenus/personal-dvm/apps/org.qubes-os.qubes-vm-settings._personal_ddvm.desktop
/home/user/.local/share/qubes-appmenus/personal-dvm/apps/org.qubes-os.vm._personal_ddvm.firefox.desktop
/home/user/.local/share/applications/org.qubes-os.qubes-vm-settings._personal_ddvm.desktop
/home/user/.local/share/applications/org.qubes-os.vm._personal_ddvm.firefox.desktop
/home/user/.gnome/apps/org.qubes-os.qubes-vm-settings._personal_ddvm.desktop
/home/user/.gnome/apps/org.qubes-os.vm._personal_ddvm.firefox.desktop
/home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu
user@dom0:~ > qvm-remove personal-dvm
This will completely remove the selected VM(s)...
personal-dvm
Are you sure? [y/N] y
user@dom0:~ > find ~ -regextype posix-egrep -regex '.*personal(.*)dvm.*'
/home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu
My understanding of the result:
It seems Qubes 4.2 has changed something in the naming of qubes and the corresponding files. I am not 100% sure but I think in 4.1 using ‘_’ in names was not possible. If I am wrong, then the change is in corresponding file names only. In any case, the fact that after removing the qube a .menu file with a modified name remains is a bug in Qubes.
Even so, my cleanup script removes the leftover successfully:
user@dom0:~ > remove-qubes-remnants
WARNING!!!
This script searches for remnants of ANY non-existing qubes.
You will be asked to confirm each change individually.
Be careful and think twice before confirming anything!
You have been warned.
If there are no remnants, you will not have to do anything.
Continue?
Yes/No/Quit? y
Checking for unused RAM qube pools
Finished checking for unused RAM qube pools
Checking for files with no corresponding qubes
Qube personal_ddvm does not exist
Delete /home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu: Yes/No/Quit? y
Finished checking for qube file remnants
Done
Additionally, I checked and I don’t notice any leftover .menu files from RAM-based qubes, which means the ram-qube script also works as expected.
Summary:
I don’t see an issue in my scripts. I see they actually clean-up issues existing because of Qubes bugs (which I have reported).
Let me know if you think I am missing something.
2 Likes
My issue isn’t that the script doesn’t remove remnants from qubes that no longer exist. What happens is I have “personal-dvm” and thats a qube I still use and haven’t deleted. Now I normally launch my qubes by right clicking the desktop, going to applications and selecting say firefox from personal-dvm. Now when I run this script it says that qube “personal-dvm” doesn’t exist (when it infact does exist and should) and if I chose to erase it’s .menu entry it removes the entry from that applications menu that I use to launch my qubes and their programs. This qube is still in the qube manager and should be as I don’t want to delete it. Should this be happening for qubes that exist? My understanding was that the script was meant to remove remaining files, logs ect for qubes that do not exist anymore such as qubes that have been deleted.
1 Like
As I stated above the paths to menu entries now in 4.2) change any dash in a qube name to _d. The qube name itself doesn’t change, just the paths to your menu files.
So, for instance: org.qubes-os.vm-firefox-esr.xfce4-file-manager becomes org.qubes-os.vm_dfirefox_desr.xfce4-file-manager.
There’s obviously nothing wrong with dashes in a file name, but they made sure to do this hoop jumping with the name of the qube, that is part of this file name.
Very aggravating.
2 Likes
Now when I run this script it says that qube “personal-dvm” doesn’t exist (when it infact does exist and should) and if I chose to erase it’s .menu entry it removes the entry from that applications menu that I use to launch my qubes and their programs.
Aha! Now, I reproduced it.
This qube is still in the qube manager and should be as I don’t want to delete it.
The script gives you a choice.
Should this be happening for qubes that exist?
No. I will look into it. But this is very confusing.
My understanding was that the script was meant to remove remaining files, logs ect for qubes that do not exist anymore such as qubes that have been deleted.
It was and it still is. However, please note that the core reason for creating this script is the bug in Qubes: deleting a qube leaves files behind. This also results in files which remain after removing a RAM-based qube.
Now, when there is even more complexity and unpredictability in regards to the bug, this makes script maintenance more difficult. Just see what the actual situation is:
- Create these qubes
personal-dvm
personal_dvm
personal–dvm
personal__dvm
- Run the cleanup script:
user@dom0:~ > remove-qubes-remnants
WARNING!!!
This script searches for remnants of ANY non-existing qubes.
You will be asked to confirm each change individually.
Be careful and think twice before confirming anything!
You have been warned.
If there are no remnants, you will not have to do anything.
Continue?
Yes/No/Quit? y
Checking for unused RAM qube pools
Finished checking for unused RAM qube pools
Checking for files with no corresponding qubes
Qube personal_d_ddvm does not exist
Delete /home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_d_ddvm.menu: Yes/No/Quit? n
Qube personal_ddvm does not exist
Delete /home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_ddvm.menu: Yes/No/Quit? n
Qube personal_udvm does not exist
Delete /home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_udvm.menu: Yes/No/Quit? n
Qube personal_u_udvm does not exist
Delete /home/user/.config/menus/applications-merged/user-qubes-vm-directory_personal_u_udvm.menu: Yes/No/Quit? n
Finished checking for qube file remnants
Done
This means:
personal-dvm -> personal_d_ddvm
personal_dvm -> personal_udvm
personal--dvm -> personal_d_ddvm
personal__dvm -> personal_u_udvm
Without knowing what the logic behind the creative naming on the right is, I can only guess. However, if that changes from version to version, it practically creates a long term job.
What I am saying is: bugs in Qubes are not to be fixed by community scripts. We are not actually fixing the cause but the effect, which is super inefficient. So, you can contribute by reporting this on GitHub. File names must speak to the user in a clear consistent language.
I will still see what I can do but under the disclaimer that I cannot fix this in a reliable future-proof way.
2 Likes