Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applications menu corrupted with template update (fedora 30 -> 31) #5898

Closed
tumbletree opened this issue Jun 21, 2020 · 1 comment
Closed
Labels
C: other eol-4.0 Closed since Qubes 4.0 has been EOL for over one year P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@tumbletree
Copy link

Qubes OS version:

4.0

Affected component(s) or functionality:

Applications menu
template update


Steps to reproduce the behavior:

  1. installed a new template by switching, as described here https://www.qubes-os.org/doc/templates/#switching

587 sudo qubes-dom0-update qubes-template-fedora-31

  1. Cloned the template to fedora-31-mod. (Modified Firefox about:config to my liking, but later discovered it wasn't propgated through the template).

  2. Went straight on to setting the disposable template. This was a mistake re instructions, I skipped step 2 (using Qubes Template Manager).

I made a few typos, but leave them in for transparency. Terminal history output:

  588  qvm-create -l red -t fedora-31 fedora-31-dvm
  589  qvm-create -l red -t fedora-31-mod fedora-31-dvm-mod
  590  qvm-delete fedora-31-dvm-mod
  591  qvm --help
  592  qvm-remove
  593  qvm-remove fedora-31-dvm
  594  qvm-remove fedora-31-dvm-mod
  595  qvm-create -l red -t fedora-31-mod fedora-31-mod-dvm
  596  qvm-prefs fedora-31-mod-dvm template_for_dispvms True
  597  qvm-features fedora-31-mod appmenus-dispvm 1
  598  qubes-prefs default-dispvm fedora-31-mod-dvm
  1. Used Qube Settings box in the Qubes Manager, one-by-one, to reset each vm's to the new fedora-31-mod. I got about half done (~10) before a break.

  2. The system updater called for fedora-31 and fedora-31-mod and I ran it. I can't remember if I rebooted somewhere in here.

  3. Check the Applications menu and discovered the malfunction.

  4. Stare in horror.

  5. PartB: recovery attempts. Tried lots of advice and experiments (see Reddit/r/qubes thread) https://www.reddit.com/r/Qubes/comments/haiisn/upgrade_to_fedora31_applications_menu_borked_help/. I made a mistake in following advice, deleted all contents of ~/.local/share/desktop rather than .desktop files. Lost all qubes in Applications menu.

Expected or desired behavior:

Nothing at all should have hapened to the Application menu.

Template should have simplly swapped over. There should be no difference between adjusting template in Qubes Manager/Settings box versus Template Manager.

Or, it should be clearly documented and/or clearly signalled in that operation.

Recovery from this - e.g. a re-set of the entire Application menu for ALL vms - should be trivial. A single command should be able to repopulate all menu items. Nothing I can find has done that (see reddit dialog).

Actual behavior:

All apps whose template I changed by Qubes Manager/Settings were then listed in Applications menu as "Disposable: [insert qube name here]" (complete with icon).
-They aren't behaving like they are disposable. I can create a file, close the vm and the new file is there on re-opening.
-The fedora-31-mod template entry in Applications also displayed as a "Disposable: fedora-31-mod".

App-menu items on each vm were not working. The qube itself didn't start. Only Qubes Settings can be launched. Everything launches fine from the dom0 command-line.

For my remaining vms, I used Qubes Template Manager (I reviewed the instructions). These appvms do not have any problems.

General notes:

I have tried a bunch of things to correct this, including replacing the template with a new one, and accidentally deleted all contents of ~/.local/share/desktop.

Vms seem to be popping back in the Applications menu now after I modify the Applications in Qubes Manager > Settings. That hasn't always been the case; there seems to be a time lag ( similar to (?) to #5588?) in some case.

Most puzzling of all was why two vm's would not display (in app-menu) all the applications assigned to them in Settings. Then today, it has started working.

I am not going to troubleshoot all that.

The focus of this Issue report should be on
a) why reassigning a new template via Qubes Manager > Settings should screw up my Applications menu
b) why is there now all-vm re-set/re-populate option (or documentation of it)?


I have consulted the following relevant documentation:

most prominently:

https://www.qubes-os.org/doc/managing-appvm-shortcuts/
https://www.qubes-os.org/doc/template/fedora/upgrade/

Also, see advice given on https://www.reddit.com/r/Qubes/comments/haiisn/upgrade_to_fedora31_applications_menu_borked_help/

I am aware of the following related, non-duplicate issues:

app-menus not populating properly #4218
#5588

@tumbletree tumbletree added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Jun 21, 2020
@andrewdavidwong andrewdavidwong added this to the Release 4.0 updates milestone Jun 23, 2020
@andrewdavidwong andrewdavidwong added the needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. label Jun 23, 2020
@andrewdavidwong andrewdavidwong added the eol-4.0 Closed since Qubes 4.0 has been EOL for over one year label Aug 5, 2023
@github-actions
Copy link

github-actions bot commented Aug 5, 2023

This issue is being closed because:

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.)

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 5, 2023
@andrewdavidwong andrewdavidwong removed the needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. label Aug 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: other eol-4.0 Closed since Qubes 4.0 has been EOL for over one year P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

2 participants