Qubes Manager shows that whonix-ws-dvm needs to be updated, but the update button is disabled

[donob4n]

Qubes OS version:

Qubes 4 testing

Affected component(s):

qubesmanager

---

Steps to reproduce the behavior:

I don't know how to reproduce. I saw it since time ago.

Expected behavior:

whonix-ws-dvm shouldn't need to be updated (at least with standard distribution procedure). Also, if Qube Manager considers it needs to be updated, should it let you click the update button?

Actual behavior:

You can see the update needed icon but you can't click the update button.

General notes:

I am not sure if Tor Browser should be installed in whonix-ws template or whonix-ws-dvm. In second case the update button could be useful for updating it.

---

Related issues:

[marmarta]

can you tell me the output of qvm-prefs whonix-ws-dvm and qvm-features whonix-ws-dvm (both run from dom0 console)? It would be really helpful in debugging this.

[marmarta]

can you tell me the output of qvm-prefs whonix-ws-dvm and qvm-features whonix-ws-dvm (both run from dom0 console)? It would be really helpful in debugging this.

[donob4n]

Yes here is:

[user@dom0 ~]$ qvm-prefs whonix-ws-dvm
autostart D False
backup_timestamp U
debug D False
default_dispvm - whonix-ws-dvm
default_user D user
gateway D
gateway6 D
include_in_backups D True
installed_by_rpm D False
ip D 10.137.0.8
ip6 D
kernel D 4.14.18-1
kernelopts D nopat
klass D AppVM
label - red
mac D 00:16:3E:5E:6C:00
maxmem D 4000
memory D 400
name - whonix-ws-dvm
netvm - sys-whonix
provides_network D False
qid - 8
qrexec_timeout D 60
start_time D
stubdom_mem U
stubdom_xid D -1
template - whonix-ws
template_for_dispvms - True
updateable D False
uuid - 434be95b-a5c2-4389-9bea-ce4094916d8c
vcpus D 2
virt_mode D pvh
visible_gateway D 10.137.0.7
visible_gateway6 D
visible_ip D 10.137.0.8
visible_ip6 D
visible_netmask D 255.255.255.255
xid D -1

[user@dom0 ~]$ qvm-features whonix-ws-dvm
appmenus-dispvm 1
updates-available 1

[donob4n]

Yes here is:

[user@dom0 ~]$ qvm-prefs whonix-ws-dvm
autostart D False
backup_timestamp U
debug D False
default_dispvm - whonix-ws-dvm
default_user D user
gateway D
gateway6 D
include_in_backups D True
installed_by_rpm D False
ip D 10.137.0.8
ip6 D
kernel D 4.14.18-1
kernelopts D nopat
klass D AppVM
label - red
mac D 00:16:3E:5E:6C:00
maxmem D 4000
memory D 400
name - whonix-ws-dvm
netvm - sys-whonix
provides_network D False
qid - 8
qrexec_timeout D 60
start_time D
stubdom_mem U
stubdom_xid D -1
template - whonix-ws
template_for_dispvms - True
updateable D False
uuid - 434be95b-a5c2-4389-9bea-ce4094916d8c
vcpus D 2
virt_mode D pvh
visible_gateway D 10.137.0.7
visible_gateway6 D
visible_ip D 10.137.0.8
visible_ip6 D
visible_netmask D 255.255.255.255
xid D -1

[user@dom0 ~]$ qvm-features whonix-ws-dvm
appmenus-dispvm 1
updates-available 1

[marmarta]

@marmarek , check this out - a VM that got both updateable=False and updates-available=1 . I think there's a backend problem with assigning the updates-available feature.

[marmarta]

@marmarek , check this out - a VM that got both updateable=False and updates-available=1 . I think there's a backend problem with assigning the updates-available feature.

[Wikinaut]

I have the same problem.

But in addition, when I want to delete the disposable vm in order to clean up the mess, then I see an

ERROR: Domain is in use: '(dvm-name)'; details in system.log

[Wikinaut]

I have the same problem.

But in addition, when I want to delete the disposable vm in order to clean up the mess, then I see an

ERROR: Domain is in use: '(dvm-name)'; details in system.log

[DanMcLaughlin]

Yeah I'm seeing the same issue in 4.0 release, both for fedora-26-dvm and whonix-wx-dvm. I update both parent templates and the dvm's show an update icon, but can't hit the update. On starting the dvm's they don't automatically regenerate the image file as they did in version 3

[DanMcLaughlin]

Yeah I'm seeing the same issue in 4.0 release, both for fedora-26-dvm and whonix-wx-dvm. I update both parent templates and the dvm's show an update icon, but can't hit the update. On starting the dvm's they don't automatically regenerate the image file as they did in version 3

[donob4n]

Maybe this is not the root of the problem, but this is fixed in QubesOS/qubes-manager#91 since it only checks 'updates-available' for 'TemplateVM' domains.

[donob4n]

Maybe this is not the root of the problem, but this is fixed in QubesOS/qubes-manager#91 since it only checks 'updates-available' for 'TemplateVM' domains.

[DanMcLaughlin]

@andrewdavidwong Could you post a link or a short note on how to manually regenerate the image files? I've done a bunch of searching but for Qubes 4 aren't finding the secret sauce unfortunately. Thanks - I'd like to at least get them updated ASAP.

[DanMcLaughlin]

@andrewdavidwong Could you post a link or a short note on how to manually regenerate the image files? I've done a bunch of searching but for Qubes 4 aren't finding the secret sauce unfortunately. Thanks - I'd like to at least get them updated ASAP.

[donob4n]

@DanMcLaughlin I think this is only a qube manager notification error (due some backend problem) but updating your fedora template you have already your dvm updated too.

On starting the dvm's they don't automatically regenerate the image file as they did in version 3

This is not needed in Qubes 4.

[donob4n]

@DanMcLaughlin I think this is only a qube manager notification error (due some backend problem) but updating your fedora template you have already your dvm updated too.

On starting the dvm's they don't automatically regenerate the image file as they did in version 3

This is not needed in Qubes 4.

[DanMcLaughlin]

@donob4n Ah, no wonder I couldn't find anything, makes sense. Thanks -

[DanMcLaughlin]

@donob4n Ah, no wonder I couldn't find anything, makes sense. Thanks -

[donob4n]

You can use AppVM's as DispVM base for do custom configurations. See https://www.qubes-os.org/doc/dispvm-customization/

[donob4n]

You can use AppVM's as DispVM base for do custom configurations. See https://www.qubes-os.org/doc/dispvm-customization/

[andrewdavidwong]

@DanMcLaughlin: @donob4n provided the correct link to describe the new behavior in Qubes 4.0.

[andrewdavidwong]

@DanMcLaughlin: @donob4n provided the correct link to describe the new behavior in Qubes 4.0.

[donob4n]

Should be fixed with QubesOS/qubes-manager#91

[donob4n]

Should be fixed with QubesOS/qubes-manager#91

[Zig-03]

I have the same issue (I'm on the latest version, not sure how can I check the exact version but there are no pending updates).

edit: I've updated the whonix-dw templatevm, tho it didn't ask for that and the arrow icon (updates pending) from the whonix-dw-dvm didn't disappear anyway.

[Zig-03]

I have the same issue (I'm on the latest version, not sure how can I check the exact version but there are no pending updates).

edit: I've updated the whonix-dw templatevm, tho it didn't ask for that and the arrow icon (updates pending) from the whonix-dw-dvm didn't disappear anyway.

[donob4n]

Do you mean whonix-ws-dvm and whonix-ws?

Did you try restarting Qube Manager? I think there is some problem with sync but in any cash whonix-ws-dvm should not get update icon. Do you have refresh button?

[donob4n]

Do you mean whonix-ws-dvm and whonix-ws?

Did you try restarting Qube Manager? I think there is some problem with sync but in any cash whonix-ws-dvm should not get update icon. Do you have refresh button?

[exidez]

I am having the same issue as Zig-03 and other. I have a fresh install of Qubes R4.0 and have updated all the template VM's and dom0. I noticed this after the updates and whonix-dw-dvm is still showing that it needs an update. Everything has been restarted

[exidez]

I am having the same issue as Zig-03 and other. I have a fresh install of Qubes R4.0 and have updated all the template VM's and dom0. I noticed this after the updates and whonix-dw-dvm is still showing that it needs an update. Everything has been restarted