pkg(8): "An error occured while fetching package: No error"

Jim L.

Jim L.

Is this another growing pain of the new pkg(8) program? I can live with it for now, just wondering if anyone else has seen this. I'm not getting any hits from Google on that error message. As the testing shows, the error is intermittent, with no pattern identified as yet.

Code: 
jimsdesk : 06:18:23 /root# pkg-static -v; pkg-static audit -Fq
2.0.5
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 06:25:16 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 06:25:18 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 06:25:19 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 06:25:20 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 06:25:21 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 06:25:22 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 06:25:23 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 06:25:25 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 06:25:26 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 06:25:27 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2

OS is FreeBSD 14.2-STABLE #0 stable/14-n270227-b40ca26721d7.
 
Can you post the output of pkg -vv | grep VULNXML_SITE?

Don't seem to have a problem on my test server:
Code: 
root@fbsd-test:~ # rm /var/db/pkg/vuln.xml
root@fbsd-test:~ # pkg audit -F
Fetching vuln.xml.xz: 100%    1 MiB   1.1MB/s    00:01
0 problem(s) in 0 package(s) found.
root@fbsd-test:~ # pkg -v
2.0.5
 
SirDice said:
Can you post the output of pkg -vv | grep VULNXML_SITE?

Don't seem to have a problem on my test server:
Code: 
root@fbsd-test:~ # rm /var/db/pkg/vuln.xml
root@fbsd-test:~ # pkg audit -F
Fetching vuln.xml.xz: 100%    1 MiB   1.1MB/s    00:01
0 problem(s) in 0 package(s) found.
root@fbsd-test:~ # pkg -v
2.0.5
Click to expand...
Hmmm. Learning things.

1) The error message at reference appears to be the same error pkg(8) gives on a failed DNS lookup:

Code: 
jimsdesk : 07:24:00 /root# grep '^[^#]' /etc/resolv.conf
jimsdesk : 07:24:02 /root# time host vuxml.freebsd.org
;; connection timed out; no servers could be reached

real    0m20.043s
user    0m0.012s
sys 0m0.001s
jimsdesk : 07:24:23 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file

2) Next piece of learning, host(1) will use a resolver on localhost even when /etc/resolv.conf says not to. I was not aware of that.

Code: 
jimsdesk : 07:26:10 /root# service named stop
Stopping named.
Waiting for PIDS: 79543.
jimsdesk : 07:26:13 /root# time host vuxml.freebsd.org
;; connection timed out; no servers could be reached

real    0m20.106s
user    0m0.004s
sys 0m0.009s
jimsdesk : 07:26:38 /root# service named start
Starting named.
jimsdesk : 07:26:44 /root# grep '^[^#]' /etc/resolv.conf
jimsdesk : 07:26:47 /root# time host vuxml.freebsd.org
vuxml.freebsd.org is an alias for web.geo.freebsd.org.
web.geo.freebsd.org has address 204.15.11.70
web.geo.freebsd.org has IPv6 address 2620:11c:5001:1099:1337::20
web.geo.freebsd.org mail is handled by 0 .

real    0m1.319s
user    0m0.009s
sys 0m0.001s

dig(1) also does this:

Code: 
jimsdesk : 07:31:27 /root# time /usr/local/bin/dig vuxml.freebsd.org

; <<>> DiG 9.20.4 <<>> vuxml.freebsd.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56723
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fc6774e924b440d00100000067aa1bd5785a5709ca67fcd5 (good)
;; QUESTION SECTION:
;vuxml.freebsd.org.     IN  A

;; ANSWER SECTION:
vuxml.freebsd.org.  280 IN  CNAME   web.geo.freebsd.org.
web.geo.freebsd.org.    130 IN  A   204.15.11.70

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Mon Feb 10 07:31:33 PST 2025
;; MSG SIZE  rcvd: 112


real    0m0.031s
user    0m0.022s
sys 0m0.008s

drill(1), however, does not disregard /etc/resolv.conf:

Code: 
jimsdesk : 07:31:33 /root# time /usr/bin/drill vuxml.freebsd.org
Error: error sending query: No (valid) nameservers defined in the resolver

real    0m0.007s
user    0m0.000s
sys 0m0.008s

However, tcpdump(1) doesn't appear to be showing any DNS failures when I snoop
traffic on port 53:

Code: 
jimsdesk : 07:36:05 /root# service named stop
Stopping named.
Waiting for PIDS: 79970.
jimsdesk : 07:36:13 /root# grep '^[^#]' /etc/resolv.conf
search example.edu
nameserver 10.10.231.53
jimsdesk : 07:36:17 /root# tcpdump -ni public port 53 &
[3] 79988
jimsdesk : 07:36:30 /root# tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on public, link-type EN10MB (Ethernet), snapshot length 262144 bytes
jimsdesk : 07:36:30 /root# host vuxml.freebsd.org
07:36:42.012841 IP 10.10.161.35.13706 > 10.10.231.53.53: 21135+ A? vuxml.freebsd.org. (35)
vuxml.freebsd.org is an alias for web.geo.freebsd.org.
web.geo.freebsd.org has address 204.15.11.70
07:36:42.229419 IP 10.10.231.53.53 > 10.10.161.35.13706: 21135 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:36:42.229825 IP 10.10.161.35.61331 > 10.10.231.53.53: 13124+ AAAA? vuxml.freebsd.org. (35)
web.geo.freebsd.org has IPv6 address 2620:11c:5001:1099:1337::20
web.geo.freebsd.org mail is handled by 0 .
jimsdesk : 07:36:42 /root# 07:36:42.299775 IP 10.10.231.53.53 > 10.10.161.35.61331: 13124 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
07:36:42.300171 IP 10.10.161.35.61647 > 10.10.231.53.53: 45340+ MX? vuxml.freebsd.org. (35)
07:36:42.300604 IP 10.10.231.53.53 > 10.10.161.35.61647: 45340 2/0/0 CNAME web.geo.freebsd.org., MX . 0 (72)

And likewise, my eyes don't see any DNS failures during *any* of the pkg-static(8) calls, whether
they succeed or not. The only thing I *can* see is that pkg(8) is very quick to report a failure
in those cases when it *does* fail, even before tcpdump(8) has time to spit out the traffic:

Code: 
jimsdesk : 07:36:44 /root# pkg-static audit -Fq
07:36:49.144119 IP 10.10.161.35.14003 > 10.10.231.53.53: 18043+ A? vuxml.freebsd.org. (35)
07:36:49.144629 IP 10.10.231.53.53 > 10.10.161.35.14003: 18043 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:36:49.144727 IP 10.10.161.35.48516 > 10.10.231.53.53: 33371+ AAAA? vuxml.freebsd.org. (35)
07:36:49.145188 IP 10.10.231.53.53 > 10.10.161.35.48516: 33371 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:36:49 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 07:36:52 /root# 07:36:51.964242 IP 10.10.161.35.57432 > 10.10.231.53.53: 5513+ A? vuxml.freebsd.org. (35)
07:36:51.964676 IP 10.10.231.53.53 > 10.10.161.35.57432: 5513 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:36:51.964757 IP 10.10.161.35.22880 > 10.10.231.53.53: 43499+ AAAA? vuxml.freebsd.org. (35)
07:36:51.965026 IP 10.10.231.53.53 > 10.10.161.35.22880: 43499 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
pkg-static audit -Fq
07:36:58.480171 IP 10.10.161.35.56508 > 10.10.231.53.53: 32471+ A? vuxml.freebsd.org. (35)
07:36:58.480687 IP 10.10.231.53.53 > 10.10.161.35.56508: 32471 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:36:58.480771 IP 10.10.161.35.29016 > 10.10.231.53.53: 3362+ AAAA? vuxml.freebsd.org. (35)
07:36:58.481181 IP 10.10.231.53.53 > 10.10.161.35.29016: 3362 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:36:58 /root# pkg-static audit -Fq
07:37:02.908410 IP 10.10.161.35.32252 > 10.10.231.53.53: 52154+ A? vuxml.freebsd.org. (35)
07:37:02.908839 IP 10.10.231.53.53 > 10.10.161.35.32252: 52154 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:37:02.908946 IP 10.10.161.35.62245 > 10.10.231.53.53: 42407+ AAAA? vuxml.freebsd.org. (35)
07:37:02.909250 IP 10.10.231.53.53 > 10.10.161.35.62245: 42407 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:37:03 /root# pkg-static audit -Fq
07:37:06.177298 IP 10.10.161.35.20902 > 10.10.231.53.53: 24583+ A? vuxml.freebsd.org. (35)
07:37:06.177724 IP 10.10.231.53.53 > 10.10.161.35.20902: 24583 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:37:06.177817 IP 10.10.161.35.59856 > 10.10.231.53.53: 55282+ AAAA? vuxml.freebsd.org. (35)
07:37:06.178110 IP 10.10.231.53.53 > 10.10.161.35.59856: 55282 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:37:06 /root# pkg-static audit -Fq
07:37:08.195197 IP 10.10.161.35.37809 > 10.10.231.53.53: 31892+ A? vuxml.freebsd.org. (35)
07:37:08.195540 IP 10.10.231.53.53 > 10.10.161.35.37809: 31892 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:37:08.195673 IP 10.10.161.35.38430 > 10.10.231.53.53: 27307+ AAAA? vuxml.freebsd.org. (35)
07:37:08.195982 IP 10.10.231.53.53 > 10.10.161.35.38430: 27307 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:37:08 /root# pkg-static audit -Fq
07:37:10.202867 IP 10.10.161.35.50356 > 10.10.231.53.53: 47946+ A? vuxml.freebsd.org. (35)
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 07:37:10 /root# 07:37:10.203206 IP 10.10.231.53.53 > 10.10.161.35.50356: 47946 2/0/0 CNAME web.geo.freebsd.org., A 204.15.11.70 (73)
07:37:10.203288 IP 10.10.161.35.38835 > 10.10.231.53.53: 2006+ AAAA? vuxml.freebsd.org. (35)
07:37:10.203591 IP 10.10.231.53.53 > 10.10.161.35.38835: 2006 2/0/0 CNAME web.geo.freebsd.org., AAAA 2620:11c:5001:1099:1337::20 (85)
 
Using a well-known public DNS server doesn't seem to change things. I'm still not getting enough info from pkg(8) to know whether this is DNS-related or not.

Code: 
jimsdesk : 07:56:32 /root# service named stop
Stopping named.
Waiting for PIDS: 80796.
jimsdesk : 07:56:34 /root# grep '^[^#]' /etc/resolv.conf
nameserver 8.8.8.8
jimsdesk : 07:56:43 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:56:56 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:56:58 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2
jimsdesk : 07:57:00 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 07:57:02 /root# pkg-static audit -Fq
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 07:57:05 /root# pkg-static audit -Fq
mariadb1011-server-10.11.10_1
firefox-134.0.2,2

Bottom line, it would be nice if pkg(8) could improve on the diagnostic message "An error occured ...: No error"
 
Maybe it does if you remove the -q option.

Code: 
     -q, --quiet
             Be “quiet”.  Prints only the requested information without
             displaying many hints.
 
SirDice said:
Maybe it does if you remove the -q option.
Click to expand...
Sadly, no:
Code: 
jimsdesk : 08:14:34 /root# pkg-static audit -F
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 08:17:37 /root# pkg-static audit -F
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 08:17:39 /root# pkg-static audit -F
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
jimsdesk : 08:17:41 /root# pkg-static audit -F
vulnxml file up-to-date
mariadb1011-server-10.11.10_1 is vulnerable:
  MariaDB -- DoS vulnerability in InnoDB
  CVE: CVE-2025-21490
  WWW: https://vuxml.FreeBSD.org/freebsd/7bcfca95-e563-11ef-873e-8447094a420f.html

firefox-134.0.2,2 is vulnerable:
  mozilla -- multiple vulnerabilities
  CVE: CVE-2025-1017
  CVE: CVE-2025-1014
  CVE: CVE-2025-1013
  CVE: CVE-2025-1011
  WWW: https://vuxml.FreeBSD.org/freebsd/20485d27-e540-11ef-a845-b42e991fc52e.html

  mozilla -- multiple vulnerabilities
  CVE: CVE-2025-1016
  CVE: CVE-2025-1012
  CVE: CVE-2025-1010
  CVE: CVE-2025-1009
  WWW: https://vuxml.FreeBSD.org/freebsd/e54a1413-e539-11ef-a845-b42e991fc52e.html

3 problem(s) in 2 package(s) found.
 
I had the same issue with pkg 2.0.6. I have a thin jail with FreeBSD 14.2 with latest package repository. I converted the jail to thick one and added lib32 dist files because some packages as 32-bit dependencies (llvm19) but pkg starts to print mesages with the error:

Code: 
An error occured while fetching package: No error

I checked DNS config in /etc/resolv.conf file, delete pkg database ( rm -rf /var/db/pkg/*) and reinstall pkg ( pkg-static bootstrap -f). Nothing worked. The "solution" was remove all /usr/local and /var/db/pkg, rehash the certificates with certctl rehash and run pkg bootstrap again and it worked.

I cannot replicate this issue again, so I don't know if the issue was a damaged base system, curl related issue (HTTP connection, server files?, etc.) or something else.

Also, before the jail was converted it had pkg-2.0.5 and it was upgraded to 2.0.6.
 
Wow, deleting your pkg(8) database (/var/db/pkg/local.sqlite) sounds harsh. For better or worse, I seem to have tracked it down to something that's different between calling pkg-static audit -F and pkg audit -F. This is using pkg(8) 2.0.6 currently. Calling pkg-static still fails indeterminately, but pkg seems to be solid. This was causing me grief in Nagios, so changing my Nagios probe to use pkg instead of pkg-static has cleared things up. So far. Touch wood.
 
I just experienced the same (14.2R-latest):
Code: 
root@q210>1: /usr/local/sbin # pkg-static -v; pkg-static audit -F
2.0.6
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
root@q210>1: /usr/local/sbin # pkg-static -v; pkg audit -F
2.0.6
vulnxml file up-to-date
postgresql16-client-16.6_1 is vulnerable:
  PostgreSQL -- PostgreSQL quoting APIs miss neutralizing quoting syntax in text that fails encoding validation
  CVE: CVE-2025-1094
  WWW: https://vuxml.FreeBSD.org/freebsd/fadf3b41-ea19-11ef-a540-6cc21735f730.html

vscode-1.96.4_2 is vulnerable:
  vscode -- multiple vulnerabilities
  CVE: CVE-2025-24039
  CVE: CVE-2025-24042
  WWW: https://vuxml.FreeBSD.org/freebsd/cbf5d976-656b-4bb6-805f-3af038e2de3e.html

2 problem(s) in 2 package(s) found.
root@q210>1: /usr/local/sbin #
However, haven't been able to reproduce after that; will keep an eye on it.

You could try, for example, set a DEBUG level and try and catch the miscreant in the act*. Something like:
Code: 
# grep DEBUG < /usr/local/etc/pkg.conf
DEBUG_LEVEL=2;
Keep in mind that setting a level > 0 can increase output substantially.

___
* Alternatively, after again such 'misbehaviour' of pkg-static, you could set a DEBUG level and subsequently go back in time, and repeat ;)
 
Got the same as soon as I updated pkg(8) from version 1 to 2.

sh: 
❯ pkg -vv | grep VULNXML_SITE
VULNXML_SITE = "https://vuxml.freebsd.org/freebsd/vuln.xml.xz";

Code: 
❯ pkg audit -F
DBG(1)[33439]> (config) loading repositories in /etc/pkg/
DBG(1)[33439]> (config) loading /etc/pkg//FreeBSD.conf
DBG(1)[33439]> (config) parsing key 'FreeBSD'
DBG(1)[33439]> (config) parsing repository object FreeBSD
DBG(1)[33439]> (config) loading repositories in /usr/local/etc/pkg/repos/
DBG(1)[33439]> (fetch) Request to fetch https://vuxml.freebsd.org/freebsd/vuln.xml.xz
DBG(2)[33439]> (fetch) curl_open
DBG(1)[33439]> (fetch) Fetch: fetcher used: https
DBG(2)[33439]> (fetch) curl> fetching https://vuxml.freebsd.org/freebsd/vuln.xml.xz

DBG(2)[33439]> (fetch) CURL> No mirror set url to https://vuxml.freebsd.org/freebsd/vuln.xml.xz

DBG(2)[33439]> (fetch) CURL> No mirror set url to https://vuxml.freebsd.org/freebsd/vuln.xml.xz

DBG(2)[33439]> (fetch) CURL> No mirror set url to https://vuxml.freebsd.org/freebsd/vuln.xml.xz

pkg: An error occured while fetching package: No error
pkg: cannot fetch vulnxml file
 
Code: 
❯ curl -V
curl 8.12.0 (amd64-portbld-freebsd13.4) libcurl/8.12.0 OpenSSL/1.1.1w zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.64.0
Release-Date: 2025-02-05

It happens in thin jails,
host is ok when doing ❯ pkg audit -F and periodic(8)
related to certs maybe ?
 
Yes indeed certs related for me in thin jails
Code: 
❯ certctl list
Listing Trusted Certificates:
Unable to read *.[0-9]
Encountered 1 errors
 
When you repeat pkg audit -F does it consistently show the same strange/erroneous behaviour; in other words does it produce the same result again and again?
 
Yes, certctl rehash must be the key command, because I used it because I manually removed /usr/local and pkg update printed TLS errors.
 
I have hit the same problem in a jail on a FreeBSD FreeBSD 14.1-RELEASE-p7 host with pkg-2.0.6

Two other jails on the same host do not have that issue. Running certctl rehash also fixed it for me.

These are all thick jails.


[14:32 tallboy-mqtt dvl /var/db/pkg] % sudo pkg-static audit -F
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file
[14:32 tallboy-mqtt dvl /var/db/pkg] % sudo certctl rehash
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
[14:34 tallboy-mqtt dvl /var/db/pkg] % sudo pkg-static audit -F
[tallboy-mqtt.vpn.unixathome.org] Fetching vuln.xml.xz: 100% 1 MiB 1.1MB/s 00:01
0 problem(s) in 0 package(s) found.
[14:34 tallboy-mqtt dvl /var/db/pkg] %
 
That means when a jail is converted from thin to thick one, the certificates hashes are corrupted (pointing to a bad path or they are removed) and it requires run certctl rehash for guarantee a working environment?

The issue is understand why it happens because base.txz contains pre-built certificate hashes.

Which jail manager do you use? I use bastille for mine.
 
joelp said:
That means when a jail is converted from thin to thick one, the certificates hashes are corrupted (pointing to a bad path or they are removed) and it requires run certctl rehash for guarantee a working environment?
Click to expand...

In my case, I'm not convinced this jail was ever a thin jail. If it was, it was converted at least four years ago.

joelp said:
The issue is understand why it happens because base.txz contains pre-built certificate hashes.

Which jail manager do you use? I use bastille for mine.
Click to expand...
I used iocage about four years ago. Now they are plain vanilla jails.

If this a thin-to-think conversion issue the problem has taken years to appear, over multiple OS upgrades.
 
I'm seeing this error after upgrading from pkg 1.x (can't recall) to 2.1. I have tried the rehash and I have valid certs showing up, but no luck:

Code: 
[/tmp]# sudo certctl rehash
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
[root@jruffner /tmp]# certctl list  
Listing Trusted Certificates:
002c0b4f.0      GlobalSign Root R46
0179095f.0      BJCA Global Root CA1
02265526.0      Entrust Root Certification Authority - G2
062cdee6.0      GlobalSign
064e0aa9.0      QuoVadis Root CA 2 G3
06dc52d5.0      SSL.com EV Root Certification Authority RSA R2
08063a00.0      Security Communication RootCA3
09789157.0      Starfield Services Root Certificate Authority - G2
...snipped list of certs

This still fails, either for pkg or pkg-static:

Code: 
[/tmp]# sudo pkg-static audit -F
pkg-static: An error occured while fetching package: No error
pkg-static: cannot fetch vulnxml file

I've tried running ktrace, but I don't see anything useful/obvious in that.
 
So, I tried a simple test of pulling down the files, and this does indeed appear to be a problem with the certs...

[/tmp]# curl -V
curl 8.12.1 (amd64-portbld-freebsd14.2) libcurl/8.12.1 OpenSSL/3.0.15 zlib/1.3.1 brotli/1.1.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.65.0
Release-Date: 2025-02-13
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSLS-EXPORT threadsafe TLS-SRP UnixSockets zstd
[/tmp]# sudo curl https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/packagesite.pkg
curl: (60) SSL certificate problem: certificate is not yet valid
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
Click to expand...

EDIT: Ok, so I'm a dope (didn't check the obvious): my CMOS battery croaked and for whatever reason, my ISP is no longer providing NTP. Pointing at a pool server resolved all...
 
Hi, what is the solution to this problem? I run into the same problem on 14.2 host and tried all the suggestions mentioned here but no success.
 
bxbzq said:
Hi, what is the solution to this problem?
Click to expand...
As you can see above there isn't one definite solution, though the general cause seems to certificate related.

The most important part is trying to figure out what's happening. I'd suggest using truss and/or ktrace to see if you can find something leading up to the error.
 
ShelLuser said:
The most important part is trying to figure out what's happening. I'd suggest using truss and/or ktrace to see if you can find something leading up to the error.
Click to expand...
I will say that working with ktrace revealed nothing (I expect truss would not either) as the problem does seem to be consistently a failure (with no useful error reporting) with the SSL connection to the repo. I think the most useful test is to run curl interactively and try to fetch the file in question directly from the repo - the error reporting will guide you to the real issue. In my case, it was immediately obvious that my clock was wrong when the repo cert was reported as not valid until some future date. An example test:

sudo curl https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/packagesite.pkg
Click to expand...

This approach would also reveal the broken cert hashes that others referenced with earlier iterations of the problem.
 
I can download with no error % sudo curl https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/packagesite.pkg --output packagesite.pkg
Can I use this file to correct pkg issue?
 
OK. The root cause in my case turns out to be the expired proxy settings in /usr/local/etc/pkg.conf. I added a while back when the proxy was still valid. Removing the proxy settings fixes the pkg update problem.
 
You must log in or register to reply here.
Back
Top