Disposable template does not have right icon in app menu; launches apps in disposable template rather than in disposable based on template

[kototama]

Qubes OS version:

Q4RC3

Affected TemplateVMs:

fedora 26

---

Steps to reproduce the behavior:

Install fedora 26 template with:

sudo qubes-dom0-update qubes-template-fedora-26
qvm-create -l red -t fedora-26 fedora-26-dvm
qvm-prefs fedora-26-dvm template_for_dispvms True
qvm-features fedora-26-dvm appmenus-dispvm 1
qubes-prefs default-dispvm fedora-26-dvm

Expected behavior:

A menu entry with Disposable: fedora-26-dvm is created

Actual behavior:

A menu entry with Domain: fedora-26-dvm is created

General notes:

Is there a workaround? How can I start a fedora 26 disposable VM?

---

Related issues:

[marmarek]

qvm-features fedora-26-dvm appmenus-dispm 1

Typo, should be appmenus-dispvm. If that doesn't help, try qvm-appmenus --update fedora-26-dvm

[kototama]

Sorry what is the typo? You mean it should be appmenu-dispvm ??

[marmarek]

You wrote appmenus-dispm, should be appmenus-dispvm.

[kototama]

I see. I had it right in the bash history, just typed it wrongly for this bug report. Typing qvm-appmenus --update fedora-26-dvm solved it. Thank you very much.

One more question, I have: update-availables 1 in fedora-25-dvm prefs but not in fedora-26-dvm. Do I need to set it?

[kototama]

I am editing the bug report for the typo, since the bug is not due to a typo...

[marmarek]

One more question, I have: update-availables 1 in fedora-25-dvm prefs but not in fedora-26-dvm. Do I need to set it?

No. It should be on the template (fedora-26), not fedora-26-dvm. It is info that you have some updates pending for that template. updates-available should be handled automatically, no manual action should be required.

[andrewdavidwong]

@kototama, would you be willing to help us document this? Please see the Documentation Guidelines for details.

[iamahuman]

Fedora 26 is no longer supported. It might be a good idea to close this issue.

[andrewdavidwong]

If anyone would like this issue to be reopened, please leave a comment. Thank you.

[tlaurion]

@marmarek @andrewdavidwong @ninavizz

Any idea why qvm-appmenus --update fedora-34-dvm is required to be entered manually after following https://www.qubes-os.org/doc/templates/#switching instructions:

 [user@dom0 ~]$ qvm-create -l red -t fedora-34 fedora-34-dvm
 [user@dom0 ~]$ qvm-prefs fedora-34-dvm template_for_dispvms True
 [user@dom0 ~]$ qvm-features fedora-34-dvm appmenus-dispvm 1
 [user@dom0 ~]$ qubes-prefs default-dispvm fedora-34-dvm

Otherwise, the "recycling icon" (stating a qube is actually a disposable qube template) in xfce menu is not showed (and the disposable qube template is not a disposable qubes template) and launching apps there launches them inside of the dvm template, not under a disposable qube as intended.

Which for clarity until bug fixed, documentation at https://www.qubes-os.org/doc/templates/#switching should be :

[user@dom0 ~]$ qvm-create -l red -t <NEW_TEMPLATE> <NEW_DISPOSABLE_TEMPLATE>
 [user@dom0 ~]$ qvm-prefs <NEW_DISPOSABLE_TEMPLATE> template_for_dispvms True
 [user@dom0 ~]$ qvm-features <NEW_DISPOSABLE_TEMPLATE> appmenus-dispvm 1
 [user@dom0 ~]$ qubes-prefs default-dispvm <NEW_DISPOSABLE_TEMPLATE>
 [user@dom0 ~]$ qvm-appmenus --update <NEW_DISPOSABLE_TEMPLATE>

Longer term

For the sake of simplicity of in-template upgrades (let it be only over a year timelapse of Qubes usage), is there a reason why the templates would not be simply named fedora, debian, whonix-ws and whonix-gw instead of having their name+version when deployed? The deployed template names could be deployed without name+version (eg: fedora), where the rpm being downloaded should continue to contain name+version (so a user can choose the version desired from repositories, while installed template name should not contain a version in its deployed template usable name).

That would ease so much the process involved into maintaining one system over time for users, with whonix-ws whonix-gw fedora and debian having to be cloned, locally upgraded, then switching disposable qubes manually; including an even more involved process if one wants sys-usb-dvm and sys-net-dvm under Qubes 4.0. And having to do that a couple times in a year.

A user could simply rename a currently used template from GUI if he wants to reinstall cleanly from rpm, and then assign one by one the qubes he wants to depend on newly deployed template, where everything else would continue to work, instead of having to do the inverse at least 3 times a year, which is cumbersome even for advanced users.

Then, an in-place upgrade script could be deployed, and QA testing could be applied to make sure an in-place upgrade of template is possible at time of EOL of templates, just like Whonix warns their users of EOL (unfortunately, with their in place upgrade script being broken inside of whonix-gw this time when trying to upgrade from 14-> 15).

And the users would finally have a great UX using Qubes over longer periods of time, with the illusion of having a semi-rolling-release feeling of its moving parts, not having to care too much about EOL of templates and having to plan ahead some kind of migration. Wouldn't that be great, @ninavizz ?

[marmarek]

Thanks for the report, I'll take a look. I assume it's Qubes 4.0, right?

For the sake of simplicity of in-template upgrades, is there a reason why the templates would not be simply named fedora, debian, whonix-ws and whonix-gw instead of having their name+version when deployed?

There is very real benefit of having version in the template name: you can switch between them. This includes migrating to a newer template in parts, but also ability to go back quickly to the previous one if something isn't compatible with the new one yet. This means for example you can migrate some of your VMs to a newer version, without disrupting some time-critical work you do in others.

The update experience is something we do need to work on, and updating templates to newer version is part of that task (including #3430).

[tlaurion]

Thanks for the report, I'll take a look. I assume it's Qubes 4.0, right

Right.

[andrewdavidwong]

Possibly related: #7058

[andrewdavidwong]

Wait, isn't this (now) a duplicate of #3574?

[ninavizz]

This is from 2018 and the icons have changed entirely. The new app menu is also an entirely different beast, I believe. @marmarta correct me if I'm wrong?

I feel like this issue should be closed. Will defer to Marta.

[github-actions[bot]]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment. (For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)