Dear friends
I have seen this topic has already been discussed, but solutions do not seem to work for me.
I reinstalled 4.1.1 and dom0 update failed, So tried installing 4.1.2 rc1 and again got the same error on sys-firewall, suggesting to try --releasever=
I tried
sudo qubes-dom0-update --releasever=4.1 or
sudo qubes-dom0-update --releasever=4.1.2
but I always get the same error. What am I doing wrong?
You have not provided any detail of what the error is.
You should also say what template is used by the dom0 updatevm (see
global settings).
You should use the update GUI tool, rather than qubes-dom0-update - I
assume that your qubes-dom0-updater was a typo in your post, rather
than on your machine, even though repeated.
Spending so much time fussing with something you are not versed in and, subsequently NOT providing “the same error” to those who are?
My best “guess” is that you’re simply misinterpreting what you see. Next “guess” is that you aren’t using the necessary CLI flags which, is leading to output which is confusing you.
I did try to copy the error from the sys-firewall window, but it did not let me to copy. So, sorry for my laziness, but, copying manually, it is:
Unable to detect release version (use “–releasever” to specify release)
Fedora 32-x86_84 updates …
Errors during downloading metadata for repository’updates:
then it repeats again the same error
template used by sys-firewall is Debian 11
The dom0 GUI update tool gives the same result
In additions to the errors now reported, Tried to update debian 11 template and it gives similar errors:
Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate…
You chose Fedora-* for your sys-firewall template, yes? Is that version of Fedora EOL?
Quick fix might be to:
A) Create & start an AppVM/DispVM based on debian-*
B) Install the qubes-core-agent-dom0-updates package like this:
# apt install -y qubes-core-agent-dom0-updates
$ sudo apt install -y qubes-core-agent-dom0-updates
C) Open “Qubes Global Settings” and chose the AppVM/DispVM you just installed qubes-core-agent-dom0-updates in
D) Try your update again
many thanks @cayce
You chose
Fedora-*for yoursys-firewalltemplate, yes? Is that version ofFedoraEOL?
No, I am using debian-11
Odd, sounds like this may be a result of an update of your core debian-11 TemplateVM?
Maybe, try this:
A) Start your debian-11 TemplateVM
B) Open a console and login to debian-11
C) Look for any errors upon login
D) Try:
# apt update
E) And, see if you have any messages about broken packages or the like. If so:
# apt --fix-broken install
No, this is brand new installation of 4.1.2 no update yet
I got the following errors, but I see nothing about broken packages:
user@debian-11:~$ sudo apt update
Err:1 https://deb.qubes-os.org/r4.1/vm bullseye InRelease
Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
Err:2 https://deb.debian.org/debian bullseye InRelease
Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security bullseye-security InRelease
Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
Reading package lists... Done
E: Failed to fetch https://deb.debian.org/debian/dists/bullseye/InRelease Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.debian.org/debian-security/dists/bullseye-security/InRelease Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.qubes-os.org/r4.1/vm/dists/bullseye/InRelease Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.
user@debian-11:~$
Haven’t seen other’s running into this issue, sound fubar to me. It’s as if, the proper cert was not installed?
Did you use the latest to install?
I downloaded 4.1.2 a couple of days ago and it passed gpg verification, but it was NOT rc2, it was rc1 as the only one provided on the Qubes download page, when I downloaded it. I did not that a rc2 was available. I imagine you now suggest ot install rc2.
Also a very similar issue with the same error happened a few days ago when I installed version 4.1 stable, even if I only checked sys-firewall, not debian-11. So, if this is a rare issue, as you say, how is it possible that it happens with two very distinct releases?
On a fresh install that’s not happy with it’s cert? Absolutely. Primarily because it’s likely faster than a bunch of troubleshooting + “dirty” manual modifications.
One could manually fetch/verify/supply the cert but …
[deleted]
It literally came out today so of course you didn’t know it a couple of days ago.
What do you get, if you run
date
?
The “not before” and “not after” in the certificate, might cause issues, if the date on your machine is wrong…
Nice catch!
Date is 03 Jan 2044,
we removed for five minutes the battery to reset the computer for boot issues.
I imagine this is the problem. Never thought about it
\Many thanks @ChrisA hris
In that case, my statement really should be updated to:
… that will cause issues with “not after” in the certificates.
Personally I had expected something in Jan 1970 (epoch) or when the BIOS in your machine was released … had I actually read (and not just scrolled quickly), I should have spotted:
