Hi. Yesterday I tried downloading qubes-template-debian-10. I foolishly stopped the operation mid-download by pressing ctrl-c. After that all operations using qubes-dom0-update give the same error/warning: Unable to detect release version (use '--releasever' to specify release version). Using --releasever=4.0 or even =4 fails. The flag seems to not work. When I do --releasever=/ the message is simply displayed twice.
I tried to consult the following topic:
After consulting with the topic and trying the answer
the message is still displayed. I even tried repeating it with --action=reinstall, but to no avail. All answers related to this message on the forum seem to be with building Qubes from source, so not applicable to this case.
I suspect I screwed up something. However I’m not sure what or how to fix it. I’d appreciate help on the matter.
Sadly it doesn’t seem to work. I think I really broke something in qubes-dom0-update. I don’t get the same problem when I use dnf directly.
EDIT: It does seem to work. Looks like the message is spurious or something. It detects the flag, yet at the same time it doesn’t…
sudo qubes-dom0-update --releasever=r4.0
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time…
Unable to detect release version (use ‘–releasever’ to specify release version)
Qubes Dom0 Repository (updates) 25 B/s | 162 B 00:06
Errors during downloading metadata for repository ‘qubes-dom0-current’:
- Status code: 404 for http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/**rr4.0**/current/dom0/fc25/repodata/repomd.xml (IP: ******)
Error: Failed to download metadata for repo ‘qubes-dom0-current’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
[Emphasis added by me]
sudo qubes-dom0-update --releasever=4.0
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time…
Unable to detect release version (use ‘–releasever’ to specify release version)
Last metadata expiration check: 0:22:07 ago on Mon Oct 4 *******
Dependencies resolved.
Nothing to do.
Complete!
No packages downloaded
No updates available
As can be seen, it detects it for looking up the URL. But for some reason the error/warning message is still there. I have no idea why.
EDIT: I have no idea what I’m going to do with qubes updates for DOM0. From what I can see in Qube’s salt code it doesn’t pass the release server as an option
I’m using Whonix 16. Didn’t have this problem with whonix 15, now that I think about it. I added 16 just yesterday, which is when this problem started…
Alright. I think the problem is slowly being narrowed down. There seems to be an issue with downloading thing with sys-whonix for some reason. It’s not the onionized repos.
Here’s what I did:
Switched to regular URL repos and using sys-firewall2 (static dispVM based on sys-firewall as base dispVM template). This works error-free.
Switched back to sys-whonix with clearnet repos. This one still updates, but has the message.
Switched to the onionized repos. Same issue as with No. 2
EDIT: I installed the whonix 16 template via salt. I also got a clean installation message. So I have no idea what happened.
I’ll try to create a Fedora-based dom0-updateVM. Then I’ll chain it once to sys-firewall2 and once to sys-whonix. It’ll allow me to see if the problem is me missing the very important whonix instruction - namely that of having the updateVM be Fedora based. This will take me a while…
The problem was in using sys-whonix as Dom0’s UpdateVM. Here’s what I did to solve it:
Created a fedora-based AppVM.
Had it supply network and used sys-whonix as an upward NetworkVM.
Set said VM as dom0’s VM
Sanity check of sudo qubes-dom0-update
This worked fantastically. Then I thought to myself: why not create a named DisposableVM and use that as the UpdateVM? Reason being I want an ephemeral update process for dom0. If something goes wrong in the cube it doesn’t persist after shutdown. So I set up such a VM. Here is what I did:
0. Deleted the previous permanent UpdateVM. This was done to start from a clean, trusted slate.
Created a fedora-based AppVM (dom0-updatevm). Had it have no network access and provided no network.
Set it as a DisposableVM template.
Created a new, named DisposableVM (dom0-updatevm2). It uses the previously mentioned VM as its template base. This one has network access. It also provides network.This one is the one connected to sys-whonix.
Set said VM as dom0’s VM.
Sanity check of sudo qubes-dom0-update.
Now it work!
Such a setup allows for an onionized repository access. It also allows for a relatively smooth update process for dom0. It also ensures that if something goes awry during the update nothing stays permanent.
There is one major downside, though. That is, the metadata isn’t permanent. Between shutdowns the local cache gets deleted. Whether or not this downside is worth it is, I feel, out of place for this thread. Correction. The metadata is impermanent either way.
Update: I’m opting back to a regular UpdateVM. I’m sure the cache being ephemeral will subtly break something which I’m not aware of. The cache is ephemeral either way. Never mind. I might as well just opt for the static DisposableVM solution.
I’ve got the same problem, happened exactly after I installed whonix-gw-16 following the instructions on the Whonix wiki. This is the error that I’m getting:
[user@dom0 ~]$ sudo qubes-dom0-update
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time...
Unable to detect release version (use '--releasever' to specify release version)
Last metadata expiration check: 0:00:21 ago on Thu Oct 7 20:15:56 2021.
Dependencies resolved.
Nothing to do.
Complete!
*** ERROR while receiving updates:
Error canonicalizing /var/tmp/qubes-updates-tmplhubwhkr.UNTRUSTED/qubes-template-whonix-ws-16-4.0.6-202109211111.noarch.rpm
--> if you want to use packages that were downloaded correctly, use dnf directly now
Hope someone can outline a solution as qubes-dom0-update is broken now for me.
I followed the advise above to make a new qube and then use it as the default UpdateVM for dom0 and I was able to install whonix-ws-16 however after it gets installed I end up with the same problem
[user@dom0 ~]$ sudo qubes-dom0-update
Using new-updatevm as UpdateVM to download updates for Dom0; this may take some time...
Last metadata expiration check: 1:18:06 ago on Fri Oct 8 02:05:46 2021.
Dependencies resolved.
Nothing to do.
Complete!
*** ERROR while receiving updates:
Error canonicalizing /var/tmp/qubes-updates-tmp8yg9sb9s.UNTRUSTED/qubes-template-debian-11-4.0.6-202109010214.noarch.rpm
--> if you want to use packages that were downloaded correctly, use dnf directly now
Another update: After installing whonix-ws-16 broke qubes-dom0-update again for me I decided to retry that advise above and make a bran new update VM for dom0, then if one runs qubes-dom0-update again it will work correctly again. Not sure if this will persists.
Also whenever I switch to sys-whonix as the default updateVM I get that same error again.
I tried the “solved” answer of switching to sys-firewall for dom0 updates, same results.
I’m also not getting the message saying I’m all up to date I used to get in 4.0.4, so I’m assuming there’s some updates to dom0 since 4.1rc3 release that I’m not getting? Or is it safe to ignore this warning?
Despite this, I was able to run the updater in the system tray and successfully update fedora 38.
EDIT: oh wait, nevermind. I just realized I haven’t onionized the other templates.
I am kind of curious why you would provide the option to update Qubes through whonix but not do it through onions. What is there to gain from routing updates through tor that you don’t get if you route the connections through onions?
EDIT 2:
Here’s what debian 11 template says after i onionize updates
$ sudo apt update && sudo apt full-upgrade
Hit:1 https://deb.debian.org/debian bullseye InRelease
Get:2 https://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 https://deb.debian.org/debian-security bullseye-security/main amd64 Packages [264 kB]
Get:4 https://deb.debian.org/debian-security bullseye-security/main Translation-en [171 kB]
Fetched 484 kB in 6s (85.4 kB/s)
Reading package lists... Done
E: The method driver /usr/lib/apt/methods/tor+http could not be found.
N: Is the package apt-transport-tor installed?
E: Failed to fetch tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/vm/dists/bullseye/InRelease
E: Some index files failed to download. They have been ignored, or old ones used instead
EDIT 3: sudo apt install apt-transport-tor seems to have solved the problem for debian. if I just knew what the fedora equivalent of apt-transport-tor is maybe i could fix dom0 and fedora 38
The onion mirrors are sometimes less reliable than the primary ones (e.g., there have been times when they were outdated compared to the primary ones). When updating over Tor and using the primary (non-onion) repos, you still get the benefits described here:
