Fresh installation from FreeBSD-15.0-RELEASE-amd64-mini-memstick.img fails when selecting "Packages (Tech preview)" with "Failed to fetch https://pkgbase.FreeBSD.org/.....": No error I think this is because pkgbase.FreeBSD.org does not resolve to DNS and this host is used as PKGHOST on RELEASE, as per usr.sbin/bsdinstall/Makefile. Linked with bug #291255 following review D53964 and possibly the cause of bug #291452
pkgbase.freebsd.org in the installer is a known bug, that should have been pkg.freebsd.org. However, it should still "work". Is your DNS resolver eating SRV records?
I get the same empty result on A, AAAA, CNAME, SRV and any records with dig, drill, nslookup and ISC host querying my ISP's, Google's, Cloudfare's and FreeBSD.org own authoritative servers, over both IPv4 and IPv6. $ drill pkgbase.FreeBSD.org srv @ns0.FreeBSD.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51065 ;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; pkgbase.FreeBSD.org. IN SRV ;; ANSWER SECTION: ;; AUTHORITY SECTION: FreeBSD.org. 3600 IN SOA ns0.FreeBSD.org. hostmaster.FreeBSD.org. 2025120812 3600 900 1209600 3600 ;; ADDITIONAL SECTION: ;; Query time: 76 msec ;; SERVER: 96.47.72.78 ;; WHEN: Mon Dec 8 13:37:02 2025 ;; MSG SIZE rcvd: 88 $ drill -v drill version 1.9.0 (ldns version 1.9.0) Written by NLnet Labs. Copyright (c) 2004-2008 NLnet Labs. Licensed under the revised BSD license.
pkgbase is an empty non-terminal. The SRV record pkg wants is _http._tcp.pkgbase.freebsd.org. _https._tcp.pkgbase.freebsd.org. 3600 IN SRV 1 100 443 cloudfront.aws.pkgbase.freebsd.org. pkgbase.aws.freebsd.org is delegated to Amazon. Perhaps they broke their DNS again? AWS doesn't exactly have a great record for running reliable infrastructure. (Incidentally: we only have _https._tcp, not _http._tcp. Another thing that was forgotten in the rush.) For the avoidance of doubt: we need to burn pkgbase.freebsd.org to the ground as soon as possible. It's unfortunate that it crept into the release installer and the VM images.
(Typo: it wants _https._tcp.pkgbase.freebsd.org -- we don't have a _http._tcp.pkgbase.freebsd.org. I don't want to add the latter because I want pkgbase to die. I don't want it to grow more things that we'll only have to spend more time burning to the ground.)
Thinking out loud: should we just respin the installer media with pkgbase.freebsd.org replaced with pkg.freebsd.org? I think we did a release media respin once before. People are going to keep running into bugs with this. Ripping off bandaids is no fun but ... the sooner we get rid of pkgbase.freebsd.org, the better.
I made a hypothesis about the cause of the bug a little too quickly without really looking for the cause. I didn't know that pkg performed an SRV query. And indeed, looking at what's happening on the network from the installer, we see successful SRV requests and a TLSv1.3 session with SNI=cloudfront.aws.pkgbase.freebsd.org. However, pkg from the FreeBSD installer seems to send a fatal Bad Certificate alert to Cloudfront and close the connection. In bsdinstaller 15.0-RELEASE /tmp/bsdinstall_log: DEBUG: Running installation step: pkgbase pkg: Failed to fetch https://pkgbase.freebsd.org/FreeBSD:15:amd64/base_release_0/meta.conf: No error pkg: Failed to fetch https://pkgbase.freebsd.org/FreeBSD:15:amd64/base_release_0/meta.txz: No error [...] https://pkgbase.freebsd.org/FreeBSD:15:amd64/base_release_0/packagesite.tzst: No error And "Updating repositories failed, try again?" [Yes/No]
After some debugging with openssl s_client I got "certificate is not yet valid" and I knew ... the motherboard is pristine and so the RTC was set to year 2018. After running ntpdate from the installer console, pkg update works and so the installer. No obvious error was given by "pkg -dd" except for "curl_open, fetcher pkg+https" and then "pkg: Failed to fetch [...]: No Error". When using the binary /usr/bin/fetch that uses the same libfetch than pkg (or pkg-static), it returns "pkgbase.freebsd.org: Address family for host not supported" (and I get it now, the SRV looking is a pkg-specific behaviour). My problem is resolved, the bug may be closed. However, I think the certificate error should be more clearly reported in the pkg logs. (package signing with HTTP was good enough IMHO, and the security of HTTPS here is not obvious: the certificate is checked against whatever the SRV lookup returned and pkg/libfetch resolver does not seem to check for DNSSEC)
just a small clarification: pkg does not use libfetch, but bundles curl
Good catch! And yes ... the only measurable contribution of https to pkg is fragility. :( I think it should be pkg+http but the web browser cartel have successfully bullied everyone into believing that cleartext http is unacceptable on today's internet. We should document somewhere that pkg does not work in the default configuration unless your clock is set correctly.
(thank you for the clarification, I was confused because usr.sbin/pkg in the sources do uses libfetch, but that seems just for bootstrapping the bigger pkg, whose repository lives on Github(!?) outside the source tree. And it is already bootstrapped in the installation medium so). Possibly fixed «upstream» by https://github.com/freebsd/pkg/pull/2559, that was not included in the 15.0 installation medium, closing.