check_upgrade: "Updating repositories metadata" returned error code 1
-
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?
