check_upgrade: "Updating repositories metadata" returned error code 1

stephenw10

@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.

aGeekhere

@stephenw10 yeah been getting that error a bit ever since upgrading to 2.8.0, never before.

Gertjan

@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 ms

so 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 msec

So 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.

753951

@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.

stephenw10

Ah, that seems like a different issue then; it's actually unable to check.

Try running: pkg -d update

And: pfSense-repoc -ND

See what errors are shown.

753951

@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.

stephenw10

Ok send me your NDI in chat and I'll check it.

renanlofiego

Me too, after the update, I started receiving the message "check_upgrade: "updating repositories metadata" returned error code 1".

I ran the command "pkg -d update" and it returned the following: "DBG(1)[56533]> pkg initialized
pkg: Unable to open '/usr/local/etc/pkg/repos//pfSense.conf': No such file or directory
No active remote repositories configured."

I don't know if it has to do with the license. Is there still a free pfSense+ license for labs?

stephenw10

So same as above; run pfSense-repoc -ND and see what error that returns.

Send me your NDI in chat and I'll check it.

mrpon8

check_upgrade: "Updating repositories metadata" returned error code 1
for resolve this problem only need update the pkg
into the "Diagnostics, then Command Prompt" run "pkg update -f"

renanlofiego

@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."

benhamou.ahmed

i have same issue

benhamou.ahmed

@stephenw10 i have same issue