Appmenu entries dupplicated for disposable

I want to use a disposable VM for certain web browsing. I followed Creating a new disposable template which works except for one annoyance: All the entries in the application menu are duplicated, which is driving me nuts.

Firefox (2)

But in the qube settings, there is only one entry.

This is not the case for the sys-* disposables I created (same documentation linked above, but further down below).

What is causing that duplication, and how can I get rid of it?

Never saw this issue.

What might fix it, is refreshing the menu:

In your dom0 run:

qvm-sync-appmenus $NAME_OF_DVM_WITH_DUPLICATES

No, running qvm-sync-appmenus does not solve the issue.

Meanwhile, I also figured the difference between the two entries. The first one (Firefox) runs Firefox in a disposable VM. The second one (Firefox (2)) runs Firefox in the template VM itself.

This explains things to me, but still, this is a confusing user experience. Is there a way to make this more obvious (which entry does what)?

Ah i see!

Maybe you could share with us what menu you use?

IIRC in the normal xfce-menu the first entries would start the disposable while the last ones would start the template itself.
Also there was a difference for the icons.

You can set the icons with qvm-prefs $QUBE icon $ICONNAME but i am unsure on how this is handled internally with the specific menu entries.

I do experience the same problem as you in my rofi menu.

For me the best way would be to simply delete the entries for the templates completely. If i want to launch them, i will by other means.

I have to admit, that i am a noob in menu stuff and .desktop files but will look into it now to customize my menu.

Here is what i know:

  • Menus read the .desktop files.
  • My menu is Rof

Following is what i did to figure out this problem. Maybe it helps some new to linux users with their problem solving. If you are only interested in the solution and not the path to it, feel free to skip to the end.

I have located the .desktop files by utilizing sudo find -iname "*.desktop" | less in the root dir of dom0.

The list was long, but i was able to visually spot locations where many .dekstop files are located.

The one promising location i was able to quickly detect was /home/$USER/.local/share/qubes-appmenus/$QUBE_NAME/apps/

Taking a look at the entries that are problematic to us: dvms.

Here is the content of home/$USER/.local/share/qubes-appmenus/whonix-ws-16-dvm/apps/ by issuing ls -1 on that location.


So one can see, that there are duplicate entries for:

I highly suspect the dispvm is for the dispvms and the vm is for the dvm-template.

The content of those files look like this:

Name=whonix-ws-16-dvm: Tor Browser Downloader (AnonDist)
GenericName=whonix-ws-16-dvm: Download Tor Browser
Comment=Download Tor Browser (AnonDist)
X-Qubes-NonDispvmExec=qvm-run -q -a --service -- whonix-ws-16-dvm qubes.StartApp+anondist-torbrowser_update
Exec=qvm-run -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+anondist-torbrowser_update

This leaves us with a few options. I would prefer to not see them at all, so i would delete all vm entries in the folders of my dvms. A less destructive approach would be to rename them from $NAME.desktop to $NAME.desktop.old. This didn’t do the trick for me.


I can think of three possibilities:

  1. Rofi caches the menu entries
  2. Rofi reads all files in the location regardless of file type
  3. I am at the wrong place

So i changed the icon of tor browser to the icon of systemcheck for the dvm entry without success.

I suspect that i may be in the wrong place so i searched for a specific .desktop file with sudo find / -name "org.qubes-os.dispvm.whonix-ws-16-dvm.janondisttorbrowser.desktop"

There are the following placed that file exists:

  • /home/$USER/dom0-home/... This is an old dom0-home from an backup.
  • /home/$USER/home-restore... Don’t know what this is, but seems like something backupish
  • /home/$USER/.local/share/qubes-appmenus This is where i tried
  • /home/$USER/.local/.gnome/apps/... Don’t know what that is, but i don’t use gnome
  • /home/$USER/.local/share/applications Looks the most promising now.

For testing i changed the icon of my dvm torbrowser by commenting out the line and adding the one from the system settings .desktop:

[Desktop Entry]
Name=whonix-ws-16-dvm: Tor Browser (AnonDist)
GenericName=whonix-ws-16-dvm: Privacy Browser
Comment=Start Tor Browser (AnonDist)
X-Qubes-NonDispvmExec=qvm-run -q -a --service -- whonix-ws-16-dvm qubes.StartApp+janondisttorbrowser
Exec=qvm-run -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+janondisttorbrowser

I can see the new icon in my menu now, so i am definitively in the right place and there is no caching.

So i reverted the change and moved the dvm .desktop to .desktop.old.

The duplicate menu entry is gone now

To see if this change would be persistent i run go to the qube manager gui and click “refresh applications”.

This does not revert my changes, nor does running qvm-sync-appmenus whonix-ws-16-dvm.

What does revert the change, is if i remove the entry in the settings, save, add it again, save.

Taking another look at the .desktop file i see other possibilities than deleting or renaming, that may be more persistent:

  • Changing the icon
  • Setting another name

I tried removing any references to the word “whonix” of the desktop but kept the Exec lines. I can still find the entry when searching for whonix.


To remove the duplicate menu item for the dispvm-templates from your menu, rename the /home/$USER/.local/share/applications/org.qubes-os.vm.$QUBE_NAME.$APPLICATION.desktop to the same name + .old

This will remove the entry that launches the application in the template of your disposable, so only the actual disposable menu entries remain.

To launch the application in the template, you need to launch it via command line. Or revert the change.

This is my preferred solution, maybe changing the icon in this file is better suited to your use case.

May break stuff for you, for me it does not.
May be a sub optimal solution.
May not be persistent.

1 Like

Yes, rofi is the right keyword here. And yes, ~/.local/share/applications is where the menu entries are kept. Editing those files is safe as long as you only add new items to the appmenu. Removing an entry, does also delete the corresponding *.desktop files on dom0, which is fine I guess.

If you use rofi's drun mode, you can simply add Hidden=true to the corresponding .desktop files to hide them from rofi’s search results.

I wrote a small bash script that adds the Hidden=true entry to the end of all .desktop files belonging to a dvm-template that also has dispvm .desktop files inside ~/.local/share/applications:

set -e

cd ~/.local/share/applications/


escaped_disp_vm_prefix=$(echo $disp_vm_prefix | sed 's/\./\\./g')
escaped_dvm_template_prefix=$(echo $dvm_template_prefix | sed 's/\./\\./g')

vms=$(ls "$disp_vm_prefix"*.desktop | sed "s/$escaped_disp_vm_prefix\([^\.]\+\).*/\1/g" | uniq)

for vm in $vms; do
	for desktop_file in "${dvm_template_prefix}${vm}."*.desktop; do
		if [ -f "$desktop_file" ]; then
			if ! grep -q "Hidden=true" "$desktop_file"; then
				echo "Hidden=true" | tee --append "$desktop_file" >/dev/null
				echo "Hid $desktop_file (belonging to $vm)"

Very basic, but it gets the job done. You can also put it inside a cron job and run it every minute. Not ideal but probably sufficient in most situations. A less hacky solution would be better though.

1 Like