Unable to check for updates from dashboard
-
OK, that's good, it has the correct repo pkg. Make sure the branch is set to 'Latest stable version (v2.7.0)'.
Check what version of pkg you have:
pkg-static info pkg
Then check for older cached versions:
ls /var/cache/pkg/pkg*
You will probably have version 1.20.4 installed and hopefully have an older version available.
-
@stephenw10 Output, in order:
pkg-static info pkg pkg-1.20.2 Name : pkg Version : 1.20.2 Installed on : Tue Jul 11 22:53:08 2023 EDT Origin : ports-mgmt/pkg Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : pkg@FreeBSD.org WWW : https://github.com/freebsd/pkg Comment : Package manager Options : DOCS : off Shared Libs provided: libpkg.so.4 Annotations : FreeBSD_version: 1400093 build_timestamp: 2023-07-11T22:24:13+0000 built_by : poudriere-git-3.3.99.20220831 port_checkout_unclean: no port_git_hash : 09a785875a27 ports_top_checkout_unclean: yes ports_top_git_hash: c959ae811528 repo_type : binary repository : pfSense Flat size : 38.8MiB Description : Package management tool WWW: https://github.com/freebsd/pkg
ls /var/cache/pkg/pkg* /var/cache/pkg/pkg-1.17.5_3.pkg /var/cache/pkg/pkg-1.17.5_3~b8e15d34b2.pkg /var/cache/pkg/pkg-1.19.1_1.pkg /var/cache/pkg/pkg-1.19.1_1~d54ac0ca75.pkg /var/cache/pkg/pkg-1.20.2.pkg /var/cache/pkg/pkg-1.20.2~269d0c3235.pkg
-
Ok, good. Make sure the update branch is set to Latest stable (2.7) again. Then force the pkg downgrade at the command line with:
pkg-static add -f /var/cache/pkg/pkg-1.19.1_1.pkg
Then recheck for upgrades.
-
@stephenw10 Awesome - appears that worked:
"
"
I can't run the upgrade right now but I believe you've helped me across the only hurdle. Greatly appreciated! -
Nice
-
Any updates for me.. ?
-
You're still seeing the dash report 'unable to check' but everything working at the CLI?
Have you tried setting IPv4 as preferred?
-
@stephenw10 That is correct. Upgrade from 2.6.0 to 2.7.0 worked fine from the CLI, but the dashboard and the update (system -> update) menu item are still showing "Unable to check for updates"
Sadly I cannot change to IPv4 as preferred as - due to the need to resolve items internally, and the complete lack of 'internal' IPv4 - this is why I need to perform 'smoke and mirrors' tricks to emulate the netgate update system in order to then point to proxies in areas of our network that DO have IPv4 connectivity out.
If there is a way to tell the update check widget to ignore system resolvers and use an internet based system (similar to squids dns_nameservers directive) then I could do this.
This is why I was wanting to know the underlying mechanism that the update widget is employing to check - as, whatever it is seems different from the pkg/pkg-static command line utilities as these are working fine.
This is a diagram of the setup - the DNS server has a 'dummy' version of the netgate SVC records that return a DNS name for the pkg servers, and the proxy is used to reach these. The proxy is squid and has the afor-mentioned DNS directive such that the proxy can resolve internet entries and reach them, yet still be part of the internal domain.This used to work for the widget, but broke somewhere during 2.6.0 and after the transition from files00 and files01 to the new domain name
-
@Nibblet re DNS for pfSense: https://docs.netgate.com/pfsense/en/latest/config/general.html#dns-resolution-behavior
Re: IPv4: https://docs.netgate.com/pfsense/en/latest/config/advanced-networking.html#prefer-ipv4-over-ipv6
“ this option causes the firewall itself to prefer sending traffic to IPv4 hosts instead of IPv6 hosts when a DNS query returns results for both.” Doesn’t affect LAN devices. -
@SteveITS I guess the point here is - that the firewall should never actually get an IPv4 A record response.
The DNS server in this example is not recursive and doesn't actually have A records to return. -
@Nibblet said in Unable to check for updates from dashboard:
this is why I need to perform 'smoke and mirrors' tricks to emulate the netgate update system in order to then point to proxies in areas of our network that DO have IPv4 connectivity out.
Ha well that seems likely to be involved in this error situation!
We are digging into a problem internally though, specifically when using external proxies. Do you have a proxy configured in pfSense?
If you run
pkg-static -d update
via Diag > Command Prompt does it fail there when it succeeds at the real command line?Steve
-
@stephenw10 Really weirdly, it has all started working again. Nothing changed from the perspective of DNS/proxy settings - very strange.
Also, running the update -d command would have worked, except of course that these servers were already updated..
Of note - these are in production with around 40-50 people actively connecting through them so I REALLY don't like running arbitrary commands that update packages. Hopefully this will put to bed that whatever pkg (and pkg-static) and the 'check of updates' widget are doing is different, and the widget is not calling the pkg (or pkg-static) command but rather doing its own thing - do you know where the source code for this widget would be? is there a specific package I can look the sources up for?
DBG(1)[33734]> pkg initialized
Updating pfSense-core repository catalogue...
DBG(1)[33734]> PkgRepo: verifying update for pfSense-core
DBG(1)[33734]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense-core.sqlite'
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/meta.conf
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/meta.conf with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/packagesite.pkg
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/packagesite.pkg with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/packagesite.txz
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/packagesite.txz with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
DBG(1)[33734]> PkgRepo: verifying update for pfSense
DBG(1)[33734]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense.sqlite'
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/meta.conf
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/meta.conf with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.pkg
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.pkg with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.txz
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.txz with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
pfSense repository is up to date.
All repositories are up to date. -
Huh, weird.
The pkg update command only updates the local cached list against the repo. pkg upgrade is required to actually upgrade anything. pkg update gets run every time it checks so everytime you visit the dashboard for example. It is generally safe to run.
Anyway glad you're back up and running.
-
i run pfsense 2.7.0 and i want to upgrade pkg from 1.19.1 to 1.20.6 but an error occurs :
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
if anyone knows how can i fix this please help me .
thank you -
You have to use pkg-static if you are already using a newer version of pkg. But in 2.7 you should be running 1.19.1_2 unless you had the dev branch set at some point.
Steve
-
@stephenw10 thank you
But i did not undrestand what i am supposed to do !! -
If you have a newer version of pkg installed than the base you have to use
pkg-static
instead ofpkg
.So for example:
[2.7.0-RELEASE][admin@pfsense.fire.box]/root: pkg-static info -x pkg pfSense-pkg-Shellcmd-1.0.5_3 pfSense-pkg-Status_Traffic_Totals-2.3.2_3 pfSense-pkg-System_Patches-2.2.4 pfSense-pkg-iperf-3.0.3 pfSense-pkg-nmap-1.4.4_7 pfSense-pkg-openvpn-client-export-1.9 pkg-1.19.1_2
But as you can see there you should have pkg version 1.19.1_2 in 2.7. Why are you trying to install 1.20.6? What version do you have now?
-
@stephenw10 you are right i have pkg 1.19.1_2 .
i want to install wazuh-agent 4.5.0 and when i run pkg-static install wazuh-agent-4.5.0 , this is what i have :
-
Where are you installing that from? That's not the CE pkg repo so it;s pulling in some unknown version of pkg.
-
@stephenw10 i want to install wazuh-agent on my psfense VMware virtual machine
pfsense 2.7.0 release
freeBSD 14