Qubes-dom0-update fails to detect release version on all operations

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

sudo qubes-dom0-update --clean qubes-core-dom0-linux qubes-rpm-oxide rpm

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.

Edit: slight formatting changes.

try --releasever=r4.0

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

Which Whonix version are you using?
Does it work if you dont use Whonix as updateVM?

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… :thinking:

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:

  1. Switched to regular URL repos and using sys-firewall2 (static dispVM based on sys-firewall as base dispVM template). This works error-free.
  2. Switched back to sys-whonix with clearnet repos. This one still updates, but has the message.
  3. 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…

@unman thank you! I solved it!

The problem was in using sys-whonix as Dom0’s UpdateVM. Here’s what I did to solve it:

  1. Created a fedora-based AppVM.
  2. Had it supply network and used sys-whonix as an upward NetworkVM.
  3. Set said VM as dom0’s VM
  4. 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.

  1. Created a fedora-based AppVM (dom0-updatevm). Had it have no network access and provided no network.
  2. Set it as a DisposableVM template.
  3. 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.
  4. Set said VM as dom0’s VM.
  5. 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 still run into this issue and running an entire new VM just to update in my limited memory system isn’t sustainable, anyone know of a fix?