check_upgrade: "Updating repositories metadata" returned error code 1

stephenw10

Hmm, curious...

rpsmith

Same problem here:

PC Engines APU2 Platform ("apu4" model)
Netgate Device ID: 97372676272a13e1bf6f

Everything else seems to be working OK. This system has no packages installed and the WAN is using 100 megabit PPPoE.

RPSmith...

rpsmith

Also, if I set "Disable the dashboard auto-update check", the error does not appear again even after a reboot and I can manually check for an update and still no error so It might be a timing issue during boot-up.

RPSmith...

stephenw10

Yes, it certainly seems like a race condition with the initial upgrade check. But there must be something additional in play to trigger it. I still can't replicate it here....

rpsmith

@stephenw10 ~ I think it will start again if I re-enable "dashboard auto-update check" and I could give you access to the firewall if that would help your troubleshooting.

RPSmith...

stephenw10

I think we're going to need to replicate it locally but if I can't that could be helpful.

rpsmith

@stephenw10 ~ The one I'm seeing this problem on is my one and only PC Engines APU2 Platform ("apu4" model) so it doesn't have much for CPU power and my "Branch" has always been correctly populated. Also, My WAN is PPPoE and I have the new PPPoE service enabled.

RPSmith...

JonnyQuest

I would like to add I am having the same problem after upgrading from 2.7.2 to 2.8.0. The only packages that I had installed were Wireguard and the system patches. Packages were uninstalled then updated. As with the others, the message only shows up again after a reboot.

Running bare metal on a

Dell Wyze 5070 Extended

Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz
Current: 1500 MHz, Max: 1501 MHz
4 CPUs : 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

4 GB DDR4

250GB M.2 SATA used for pfSense
(Internal eMMC not used)

Intel I350-T2 Network card

Very basic configuration (no vlans) with no wireguard at the moment (Did not restore my configuration file yet).

Had no issues running 2.7.2

stephenw10

Also using a pppoe WAN?

And I assume, like the others here, you can still access the repos after boot?

JonnyQuest

@stephenw10

WAN - DHCP

I also noticed the first 3-4 minutes of a reboot the CPU usage is very high at 27-37% then settles down to 2-5% (typical for 2.7.2) then the message pops up. I don't remember that high of a CPU usage with 2.7.2 during the first few minutes, but to be fair I did not reboot much.

I do have "Current Stable Version (2.8.0)" in the Branch dropdown box.

rpsmith

I've seen this error now on multiple PC Engines APU2 Platforms but not on any of my other platforms.

stephenw10

@JonnyQuest said in check_upgrade: "Updating repositories metadata" returned error code 1:

I do have "Current Stable Version (2.8.0)" in the Branch dropdown box.

I mean, for example, if you go to the package manager can you see the list of available packages? The requires querying the configured repos which would fail if it could access them.

rpsmith

I have no problems showing or searching for available packages on the firewall that displays this error.

RPSmith...

JonnyQuest

@stephenw10

I can access the available packages and install with no issues. Installed Wireguard and System_Patches no problem.

pfpv

@stephenw10
I got here by googling the error. I upgraded from 2.7.2 to 2.8.0 CE about a week ago. I uninstalled all packages as instructed and after the upgrade I restored the saved 2.7.2 configuration and the packages were reinstalled automatically. I am on the new PPPoE driver on WAN.

After about a week without any issues, today I logged in to the GUI and it was slow to appear. After I got the interface the dashboard update check was "turning around the circle" forever. I didn't wait until it finished and checked the installed packages for updates but the list of packages never loaded. I stopped waiting and went to check other things (port forwards etc.) Meanwhile, I checked my pi-holes for queries (my DNS goes through pi-holes) and saw plenty of queries to ews.netgate.com, pkg00-atx.netgate.com, pkg01-atx.netgate.com, netgate.com. They were all served IPs.

Then, I went to the dashboard and the update check finished with no updates. That's when I noticed that error at the top. I checked packages and they all loaded this time with no updates. Getting back to the dashboard was still slow. After reading this thread I went to System/Update/System Update and in the line "Retrieving" there was the "turning circle" for quite a long time. After some time I got the following:

"Retrieving: Another instance of pfSense-upgrade is running. Please try again in a few moments."

This is something new. I haven't seen this before. I just went back to the dashboard and found the same message again

check_upgrade: "Updating repositories metadata" returned error code 1

Maybe this can give you an idea of what may be going on here. My system has been up for 6 days and 21 hours when I noticed the above. I also wonder if the new PPPoE driver has anything to do with this as it was mentioned earlier. I guess the simplest explanation could be that the Netgate servers were intermittently down but I doubt it. This was happening on 2025-06-16 between 10 and 10:25am EDT. Now I refreshed the system update page and it came with Status Up to date as expected. Also, strangely I didn't receive Pushover notifications for the errors.

stephenw10

I assume you see available packages if you manually check after that?

Do you only see that error after rebooting?

The 'Another instance of pfSense-upgrade is running' message is expected if the initial update check at boot is still running.

pfpv

@stephenw10
I tried to describe everything carefully. It's all in my post.
Yes, the installed, not the available packages list showed up later.

No, not after rebooting. My system hasn't been rebooted for 6 days and 21 hours. I had logged in to it after the reboot (~7 days ago) and some time after but before today. That's why I thought what was going on today was strange.

stephenw10

Hmm, OK. If you check the available packages now though it shows them?

Alternatively run at the command line: pkg -d update

That will show if you have access to the pkg repos and should should you why it's failing if it does.

pfpv

@stephenw10
I logged in to the GUI again and there was no delay this time. The dashboard update check was relatively fast. I went to System, Package Manager. And it got stuck there without loading anything for longer than I could have expected, for about a minute. Thinking it will not load anything, I opened the Diagnostics, Command Prompt page in a new tab and executed the command you suggested (pkg -d update). The lengthy output is below. It looks like something was not right ("Couldn't find host pkg01-atx.netgate.com in the .netrc file; using defaults" and it tried twice, and "The requested document is not new enough") but in the end it concluded "All repositories are up to date."

After that I switched to the Package Manager tab and found that the list of the installed packages that wasn't loading before now loaded. I clicked on the "Available Packages" and the list loaded reasonably fast.

The output of 'pkg -d update':

DBG(1)[64250]> pkg initialized
Updating pfSense-core repository catalogue...
DBG(1)[64250]> PkgRepo: verifying update for pfSense-core
DBG(1)[64250]> Pkgrepo, begin update of '/var/db/pkg/repos/pfSense-core/db'
DBG(1)[64250]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_8_0_amd64-core/meta.conf
DBG(1)[64250]> curl_open
DBG(1)[64250]> Fetch: fetcher used: pkg+https
DBG(1)[64250]> curl> fetching https://pkg.pfsense.org/pfSense_v2_8_0_amd64-core/meta.conf

DBG(1)[64250]> CURL> attempting to fetch from , left retry 3

* Couldn't find host pkg01-atx.netgate.com in the .netrc file; using defaults
* Host pkg01-atx.netgate.com:443 was resolved.
* IPv6: 2610:160:11:18::209
* IPv4: 208.123.73.209
*   Trying 208.123.73.209:443...
* Connected to pkg01-atx.netgate.com (208.123.73.209) port 443
* ALPN: curl offers http/1.1
*  CAfile: none
*  CApath: /etc/ssl/certs/
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.netgate.com
*  start date: Apr 10 00:00:00 2025 GMT
*  expire date: May 11 23:59:59 2026 GMT
*  subjectAltName: host "pkg01-atx.netgate.com" matched cert's "*.netgate.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha384WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* using HTTP/1.x
> GET /pfSense_v2_8_0_amd64-core/meta.conf HTTP/1.1
Host: pkg01-atx.netgate.com
User-Agent: pkg/1.21.3
Accept: */*
If-Modified-Since: Thu, 22 May 2025 01:27:36 GMT

* Request completely sent off
< HTTP/1.1 200 OK
Fetching meta.conf: < Server: nginx
< Date: Mon, 16 Jun 2025 15:59:53 GMT
< Content-Type: application/octet-stream
< Content-Length: 179
< Last-Modified: Thu, 22 May 2025 01:27:36 GMT
< Connection: keep-alive
< ETag: "682e7d88-b3"
< Strict-Transport-Security: max-age=31536000; preload
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Robots-Tag: all
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Accept-Ranges: bytes
<
* The requested document is not new enough
* Simulate an HTTP 304 response
* Closing connection

DBG(1)[64250]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_8_0_amd64-core/data.pkg
DBG(1)[64250]> curl_open
DBG(1)[64250]> Fetch: fetcher used: pkg+https
DBG(1)[64250]> curl> fetching https://pkg.pfsense.org/pfSense_v2_8_0_amd64-core/data.pkg

DBG(1)[64250]> CURL> attempting to fetch from , left retry 3

* Couldn't find host pkg01-atx.netgate.com in the .netrc file; using defaults
* Hostname pkg01-atx.netgate.com was found in DNS cache
*   Trying 208.123.73.209:443...
* Connected to pkg01-atx.netgate.com (208.123.73.209) port 443
* ALPN: curl offers http/1.1
*  CAfile: none
*  CApath: /etc/ssl/certs/
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.netgate.com
*  start date: Apr 10 00:00:00 2025 GMT
*  expire date: May 11 23:59:59 2026 GMT
*  subjectAltName: host "pkg01-atx.netgate.com" matched cert's "*.netgate.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha384WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* using HTTP/1.x
> GET /pfSense_v2_8_0_amd64-core/data.pkg HTTP/1.1
Host: pkg01-atx.netgate.com
User-Agent: pkg/1.21.3
Accept: */*
If-Modified-Since: Thu, 22 May 2025 01:27:36 GMT

* Request completely sent off
< HTTP/1.1 200 OK
Fetching data.pkg: < Server: nginx
< Date: Mon, 16 Jun 2025 15:59:53 GMT
< Content-Type: application/octet-stream
< Content-Length: 1623
< Last-Modified: Thu, 22 May 2025 01:27:36 GMT
< Connection: keep-alive
< ETag: "682e7d88-657"
< Strict-Transport-Security: max-age=31536000; preload
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Robots-Tag: all
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Accept-Ranges: bytes
<
* The requested document is not new enough
* Simulate an HTTP 304 response
* Closing connection

pfSense-core repository is up to date.
Updating pfSense repository catalogue...
DBG(1)[64250]> PkgRepo: verifying update for pfSense
Waiting for another process to update repository pfSense
All repositories are up to date.

stephenw10

Hmm, well that's the expected behaviour so perhaps you just hit some temporary connectivity issue somewhere.

If it fails again re-run that command to see where it's failing.