check_upgrade: "Updating repositories metadata" returned error code 1
-
@stephenw10
This just happened again. I logged in to the GUI (haven't rebooted pfSense for 8 days). The dashboard check took forever. I left it alone for a few minutes. When I returned to the tab the check was finished normally with "no new version". I went to another page in the GUI and noticed that dreaded error at the top of the page. Then I ran 'pkg -d update' and it returned the output similar to what I posted earlier. I went to the package manager and it loaded the list of installed packages fairly quickly. I went to the dashboard and it loaded quickly with "no new version" check.It looks like the issue happens after a prolonged time of not checking for updates and on login. Is somebody else having the same issue?
-
Hmm, so just the alert shown after that? No errors in the system log? Gateway went down?
-
Same problem here with a PC Engines APU4.
No package installed.After upgrading from 2.7.2 to 2.8.0, the bell with check_upgrade: "Updating repositories metadata" returned an error code 1
Doesn't come back after marking as read until next reboot AND click on a menu item.
And yes,
- Available Packages can be seen,
- System update status is "Up to date".
-
Hmm, and that's repeatable after every reboot?
And does it initially show an error in the dashboard widget for updates?
-
@stephenw10
Hello stephenw10,
I’ve been trying to find a way to resolve the issue: check_upgrade: "Updating repositories metadata" returned error code 1
an issue that many users seem to be facing, just like me. Unfortunately, I couldn’t solve it through the WebGUI or by accessing the console via option 8 and using commands like pkg -d update, pkg upgrade, or anything similar.So I ended up leaving the notification bell (next to the top menu bar on the dashboard) as it was—showing that error—for about one or two weeks, if I remember correctly. After that, I tried disabling and re-enabling pfBlockerNG-Devel to refresh its database.
Then I configured and saved new Traffic Shaper settings. At that point, I manually clicked "X – Close and Mark All as Read" on the bell icon to dismiss all notifications.Later, I rebooted the pfSense system. After logging back in to the dashboard, I noticed that the notification bell no longer showed the message (check_upgrade: "Updating repositories metadata" returned error code 1). not on the Dashboard, nor when navigating through other menu sections like System, Interfaces, Firewall, etc.
To be sure, I rebooted the system two or three more times. Normally, I don’t reboot my firewall unless necessary, but this time I wanted to confirm whether the error would return. Surprisingly, the bell notification never came back, and everything has been running smoothly since then.
I still don’t know whether this resolution is directly related to pfBlockerNG-Devel, Traffic Shaper, or a combination of both—but somehow, after these actions, the error never appeared again.
-
Hmm, and prior to that the alert was shown after every reboot?
-
@stephenw10 Yes, prior to that, after every reboot, a notification bell would appear showing the alert: check_upgrade: "Updating repositories metadata" returned error code 1. This happened every time.
Later, when I clicked “X – Close and Mark All as Read” (without rebooting), the system continued to work normally. However, after rebooting again and logging in to the pfSense Dashboard, the bell notification wouldn't appear initially. It only popped up once I clicked on a menu item—such as System, Interfaces, Firewall, or any other menu—and then the notification would show up immediately. After clicking the bell and selecting “X – Close and Mark All as Read” again, everything continued to work normally. This behavior repeated itself after every reboot.
But now, that no longer happens. After every reboot, the bell alert no longer appears, and I can navigate through all menu items without any issues. This change occurred after I disabled and re-enabled pfBlockerNG-Devel and configured the Traffic Shaper.
So, I'm not sure whether this behavior is somehow related to setting the maximum bandwidth values on the WAN, LAN, and OPT interfaces that are used in conjunction with the Traffic Shaper.
-
Same problem with APU2C4.
Fresh installed 2.8 no packages installed.
Also tested 2.7.2 with update to 2.8, always the same message after rebooting.
Setting and deleting traffic shaping doesn‘t help. -
@stephenw10 said in check_upgrade: "Updating repositories metadata" returned error code 1:
Hmm, so just the alert shown after that? No errors in the system log? Gateway went down?
Just now I logged in to the pfSense GUI after not doing it since my last post 11 days ago. pfSense has been working fine from the clients side of view. It took a while to load the interface after entering the username and password. I found 3 errors '"Updating repositories metadata" returned error code 1' from 6/18 06:49, 6/20 07:38 and 6/22 19:37. After going to another menu another such error showed up from the time I logged in. That's probably why it took so long to show the interface. Checking packages and reloading the interface was fast after that.
At least, this happens on every login for me.
I looked for errors. I found that my failover Tier 3 Gateway did go down a few times but the times did not correspond to the times of the errors we are discussing here. That gateway goes down sometimes as it is a cell backup. Another problem I found - I did not get notifications through Pushover. I always did before the upgrade. Maybe I will open another thread about this.
Then, I found a few
unbound 4444 [4444:0] info: service stopped (unbound 1.22.0).lines in the log. 30 milliseconds later I see this
unbound 4444 [4444:0] notice: Restart of unbound 1.22.0.Then, several milliseconds later it stopped again and started again. It did it 3 times in fast succession and then there was a pause for several hours or few days. This doesn't seem to be normal. And again, no notifications through Pushover, although this service is in my Service Watchdog list with notifications. But it seems to recover before the watchdog gets a chance to notice it. Is it normal? Before the upgrade I used DNS Forwarder. Maybe I should go back to it.
Again, the times of unbound stops/starts do not correspond to the time of the errors we are discussing here.
This 2.8.0 update added weirdness but pfSense is working fine otherwise.
-
Keep getting check_upgrade: "Updating repositories metadata" returned error code 1 even if i do not reboot, a get a few errors each day after upgrading to 2.8.0
-
@aGeekhere Do you see anything logged at those times?
@pfpv Seeing Unbound restart is normal if you have anything updating it like dhcp leases resolving or pfBlocker with dnsbl enabled.
However the fact it shows that error at login seems like a clue. I still can't replicate it here though.
-
@stephenw10 yeah been getting that error a bit ever since upgrading to 2.8.0, never before.
-
@pfpv said in check_upgrade: "Updating repositories metadata" returned error code 1:
This doesn't seem to be normal. And again, no notifications through Pushover, although this service is in my Service Watchdog list with notifications. But it seems to recover before the watchdog gets a chance to notice it. Is it normal? Before the upgrade I used DNS Forwarder. Maybe I should go back to it.
Several things here.
It's totally normal that system processes restart.
It could be as simple - but in reality rare - you saving new settings in the GUI : the related process, like unbound will get restarted.
Far more often : if an interface like a LAN or your WAN disconnects, processes that are interface-bound will be restarted. Example : nginx, the GUI web interface, unbound, dhcp, ntp and so on.
Another example : pfBlockerng. This package maintains lists : IP and DNS hostnames (DNSBL). If an IP list changes, a new firewall alias is build, and the firewall rules are reload.
If an DNSBL list changes, they are sorted, doubles are remove, white listed hosts are removed, and unbound gets restart - as it's actually unbound doing the heavy lifting here. pfBlockerng by itself isn't involved in DNSBL filtering.Do yourself a favor : remove "Service Watchdog" from your system. You don't need it. Process don't die, so don't need to be restarted.
If they get restart by the system - see condition above - they are stopped and started.
Only the admin can actually disable or stop a service / prcoess.
If a process fails to start you have a config - or even hardware ? - error. The "Service Watchdog" won't repair your config errors neither hardware error.
"Service Watchdog" is an excellent tool in making your system less stable.@pfpv said in check_upgrade: "Updating repositories metadata" returned error code 1:
DNS Forwarder.
Forwarding exists because our initial ISP connection, way back in the past, was very expensive, metered (bytes were counted) and slow. I stall remember my huge upgrade a "USR Robtics sportster 56 Kbit V34 modem". It was a must have, and expensive.
You had to use the 'close by' ISP DNS "server" (more a DNS cache system).
These day, forwarding isn't needed anymore.
These days, you can use Internet as it was meant to be used and designed.
You resolve.
Recently, other DNS super caches (actually : they are resolvers like unbound) came to live : you know thhem : 8.8.8.8 1.1.1.1 etc etc.
They do not exist to make your live faster or better. The one and only reason they exist is : they want you DNS data, as that is worth a lot of money for them. And true, using a nearby copy of 8.8.8.8 is a bit faster, you'll gain several milli seconds.Let's test with a random host name :
[25.03-BETA][root@pfSense.bhf.tld]/root: dig +trace @127.0.0.1 knmi.nl ....Dd7LgdOqhfK2IJ22a3iyw8ayWsASbITzLE8YM/u5rpiKjA== ;; Received 295 bytes from 192.87.36.2#53(ns2.surfnet.nl) in 29 msso resolving took (for me) 29 ms.
And from now on, knmi.nl is present in the unbound cache, and will get auto refreshed when it's TTL reaches zero.
Test again :[25.03-BETA][root@pfSense.bhf.tld]/root: dig knmi.nl ... ;; ANSWER SECTION: knmi.nl. 28771 IN A 13.248.242.218 knmi.nl. 28771 IN A 76.223.116.179 ;; Query time: 1 msecSo from now on, 1 ms.
And resolving (yourself) offers something which will become one day, in a near feature**, a planet economic live saver : it uses DNSSEC. They day you understand why it its usage is enforced - even in the US all official web site use it now - nearly entire Europe, you will be scared.
** I hope to be wrong of course.
Anonymous said ones : "DNS" is our last resort emergency break, on a world level.
But countries (governments) have already voluntary corrupted (spoofed) DNS 'because they could or though they had to'.Anyway, enough side tracked.
So, conclusion : a couple of "service stopped (unbound 1.22.0)" and "Restart of unbound 1.22.0" isn't harmful.
And its up to you to decide if you don't want this to happen, or to happen more often ^^Keep in mind that a pfSense with a mostly default configuration and no extra pfSense packages installed won't restart unbound, it will keep on running until you reboot pfSense. And that goes for most other processes also.
So, KIS applies as always : keep pfSense as bare bone as possible, and you can actually forget about it for months if not years, only limited to the not so often upgrades and other power outages.
And be ware : consider your pfSense network interfaces : do what ever is needed so they never 'disconnect' or power down.
That's why, if you see a pfSense and a bunch of connected switches, you see an UPS nearby.
A system (pfSense) admin does everything to reach the ultimate admin goal : he does nothing, and is just observing. If he does something, it's planned. A system or network event is by nature a admin's fail.I'm not saying you did something wrong.
Just : go back to the basics, and then build up your system, and test (a lot) between each step. Be ready to step back.
If you have an issue, you'll know when and where it happened.
At that moment a solution is nearby. -
@stephenw10 I'm getting that error for the last week or so, and I'm still on 24.11. If I try to manually check for an update, the branch drop down is empty.
-
Ah, that seems like a different issue then; it's actually unable to check.
Try running:
pkg -d updateAnd:
pfSense-repoc -NDSee what errors are shown.
-
@stephenw10
[24.11-RELEASE][root@pfsense.stanar.info]/root: pkg -d update
DBG(1)[92284]> pkg initialized
pkg: Unable to open '/usr/local/etc/pkg/repos//pfSense.conf':No such file or directory
No active remote repositories configured.As for pfSense-repoc -ND
Messages:
Your device has not been registered for pfSense+. Please purchase a pfSense+ subscription to receive future updates. <a href="https://shop.netgate.com/products/pfsense-software-subscription" target="_blank" rel="noopener noreferrer">Netgate store</a>Don't get it. I made no changes in months.
-
Ok send me your NDI in chat and I'll check it.
