[user@dom0 ~]$ sudo qubesctl --skip-dom0 --targets=fedora-32 --show-output state.sls update.qubes-vm
fedora-32:
----------
ID: dnf list updates --refresh >/dev/null
Function: cmd.run
Result: False
Comment: Command "dnf list updates --refresh >/dev/null" run
Started: 22:40:23.101185
Duration: 3238.605 ms
Changes:
----------
pid:
1151
retcode:
1
stderr:
Errors during downloading metadata for repository 'fedora-cisco-openh264':
- Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
Errors during downloading metadata for repository 'fedora-modular':
- Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
stdout:
----------
ID: update
Function: pkg.uptodate
Result: True
Comment: System is already up-to-date
Started: 22:40:29.468223
Duration: 2599.923 ms
Changes:
----------
ID: notify-updates
Function: cmd.run
Name: /usr/lib/qubes/upgrades-status-notify
Result: False
Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
Started: 22:40:32.068342
Duration: 1361.085 ms
Changes:
----------
pid:
1306
retcode:
1
stderr:
stdout:
Summary for fedora-32
------------
Succeeded: 1 (changed=2)
Failed: 2
------------
Total states run: 3
Total run time: 7.200 s
OP’s UpdateProxy policy is missing rules for non-Whonix VMs. The rules say that any VMs with tag whonix-updateVM would use sys-whonix as their UpdateVM, but there are no rules that would match other templates that don’t have that tag.
Assuming you want to update the other templates using sys-net, two more lines could be added:
This isn’t right in 4.1.
The policy file framework has been updated to use a default unified file
under /etc/qubes/policy.d/90-default.policy.
If you want to make changes to the default policy, you create a NEW
policy file in that directory, numerically lower, and that will override
the default.
That separate Whonix file is unnecessary, since it is using the old,
deprecated, form, which will be used under 4.X, but dropped in 5.0. Whonix
treatment is correctly set in the default file.
SO, to anyone having this problem, let’s get some hard information:
Confirm which version of Qubes you are using.
Does the error affect all templates? If not, which are affected?
For templates which show the error, what is the output of qvm-tags?
Are you updating over Whonix?
Have you made any changes to default policy?
What template are you using for the UpdateProxy - by default this
will be sys-net unless you opted to update all templates over Tor.
I have the same issue. I’m using Qubes 4.1. The error is: Denied: whonix.NewStatus. It happens when I open the whonix-gw-16 template, whonix-ws-16 template and any other VM based on whonix-gw-16 or whonix-ws-16. Never changed any policy, Just updated all vms. The error appears when shut down or start a vm(based on whonix templates). I’m not updating over tor.
Same issue here after cloning sys-net to seperate wireless and wired connectivity.
Nothing can update except dom0. No idea what to do. Default Fedora-34 AppVMs still have connectivity but AppVM’s based on minimal templates do not even connect to internet anymore.
Feels like a global pref issue but can’t find nor do I know Qubes enough to know what is wrong.
Same Issue here after deleting sys-net and creating sys-net-lan and sys-net-wlan. Fresh 4.1 install Debian templates only.
I also edit /etc/qubes/policy.d/90-default.policy and changed qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net
to qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net-wlan
I stumbled upon this bug a day before and thought i somehow trashed my qubes install (playing a lot with saltstack latley) so i did a fresh install yesterday, but now its there again…
Maybee i missed something in the minimal templates to install, but even if i switch apvm templates back to default debian-11 the error seems to persist.
some progress here, at least template updates are working if i activate the “qubes-updates-proxy” service in the qube thats defined in /etc/qubes/policy.d/90-default.rule
SO, to anyone having this problem, let’s get some hard information:
Confirm which version of Qubes you are using. **4.1.1**
Does the error affect all templates? **yes**
For templates which show the error, what is the output of qvm-tags? **cannot update repo**
Are you updating over Whonix? **whatever is default**
Have you made any changes to default policy? **not to my knowledge**
What template are you using for the UpdateProxy - by default this will be sys-net unless you opted to update all templates over Tor. **default**
Thank you for reply joe,
still get the error after reboot. There was already one line
in qubes.UpdatesProxy: $type:TemplateVM $default allow,target=sys-vpn
Should I delete that and only keep your six lines?
Following this from whonix aboout UpdatesProxy:
**_At the very top_of that file you should have the following: ** $tag:whonix-updatevm $default allow, target=sys-whonix
whonix now updates, but fedora-36, debial-11, kali, and
gentoo-xfce still fail to update.
These are the generated lines during the install: $tag:whonix-updatevm $default allow,target=sys-whonix $tag:whonix-updatevm @anyvm deny $type:TemplateVM $default allow,target=sys-whonix
The six lines earlier was a larger selection.
Try deleting the sys-vpn line. Check your Global Settings. You might have selected sys-vpn in your Global Settings. Maybe it’s a conflict with sys-whonix.
Thank you Joe.
That worked for all qubes except kali and gentoo, so I just deleted them.
My UpdatesProxy now has 8 lines - seems duplicate but for the $ and @
and tag and type:
**
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:TemplateVM @default allow,target=sys-whonix
$tag:TemplateVM @anyvm deny
$type:TemplateVM $default allow,target=sys-whonix @tag:whonix-updatevm @default allow,target=sys-whonix @tag:whonix-updatevm @anyvm deny @type:StandaloneVM @default allow,target=sys-whonix @type:StandaloneVM @anyvm deny
**
Its nice to not see all those errors pop up. Thank you!
Why do you still insist on qubes.UpdatesProxy, and especially using legacy and new tags?
# HTTP proxy for downloading updates
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy * @tag:whonix-updatevm @anyvm deny
# Upgrade all TemplateVMs through sys-whonix or cacher.
qubes.UpdatesProxy * @type:TemplateVM @default allow target=cacher
# Default rule for all TemplateVMs - direct the connection to sys-net-dvm or cacher
qubes.UpdatesProxy * @type:TemplateVM @default allow target=cacher
qubes.UpdatesProxy * @anyvm @anyvm deny
Immediately when starting the Whonix WorkSpace 16 qube, after the Whonix GateWay 16 qube started successfull.
Denied: qubes.UpdatesProxy
Denied qubes.UpdatesProxy from whonix-ws-16 to
Whonix-Gateway (sys-whonix) required for updates!
Please ensure that whonix-gw TemplateBasedVM sys-whonix exists.
No updates are possible without an active (running) Whonix-Gateway VM.
Completely fresh Qubes OS installation, only Whonix templates installed. Not even trying to update yet, only launch Whonix.
Qubes R4.1.1 x86_64
Don’t know, only Whonix 16 templates (GateWay and WorkSpace) installed
qvm-tags: command not found
Installing off a fresh Qubes ISO USB.
Since not sure what that means, I guess not(?)
If thats true when only Whonix templates installed, then I guess sys-net(?)
Do you have sys-whonix, and is it started? To me it looks like you started whonix-gw-16 which is template and no template provides network. AppVm based on that template named sys-whonix provides network and possibility to update.
if you had sys-whonix but you renamed it, then you have to change correspondent entries in `/etc/qubes/policy.d/90-default.policy
You’d want instead to create let’s say 30-user.policy with the content above, for example, just rename sys-whonix with the name you gave to it. I haven’t tested if renaimg is allowed for sys-whonix in order update to properly work, so if it doesn’t then try to name it back to sys-whonix.
None of this is guaranteed, it’s just my thoughts on the issue. Further info needed probably for better diagnostics.
You make a distinction between sys-whonix and whonix-gw-16 that the installer does not. Under initial setup → configuration whonix-gw-16 and whonix-ws-16 seem identified with sys-whonix and anon-whonix respectively:
Create Whonix Gateway and Workstation qubes (sys-whonix, anon-whonix)
Since it said whonix-gw-16 started successfully, I assumed I could start whonix-ws-16 without further steps. But you are saying I need to start sys-whonix manually first? How can I do that? I have not renamed it as far as I know.
Also important is that when you install only Whonix templates (no Fedora and Debian), most configuration options get greyed out, including “Create Whonix Gateway and Workstation qubes (sys-whonix, anon-whonix)”. I assumed that option was necessarily implied by installing only Whonix templates, but now I am second guessing myself. Could it be that sys-whonix and anon-whonix, and also sys-net, sys-firewall and sys-usb, are not created unless a Debian or Fedora qube is also installed?