You are not logged in.
I have Arch installed on a chromebook and after a recent reboot I attempted to update with pacman, but the following occurred:
$ sudo pacman -Syu
:: Synchronizing package databases
error: failed retrieving file 'core.db' from mirror.osbeck.com : SSL certificate problem: certificate has expired
error: failed retrieving file 'core.db' from mirror.dc02.hackingand.coffee : SSL certificate problem: certificate has expired
error: failed retrieving file 'core.db' from archmirror01.octyl.net : SSL certificate problem: certificate has expiredand so on for each mirror. I tried enabling all mirrors to see if any would work, but each mirror returned the same certificate error.
When I opened my browser to find a solution, every web query returned an SSL certificate expired error, so I've determined that
the problem is definitely the certificate verification. I was able to perform a full system update by modifying the following in
/etc/pacman.conf
XferCommand = /usr/bin/curl -k -L -C - -f -o %o %u
SigLevel = NeverUpon reboot, the problems persist. I tested my connection by pinging the mirrors:
$ ping mirror.osbeck.com (104.25.95.5) 56(84) bytes of data.
64 bytes from 104.25.95.5: icmp_seq=1 ttl=55 time=14.8msThen I attempted certificate verification with openssl. When connecting through port 80, the verification
returned 0, but on attempting connection through 443, the following occurs:
$ openssl s_client -connect 104.25.95.5:443
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, 0 = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify error:num=10:certificate has expiredfollowed by similar failures and a more verbose message returning the same error code. When I run the exact
same command on my desktop, which is connected to the exact same LAN, verification always succeeds with
return code 1. I'm open to any fix, even disabling verification completely because I really only need my laptop
to be able to push/pull from git repos, update, and use ssh.
Last edited by Nagefire (2020-08-31 04:38:25)
Offline
What's the output of timedatectl?
Offline
Thank you for the quick reply, output:
$ timedatectl status
Failed to query server: Failed to read RTC: Invalid argumentI attempted using time synchronization, which returns a success but the system time remains
the same even after a hard reboot. My timezone is America/Denver or US/Mountain and the
output of date is:
$ date
Thu Sep 23 08:20:20 PM MDT 2094So the problem is obviously something with timedatectl.
Offline
Not something with timedatectl, something with your system time and your RTC. What date is set when you go into the system firmware settings?
Offline
Did you actually look at the 'date' output? There is absolutely no way that time synchronization, which works on sub-second basis, can help when you are 74 years set in the future. Read the section on resetting things with Removing adjtime and manually resetting.
Offline
I'm not sure how to check my firmware because I had to flash Seabios to the chromebook and
I can't make it do much outside of running grub, but thanks to you both I was
able to find some information at https://wiki.archlinux.org/index.php/Sy … local_time
so I followed the advice, installed ntp, and ran
$ ntpd -qgThe time was manually set to the correct value and now everything works as normal. I had obtained this laptop
in Texas and installed arch on it while there, so it's likely that I had the time zone set to America/Chicago and forgot
to switch it to US/Mountain after returning to my home. I'm not sure if the problem will persist, but it seems to be fine now
Last edited by Nagefire (2020-08-31 14:39:06)
Offline
I had obtained this laptop
in Texas and installed arch on it while there, so it's likely that I had the time zone set to America/Chicago and forgot
to switch it to US/Mountain after returning to my home. I'm not sure if the problem will persist, but it seems to be fine now
And just how do you think setting the timezone to America/Chicago sets the time to 74 years into the future?
Offline
I don't know, but I what did happen was I set the timezone and then geographically relocated to another time zone.
My time and date were correct before I moved, so the issue probably had something to do with having the wrong
time zone for my geographical area set.
Offline
no, it didn't.
Offline