Dares
March 9, 2024, 3:05pm
1
After installing fedora-39-xfce following the instructions in the documentation, I feel like I remember updating it once through the Qubes updater, but now the update fails with the error:
Updating fedora-39-xfce
Error: Failed to download metadata for repo ‘fedora’: Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-39&arch=x86_64 [CONNECT tunnel failed, response 403]
Error: Failed to download metadata for repo ‘fedora’: Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-39&arch=x86_64 [CONNECT tunnel failed, response 403]
Entering the template and trying to update it using sudo dnf upgrade
results in the same error. I can visit the URL in a browser just fine, so I assume something is wrong with the updating proxy, but I don’t know how or what to do.
1 Like
It’s probably this bug:
opened 12:41PM - 08 Mar 24 UTC
T: bug
P: blocker
C: Fedora
needs diagnosis
C: updates
affects-4.2
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## Qubes OS release
4.2
### Steps to reproduce
Upgraded Fedora templates (both full and minimal), then shut them down and restarted sys-net/firewall. Now, there is no possibility to upgrade any templates (neither Fedora nor Debian).
### Expected behavior
Upgrades should proceed as usual.
### Actual behavior
Fedora 39 template:
```
[user@fedora-39 ~]$ sudo dnf upgrade --refresh && sudo dnf clean all
Fedora 39 - x86_64 0.0 B/s | 0 B 00:01
Errors during downloading metadata for repository 'fedora':
- Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-39&arch=x86_64 [CONNECT tunnel failed, response 403]
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-39&arch=x86_64 [CONNECT tunnel failed, response 403]
[user@fedora-39 ~]$
```
Debian 12 template:
```
user@debian-12:~$ sudo apt update && sudo apt full-upgrade && sudo apt autoremove --purge && sudo apt autoclean
Ign:1 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Ign:2 https://deb.debian.org/debian bookworm InRelease
Ign:3 https://deb.debian.org/debian-security bookworm-security InRelease
Ign:1 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Ign:2 https://deb.debian.org/debian bookworm InRelease
Ign:3 https://deb.debian.org/debian-security bookworm-security InRelease
Ign:1 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Ign:2 https://deb.debian.org/debian bookworm InRelease
Ign:3 https://deb.debian.org/debian-security bookworm-security InRelease
Err:1 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
Err:2 https://deb.debian.org/debian bookworm InRelease
Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security bookworm-security InRelease
Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
Reading package lists... Done
E: Failed to fetch https://deb.debian.org/debian/dists/bookworm/InRelease Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.debian.org/debian-security/dists/bookworm-security/InRelease Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.qubes-os.org/r4.2/vm/dists/bookworm/InRelease Invalid response from proxy: HTTP/1.0 403 Access denied Server: tinyproxy/1.10.0 Content-Type: text/html Connection: close [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.
user@debian-12:~$
```
Fedora curl 127.0.0.1:8082
```
[user@fedora-39 ~]$ curl 127.0.0.1:8082
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>403 Access denied</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<h1>Access denied</h1>
<p>The administrator of this proxy has not configured it to service requests from your host.</p>
<hr />
<p><em>Generated by <a href="https://tinyproxy.github.io/">tinyproxy</a> version 1.10.0.</em></p>
</body>
</html>
[user@fedora-39 ~]$
```
Debian curl 127.0.0.1:8082
```
user@debian-12-minimal:~$ curl 127.0.0.1:8082
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>403 Access denied</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<h1>Access denied</h1>
<p>The administrator of this proxy has not configured it to service requests from your host.</p>
<hr />
<p><em>Generated by <a href="https://tinyproxy.github.io/">tinyproxy</a> version 1.10.0.</em></p>
</body>
</html>
user@debian-12-minimal:~$
```
### Workaround
Shut down sys-net/firewall/usb.. and switch the DVM template on which these DispVMs are based to Debian-12. The internet connection will return to the templates.
### Note
The internet connection is lost only in the templates, not in DispVMs or AppVMs.
It’s being fixed now; in that issue thread you can also find workarounds to fix it temporarily. I think rebasing your sys-net
and sys-firewall
to debian templates may also work.
6 Likes
Dares
March 9, 2024, 3:35pm
3
Looks like that was posted after I tried to find it yesterday. I should’ve checked today. That looks exactly like my issue. Thank you very much
1 Like
@Dares Can you try if your Debian templates and HVM-qubes get updated? Because it seems i have the same problem, but it affects all of my templates, but not dom0 and HVM-qubes.
Dares
March 9, 2024, 4:47pm
5
I do not have any debian templates, so I cannot help you with that.
solene
March 10, 2024, 9:21am
6
The problem is fixed, but it requires a quirk to be solved faster, see this comment
One unfortunate thing is the fix will require updating twice:
1. run template update once - this will apply the fix, but the update itself will fail, since the fix isn't in sys-net at this point yet
2. restart sys-net
3. update again - now it will work
Worked for me
Does this still require manually adding Allow ::1
tinyproxy-updates.conf on 4.2?
This seems to be the only way I can get updates to work again.
I added the above
updated, dom0 and fedora/debian templates.
rebooted
run update again, still broken til I readd Allow ::1
1 Like
DVM
March 10, 2024, 4:17pm
8
It works too, but that’s not how the final fix was implemented.
qubes.UpdatesProxy
now forces IPv4 because the new socat version prefers IPv6 when using TCP
.
The fix should automatically implement this in the templates. Make sure you update dom0 first, since it is the updater itself that will change the service file the first time.
QubesOS:main
← marmarek:bug9025
opened 04:37PM - 09 Mar 24 UTC
Since the issue breaks updates, apply the fix via updater wrapper
QubesOS/qubes… -issues#9025
1 Like
barto
March 10, 2024, 4:24pm
9
[irrelevant comment retracted]
DVM
March 10, 2024, 4:29pm
10
Qubes 4.1 was also affected. This issue was caused by a socat upgrade that broke qubes.UpdatesProxy
on fedora-based templates.
2 Likes
Has the fix been released to all or is this just in testing branch?
DVM
March 10, 2024, 4:37pm
12
Based on:
opened 06:45PM - 09 Mar 24 UTC
r4.2-host-cur-test
Update of core-admin-linux to v4.2.19 for Qubes OS r4.2, see comments below for … details and build status.
From commit: https://github.com/QubesOS/qubes-core-admin-linux/commit/aa24f3def5373c62cf7c7410a5eeba99f046ac79
[Changes since previous version](https://github.com/QubesOS/qubes-core-admin-linux/compare/v4.2.18...v4.2.19):
QubesOS/qubes-core-admin-linux@aa24f3d version 4.2.19
QubesOS/qubes-core-admin-linux@35b9efe Apply hotfix for #9025
Referenced issues:
QubesOS/qubes-issues#9025
If you're release manager, you can issue GPG-inline signed command:
* `Upload-component r4.2 core-admin-linux aa24f3def5373c62cf7c7410a5eeba99f046ac79 current all` (available 5 days from now)
* `Upload-component r4.2 core-admin-linux aa24f3def5373c62cf7c7410a5eeba99f046ac79 security-testing all`
You can choose subset of distributions like:
* `Upload-component r4.2 core-admin-linux aa24f3def5373c62cf7c7410a5eeba99f046ac79 current vm-bookworm,vm-fc37` (available 5 days from now)
Above commands will work only if packages in current-testing repository were built from given commit (i.e. no new version superseded it).
For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.
Apparently, it’s only available in the testing repo.
2 Likes
I’m likely being slow, but I can’t see how to fix Qubes 4.1? I’ve tried updating tinyproxy-upates.conf as suggested above but that’s made no difference
1 Like
barto
March 11, 2024, 3:55pm
14
Yeah, fedora updates fail on 4.1 for me too: no Dom0 updates available, no communications on how to install a hotfix of some sort.
Well I know nothing about anything anymore. Tried an update this morning out of desperation more than anything, and the update went through fine and I can now install packages again.
solene
March 12, 2024, 11:24am
16
this is what was supposed to happen
Ims
March 12, 2024, 11:27am
17
Didn’t work for me… any other ideas what to try?
solene
March 12, 2024, 11:44am
18
try to update dom0 and your templates, reboot and try again?
If it doesn’t work, you could try to enable testing updates and try again the sequence above.
I was having the same problem in 4.2. I eventually made update work on my Fedora templates by:
Opening Qubes Global Config in Qubes Tools - Updates tab
ticking the bubble Enable all testing updates click APPLY
open Qubes Tools , Qube Updates uncheck all then check only dom0 hit UPDATE
4)after dom0 completes update (took longer than usual) shutdown and restart all services based on Fedora templates
Update templates as usual
Optional - Open Qubes Global Config in Qubes Tools Updates tab. tick the bubble Enable stable updates only click APPLY
I used the new tools that are provided in 4.2 but I believe the same could be done from terminal in 4.1 or 4.2
Hope it works for you
edt11x
March 12, 2024, 2:48pm
20
The other fix that worked for me, is I dropped back to the Fedora 38 template for sys-net. I always like to keep one older copy of the templates around in case I mess things up.
1 Like