check_upgrade: "Updating repositories metadata" returned error code 1
-
@mrpon8 When I run this command "pkg update -f" it returns this message "pkg: Unable to open '/usr/local/etc/pkg/repos//pfSense.conf': No such file or directory
No active remote repositories configured." -
i have same issue
-
@stephenw10 i have same issue
-
I had same issue for a long time.
Then I tried pkg update -f and got an error for SunnyVally repository
I figured that I had a old version of zenarmor installed that matches the FreeBSD 14 and not 15.
Upgraded the zenarmor to the latest version.Haven't had any of the error messages for some time now. hopefully that was it.
Maybe this can be helpfull to someone.
-
I did a fresh install of 2.8.0 and do not get the error anymore.
-
im on 2.8.0 and i also had no problems
Shell Output - pkg update -f
Updating ntop repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: . done
Processing entries: . done
ntop repository update completed. 6 packages processed.
Updating pfSense-core repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: . done
Processing entries: . done
pfSense-core repository update completed. 4 packages processed.
Updating pfSense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ......... done
Processing entries: .......... done
pfSense repository update completed. 541 packages processed.
All repositories are up to date. -
Same problem here, i'm running 2.8.0 updated from 2.7.2. It also takes much longer to login to dashboard than in previous version.
-
I am also encountering the (check_upgrade: "Updating repositories metadata" returned error code 1) Upgrade Notice after updating from 2.8.0 => 2.8.1
The notice timestamp updates on every reboot even with the dashboard auto-update check disabled. Even if I wait 10 minutes after the reboot before logging into the gui, the notice timestamp is when the system rebooted and not at time of log in.
Also, no repository errors when checking from the cli or the System Update gui. Other than the notice message, everything seems fine.
-
Yup the check that fails is during boot. The alert should be there however long you wait to login. But, yes, it's just ugly. It shouldn't actually be a problem.
-
fwiw, after checking a few other systems I am seeing this exact notice on several other 2.8.0 systems. Now I am geussing the above system had the notice before upgrading to 2.8.1.
-
This post is deleted! -
@SuperTypeGuy said in check_upgrade: "Updating repositories metadata" returned error code 1:
Also, no repository errors when checking from the cli or the System Update gui. Other than the notice message, everything seems fine.
Just chiming in. I came here to report this "check_upgrade: "Updating repositories metadata" returned error code 1 @ 2025-10-01 17:41:46" which is reported on each boot This was for a new host, installed fresh via USB. The config was then updated from backup of the (failed) host it was replacing.
Everything works...but we get this message on every reboot.
-
Point of interest: This may be related to my other issue/unbound. It seems that unbound is taking an inordinately long time to load now on v2.8.1 (1-2 minutes). @Gertjan pointed out that I am running an archaic config with pfBlocker in unbound mode and should update that to "python mode" for speed...
Is there something new with 2.8.2 / unbound / pfBlocker that causes DNS to take too long and therefore isn't available to "pkg update" when it is first run?
-
Hmm, it would certainly hit an error if it's unable to resolve.
Do you have the DNS behaviour set to local DNS only in System > General Setup?
-
@stephenw10 The slow-boot issue I fixed. Not interesting. I fat-fingered an entry in DNS TLS resolver names while working on other issue...
The "check_upgrade" errors on boot persist. However, I've tested every aspect of package management and can identify zero functional issues. Since the firewalls get rebooted on average of once a year, I'll just click "Mark as Read" and call it good.
-
Just for reference do you have DNS set to local only or can it fall back to external?