it still is not fixed
you simply don’t have a net connection. Question is now - how are your qubes put together in your qubes manager and whats your updateVM (sys-whonix or something else)?
Usual way to the net should be:
internet ← sys-net ← sys-firewall ← sys-whonix
---------------------------------------------^— appVMs
Error: Failed to download metadata for repo ‘fedora’: Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached forhttps://mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64 [Operation timed out after 30000 milliseconds with 0 out of 0 bytes received]
It appears you have no network.
i am posting from the machine that has no internet
it has internet
the internet is connected to sys-net to sys-firewall to sys-whonix
i have global settings to get updates/upgrades from whonix
all the other templates did upgrade
i have no idea whats hapening
-
If you are on R4.0 please post the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy
-
Within the fedora template, please try
curl --proxy http://127.0.0.1:8082/ -O https://keys.qubes-os.org/keys/qubes-release-4-signing-key.ascto check the network connection without using dnf
Does sudo dnf update in fedora-34’s terminal works?
If it works, then when using Qubes update to update fedora-34, is default-mgmt-dvm invoked? It might be something wrong with it…
If it’s invoked, does update in it’s terminal works? If it works, then it’s the problem between it and the template. If it doesn’t work then the network doesn’t work,
If it’s not invoked, then it’s the problem of the template, I guess, and you should maybe try to download and install fresh new template.
EDIT: Sorry, @Sven added post while i was preparing mine, so didn’t see it.
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
when i did curl in the terminal nothing happened. i saw a bunch of 0s and after a long time shut down the qube
I typed it and it says
Copr repo for PyChar
then it’s a bunch of zeros and lines and nothing happens
I must to download an entire new template? 
If those are the only lines you found the problem, make sure you also have the following lines:
$type:TemplateVM $default allow,target=sys-whonix
$type:TemplateVM $anyvm deny
This confirms no connection, which is not surprising if the above lines are in fact the only ones. $tag:whonix-updatevm identifies only qubes that have the respective tag (you can check with qvm-tags). $type:TemplateVM identifies all templates.
i don’t think it fixed it
i tried your fix @sven but the cirlce thing goe aroun and around. nothing changes
it’s doing what it did before: just showing “Updating fedora-34” for a much time with nothing hapening
is there command or icon for qubes to see rate of download upload?
i think it’s doing no thing
does the disp-mgmt need net access or is that qubes that used for just moving files or upgrade around?
i don’t like connecting to net through system with possible error and not knowing what goes on
it makes more likely i become crushed under wall
from other posts I assume you are on R4.1?
If so that was the wrong file and has no influence on what’s happening. I am not on R4.1 yet personally, but here is an article explaining the difference:
You said all your other templates update fine. What are those? Debian, Whonix?
I have never seen such an output from dnf update. Sorry.
Copr repo for PyChar
I have never seen such an output from
dnf update. Sorry.
That’s just an unofficial Fedora repo for a Python IDE.
The issue clearly is no network connection available to DNF. The question is: why?
Yes, I know about Copr, thanks but it would be easier to copy/paste the real output here. That was my point.
sorry to tag on to this topic but is ,
Comment: File /usr/lib/rpm/macros.d/macros.qubes is not present
expect output during update I see it despite the rest of the output being normal.
btw, also had Fedora recent fails on 4.1 , when all other updates went through.
I’m on wifi, the debian and whonix update but Not the Fedora
often they say, wait a while and try again …
1 Like
waiting fixed it
i am less likely to be crushed under large wall
for now
for me over a number of days, with wifi otherwise working fine.
fedora 34 failed on wifi, but on 1st try worked on ethernet
go figure why