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

[SteveC]

I’ll start by repeating my last comment here…which wasn’t set up as a reply to you, so I don’t know if you’ll see it otherwise. Then, after that, I have more information.

@SteveC

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!

************* OK, New information *************

It looks like what bollixed deb11a-base up was a line in my salt where I set the default-menu-items. I was setting both that and menu-items, to a list of stuff I hadn’t yet installed–but did actually install on the qube in the next salt file. (I had the same line in “earlier” templates but it just put in qube startup and xterm.)

I tried issuing the same command after the qube had been set up and the reference software installed, and…no luck. Which is just as well; instituting that on all qubes would be a royal pain. Anyhow, I’m removing that line from my salt jinja include for creating templates–particularly since I’m not quite sure what it actually is used for anyway.

[SteveC]

Another discovery: If you use the menu-item features while creating a disposable VM template, it messes up again. In that case, you have to set default-menu-item.

So you must use menu-item on the templateVM and you must use default-menu-item on the DVM Template.

I have one residual issue. If I am creating the DVM template for the sole purpose of supporting a named disposable virtual machine, I generally don’t want to set the feature appmenus-dispvm (I don’t want to create disp1234 DVMs from this). What happens then is the dvm template shows as “Qube”. That’s not too big a deal because the behavior is correct; if you start something up, it runs in the DVM template. It’s potentially confusing, though. (This clears up by simply running settings and refreshing applications.)

[Zeno]

Did you find any solution to this, except renaming back and forth?

[SteveC]

Somewhere else…I don’t know where…I described a procedure I discovered that didn’t involve renaming but did involve having to start the qube up, shut it down, change the menu…ridiculous but not as time consuming as two renames.

I found out in the process of switching to 4.2…that almost everything works well (no gymnasitics needed at all) provided you’re very careful about qube-start.

When dealing with a disposable template, there are two menus that can be generated: one is the menu to actually control the template itself, the other is the menu to launch the disp1234 based on that template. (You get the second menu if you set the feature “appmenus-dispvm” to true. You always get the first one.) In the latter case you cannot have qube-start in the menu without a lot of crazy stuff to get it to show up (and it’s even more difficult in 4.2 than it was in 4.1). It makes sense not to have it, actually, since is disp1234 needs something to do, or it will just shut down immediately.

I had to do a bit of fiddly work with my scripts that regenerate VMs to get this to be done properly, but I no longer have to start qubes up and do changes of menus after I generate them, just to get menus to work right.

The price I pay is I can’t just have start-qubes on one of these templates, when I want to actually run the template. But in those cases, I just start an xterm or the file manager (if there is one), since that’s probably what I’m going to do anyway [generally if I am running a template as a template, I’m trying to debug something].