Possible glitch in KDE menuing (and other menus too) for Qubes disposable templates

This may be KDE-specific, but I doubt it…since it involves putting VMs into the KDE menu.

If I create a new DVM template, this must be done in steps. First of course you must actually create the template, which (in salt) involves the qvm.present state.

Then preferences must be set, including “template_for_dispvms: true”

FInally, to get it to show up in menus as a disposable, you need to set features, in particular “qvm-features [vmname] appmenus-dispvm 1”

The problem is, when I do this, it won’t show up in the KDE menu as a disposable. Nothing I tweak afterwards will get it to happen.

I’ve even tried setting the feature before setting the prefs. Although the feature is still set after the qube is created, it refuses to show up in the menu as a disposable.

The only thing that works is to clone the VM. The clone will show up as a disposable, presumably because it’s being created with all of these flags set to begin with.

So in my salt recipes I’m doing something very clunky. Let’s say I want to create a dvm template named “Firefox-dvmt”. I instead run through those steps to create “Firefox-dvmt1” and then I rename it to “Firefox-dvmt” (and a rename is really a clone followed by a delete of the original, so this does the job).

Going through the Qubes manager, it’s even worse. There, of course you first create an appvm (without any way in that gui to tell it it’s going to be a dvm template), then you have to go into settings to turn on template for disposable VMs. (This does, at least, automatically set the appmenus-dispvm to 1 automatically.)

The KDE menu never shows it as anything other than an AppVM. (At least using salt, it showed up as a DVM template in the menu, you just never got the accompanying disposable menu entry.)

Again, this is “fixed” by renaming the VM.

What happens when you run

$ qvm-run dispvm=YOUR-"NOT-WORKING"-DVM-TEMPLATE-NAME --service qubes.StartApp+thunar

Absolutely nothing happens. No error message, no abortive start to the qube, nothing.

That’s true when I run it on a qube that shows up in the menu as a disposable, too. Is there possibly a mistake in what you asked me to try?

If I instead run qvm-run --dispvm [NOT WORKING TEMPLATE NAME] --service qubes.StartApp+thunar then both the "working’ and “non-working” qubes bring up thunar and both shut down when I close thunar (i.e., expected behavior of a disposable).

The KDE menu does not change (I was hoping this command would “kick” it into looking at that VM again and doing it right), nor does it show up correctly in the menu’s editor.

Nope. you know I emphasize when not reproducing something before suggesting. Both should run, at least they do with me.

So, you definitely have working “not-working”-dvm-template, and you are missing appmenu shortcut.

Did you reboot Qubes after creating “not-working-dvm-template”? If not, reboot and check.

If that doesn’t help, I’d try to create /home/user/.local/share/desktop-directories/qubes-dispvm-directory-NOT-WORKING-DVM-TEMPLATE-NAME.directory with the content

[Desktop Entry]
Encoding=UTF-8
Type=Directory
Name=Disposable: NOT-WORKING-DVM-TEMPLATE-NAME
Icon=dispvm-gray

and would reboot just in case and check what happens. Please note that I have no idea how things works with KDE, and this is my tip under Xfce.

You’d also have to try in addition to explore other related directories in /home/user/.local/share/ and to experiment to bring it to fully functional.

I’m claiming this is an issue with KDE at least as implemented for Qubes. It’s not recognizing a dvm template as being able to create disposables when the flag that should cause it to do so has been set.

Xfce advice is therefore moot.

Ok.

Repeating (with some clarifying edits) in the hope that @unman will see this:

This may be KDE-specific, but I doubt it…since it involves putting VMs into the KDE menu.

If I create a new DVM template, this must be done in steps. First of course you must actually create the appvm, which (in salt) involves the qvm.present state.

Then preferences must be set, including “template_for_dispvms: true”

Finally, to get it to show up in menus as a disposable, you need to set features, in particular “qvm-features [vmname] appmenus-dispvm 1”

The problem is, when I do this, it won’t show up in the KDE menu as a disposable. Nothing I could think of to tweak afterwards will get it to happen.

I’ve even tried setting the feature before setting the prefs. Although the feature is still set after the qube is created (I checked from the command line to ensure it wasn’t somehow going away, which would exonerate KDE), it won’t show up in the KDE menu as a disposable.

The only thing that works is to clone the VM. The clone will show up as a disposable, presumably because it’s being created with all of these flags set to begin with. It looks to me very much as though KDE is oblivious to changes to the appmenus-dispvm flag once the qube has had its preferences set.

So in my salt recipes I’m doing something very clunky. Let’s say I want to create a dvm template named “Firefox-dvmt”. I instead run through those steps to create “Firefox-dvmt1” and then I clone to Firefox-dvmt and delete Firefox-dvmt1. THAT will get Firefox-dvmt to show up in the KDE menu as a “disposable.”

Apparently (given my prior conversation in this thread with enmus) it works just fine in xfce, which matches my recollection from back before I switched.

I tried to create 2 different templates based dvm-templates and no entries in AppMenu and Whisker Menu anymore. In new application menu, there are directory entries, but app shortcuts side is empty.
Running disposables from terminal works as expected and explained above.

xfce4-settings-qubes.x86_64    4.0.5-2.fc32 
xen_version :   4.14.5
Linux:         6.0.12-1.fc32.qubes.x86_64
qubes-desktop-linux-menu.noarch:    0.3.0-1.10.fc32 
qubes-menus.noarch:     4.1.14-1.fc32

Maybe we should rename this topic’s subject… If not, I’ll open new one, just let me know.

If you’re saying that this isn’t just a KDE issue, then yes a rename is appropriate. Am I understanding you correctly?

(And yes the DVMs open up from the command line, that was never in dispute…which is why I figured it had to be an issue with the menu. I’m just surprised that it affects xfce because when I was using xfce, it worked.)

Meanwhile my workaround is to create the DVM template under a temporary name then copy/delete (adds up to a rename); that, for some reason, the menu picks up properly.

That has a side effect. Usually to update a qube’s software I just rerun my setup script which 1) creates the qube and 2) installs software on it. If the qube exists already, it just skips step 1). But with the rename, the qube doesn’t exist because what’s being created is the temporary qube. So it creates that and then fails when it tries to do the clone to the correct name, because THAT qube exists.

Yes it’x Xfce. Cloning helps. With fedora-36. It doesn’t help with fedora-37. But let’s assume it’s still testing. For fedora-37 qubes-shutdown-idle also doesn’t work. there’s no contrib qubes repo, etc, etc.
What is the most fantastic is that cloning, deleting original, then renamig the clone back to original also doesn’t work.

Just renaming it to anything else third, works!
Wow!
If this isn’t a bug (I never claimed one), then I don’t know what one is.

The workaround to this could be to create dvm-template to whichever name and then to clone to the name from your script.

Title changed!

Interesting, about XFCE. I originally “solved” my problem by starting with my working, but-non-menuing DVM template, renaming it to sometheing, then naming it back. That works for KDE, but you’re saying it isn’t working for xfce…interesting.

When I decided I’d have to automate things, I decided it was better to just do the rename once…so I created it with a name I didn’t want to be permanent. For example, let’s say I want to create a DVM template for firefox, and so I want it to be named Firefox-dvmt. I have changed my salt scripts to actually create Firefox-dvmt1, set the menuing flag, and so on, then rename it to firefox-dvmt. That’s my “create” script. The “configure” script installs the software on firefox-dvmt. With salt, if I want an update I can usually just run the two steps; I have that aliased. Since the qube already exists, the first step just says “Oh, goody, it’s already there, I’m done” [maybe it has to set some flags] and the second step does the software update. That works well for (regular) templates.

But that update strategy won’t work cleanly with this situation, a dvm template. The create script starts by creating firefox-dvmt1. Well, it doesn’t just say “I’m done” because when it looks to see if there’s a qube by the same name, there is no firefox-dvmt1…because I renamed it the last time. So it creates firefox-dvmt1, sets all those flags, then tries to rename it to firefox-dvmt. And it can’t do that because that qube (the real target of the update) exists, and always has. So when updating one of these guys, I have to remember to delete the old one first. I could probably automate that part too but for now I’ll just wait to see if there’s a fix coming. (I went through that whole explanation because it looked like you were suggesting I do what I’m already doing…maybe I misunderstood you.) The good news is, I literally have two (out of well over a dozen) DVM templates that need “updating” and that’s only because I haven’t switched to setting things up in /etc/skel (i.e., in the regular template) in those two cases. (Yes, I’m still on a quest to eliminate AppVMs…I think there are about six I can’t get rid of, but only two left that I can–and one of those is going to die tonight.)

About naming, that’s pretty that. What I can’t comprehend from your post - updating dvm-template. What kind of updating you actually meant on? Creating and naming, or updating/upgrading packages in it?

Ah, OK. My naming convention is a bit odd perhaps.

Salt scripts run either in the dom0 environment, or some other VM’s environment, so you have to do something in the right environment.

My vmname-create.sls script includes the command to actually create the VM, and it includes qvm-prefs, qvm-features, and qvm-tags calls. These are all executed by dom0 so they belong in that environment. So “create” does a little bit more than just creating the qube. This directly corresponds to the fact that you’d normally issue these commands at the dom0 command line.

“configure” runs in the new VM’s environment and it installs all software on the machine (as well as bringing in config files and so on). The file copies in salt all implicitly assume the mod is going to happen on whatever system the environment specifies, so they go there. (In a bash script it would be qvm-copy-to-vm run from dom0.) But installing software must happen on the target machine, either from the command line or from salt.

As it turns out, most VMs have about the same length of “create” salt files, but there’s a big difference between the types of VMs for configure. TemplateVMs have long configure files, DVM templates ideally have no configure file, though I have a couple of exceptions, the DVMs (when I create a named one) have no configure file, and AppVMs usually have something even if it’s just installing user pref files into the home directory. (For DVM templates I used to do it the same way, but then I found out about /etc/skel…which lives on the template, not the app vm.)

I have a bash script that invokes the create file, then the config file (if any). There’s also a rare case where I might want dom0 to do something after config, so there’s a third file that can run (can’t remember what I called it)…if it is present. The script does all that just based on the template name and a prefix I supply it.

I can run the same script to update the software on a VM. It runs create…which will NOT create the VM because it already exists, but MIGHT change prefs and features if they’re different than they should be–that’s good, just in case something got changed, set it back. Then config runs (if there’s a config file) and that should update software and other files if they need to be, then finally that last file. (Yet another issue I haven’t brought up yet is something that final file addresses…I’ll get to it in due course.)

For templates I even set up the config files to include the “parent” template’s config files (e.g., if I clone deb11a-base to create deb11a-wifi, deb11a-wifi’s config file includes deb11a-base’s config file, so I can update everything on deb11a-wifi with one command instead of having to update deb11a-base then clone it again).

But because of this glitch, my create file for DVM templates has to create the dvmt under the wrong name (e.g., to create firefox-dvmt, I create firefox-dvmt1, set prefs and features, then copy that qube to the right name and delete the one with the wrong name–so that at the end I have firefox-dvmt but no firefox-dvmt1). If, later on, I want to make sure firefox-dvmt has the right prefs and features, I usually just run my script which will run create and configure. But the create will look for firefox-dvmt1 (not firefox-dvmt) and if not found, will create it; it then sets prefs and features on firefox-dvmt1 and then tries to rename it. Well, my old firefox-dvmt is still there, so that fails. I get to say “Steve you dumbass” and delete firefox-dvmt and firefox-dvmt1 by hand and rerun again.

Yes, I could solve this a bunch of different ways but they all would take some work and I’d rather wait to see if they can just fix the problem so I don’t have to rename VMs.

1 Like

It is my experience that this will show the disposable:qube menu ,
and rename the original to Template (disp): qube

The only difference of note is that I use qvm-features [vmname] appmenus-dispvm True
rather than the implicit 1 that you cite.

I switched to using True…and it makes no difference (and I verified by scrolling up that the command is being issued with ‘True’). I am still seeing (in the KDE menu) a “regular” Qube where it should be a Template (disp): qube, and the disposable is no longer there (I regenerated a qube I had previously built with my work around). [note I think before I tried switching it would at least show as a disposable temple. Now, it won’t even do that.)

As far as the KDE menu is concerned, this is a regular AppVM and not a disposable template, but the Qubes Manager shows it as a dvm template (though the icon won’t update until you close and reopen it). I’ve tried both True and true (thinking case sensitivity might be an issue). Makes no difference.

I’ve just tested with a variety of templates, and the menu items are
created as expected.
I have dom0 testing repositories enabled, but I do not recall ever seeing
the behaviour you complain of.

I’m not sure where to go without a good deal more information, and
perhaps a sample.

OK, I did the following through the GUI: Created an appvm based on debian-11-minimal. Then in settings, “Advanced” tab, turned on “Disposable template”

Checking with qvm-prefs and qvm-features, this apparently turns on appmenus-dispvm, setting it to 1, in addition to turning on template_for_dispvms (setting it to True). So the default for the gui checkbox is to assume the user will want disp1234 disposables. Not unreasonable (also not true for me 80 percent of the time, but my case is likely an exception).

AND it shows up properly in the KDE menu.

Command line (same result):

qvm-create --template debian-11-minimal --label read A-menu-test-dvmt1
qvm-prefs A-menu-test-dvmt1 template_for_dispvms True
qvm-features A-Menu-test-dvmt1 appmenus-dispvm 1

Doing the same thing with my deb11a-base template, it does not work. The flag gets set but the menu never updates. Sometimes KDE can take about 30 seconds or so to “catch up” but it has now been about ten minutes and it’s still just a “Qube.”

The command line also does not work.

I conclude that there’s something about that template that breaks this functionality. Since every user-level (I also call them “app” templates as opposed to “system” templates–it’s a meaningful distinction to the user, not to a qubes developer I know) template in my system ultimately derives from that template, I conclude that’s where the issue is–there’s either something squirrely about some package there, or my salt scripts are somehow bunging things up. I just have to selectively remove things from that configuration until it works.

I’ve eliminated one factor. deb11a-base has as it’s immediate ancestor deb11m-sys-base, which is the ancestor of absolutely everything I’ve built–including things like sys-wifi-net, my redone sys-cacher, etc. It’s the ancestor to what I call my “system” qubes as well as my “app” qubes. And deb11m-sys-base does not show this problem, so I know it’s something deb11a-base added to deb11m-sys-base.

The command line also works in this case.

OK…well, I have some work to do, just tedious “add things until it breaks”/“remove things til it doesn’t” type stuff. (If I remove everything from deb11a-base and it’s still broken, then it’s something I’m doing in salt as such, not a package or configuration.) And also running things from the command line instead of using salt, to eliminate something about salt being the issue.

When I know the immediate cause of the problem, I’ll be back to let you (and others including @enmus, who seems to be having similar issues) know. Thank you for your help!

It’s not only about Steve?

Is there any limit about the number of records in menu folders?

/home/user/.local/share/applications/ - ~1500 entries

/home/user/.local/share/desktop-directories/ - ~150 entries

/home/user/.local/share/qubes-appmenus/ - ~110 entries