Unable to check for updates
-
pkg-static -d updateIt was working well for me, thanks.
Have a look on my output now, perhaps it will work for you too if the repo is up again;
[23.01-RELEASE][root@xxxx.xxxx]/root: pkg-static -d update DBG(1)[19878]> pkg initialized Updating pfSense-core repository catalogue... DBG(1)[19878]> PkgRepo: verifying update for pfSense-core DBG(1)[19878]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense-core.sqlite' DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-core/meta.conf DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_amd64-core/meta.conf with opts "i" DBG(1)[19878]> Fetch: fetcher chosen: https DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-core/packagesite.pkg DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_amd64-core/packagesite.pkg with opts "i" DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-core/packagesite.txz DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_amd64-core/packagesite.txz with opts "i" pfSense-core repository is up to date. Updating pfSense repository catalogue... DBG(1)[19878]> PkgRepo: verifying update for pfSense DBG(1)[19878]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense.sqlite' DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/meta.conf DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg01.atx.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/meta.conf with opts "i" DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/packagesite.pkg DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg01.atx.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/packagesite.pkg with opts "i" DBG(1)[19878]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/packagesite.txz DBG(1)[19878]> opening libfetch fetcher DBG(1)[19878]> Fetch > libfetch: connecting DBG(1)[19878]> Fetch: fetching from: https://pfsense-plus-pkg01.atx.netgate.com/pfSense_plus-v23_01_amd64-pfSense_plus_v23_01/packagesite.txz with opts "i" pfSense repository is up to date. All repositories are up to date. -
The configured update was disabled by Netgate to stop people from bricking their devices due to a problem with the update. This was covered by a netgate staffer earlier.
Presumably, once they've resolved that, the main site will no longer report unavailable.
If you want to try and outsmart them by running shell commands, which may find a method that they haven't updated, because their devices don't try it by default, please do so at your own risk.
-
Thanks for the information.
I updated my pfSense.conf again to account for your url of "...https://pfsense-plus-pkg.netgate.com..."
This resulted in the following:
DBG(1)[28253]> pkg initialized Updating pfSense-core repository catalogue... DBG(1)[28253]> PkgRepo: verifying update for pfSense-core DBG(1)[28253]> PkgRepo: need forced update of pfSense-core DBG(1)[28253]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense-core.sqlite' DBG(1)[28253]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pkg/pfSense_plus-v23_01_aarch64-core/meta.conf DBG(1)[28253]> opening libfetch fetcher DBG(1)[28253]> Fetch > libfetch: connecting DBG(1)[28253]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pkg/pfSense_plus-v23_01_aarch64-core/meta.conf with opts "i" Certificate verification failed for /C=US/ST=Texas/L=Austin/O=Rubicon Communications, LLC (Netgate)/OU=pfSense Plus/CN=pfsense-plus-pkg00.atx.netgate.com 1086423040:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/var/jenkins/workspace/pfSense-Plus-snapshots-23_01-main/sources/FreeBSD-src-plus-RELENG_23_01/crypto/openssl/ssl/statem/statem_clnt.c:1921: DBG(1)[28253]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pkg/pfSense_plus-v23_01_aarch64-core/meta.conf with opts "i" Certificate verification failed for /C=US/ST=Texas/L=Austin/O=Rubicon Communications, LLC (Netgate)/OU=pfSense Plus/CN=pfsense-plus-pkg00.atx.netgate.com 1086423040:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/var/jenkins/workspace/pfSense-Plus-snapshots-23_01-main/sources/FreeBSD-src-plus-RELENG_23_01/crypto/openssl/ssl/statem/statem_clnt.c:1921: DBG(1)[28253]> Fetch: fetching from: https://pfsense-plus-pkg00.atx.netgate.com/pkg/pfSense_plus-v23_01_aarch64-core/meta.conf with opts "i" Certificate verification failed for /C=US/ST=Texas/L=Austin/O=Rubicon Communications, LLC (Netgate)/OU=pfSense Plus/CN=pfsense-plus-pkg00.atx.netgate.com 1086423040:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/var/jenkins/workspace/pfSense-Plus-snapshots-23_01-main/sources/FreeBSD-src-plus-RELENG_23_01/crypto/openssl/ssl/statem/statem_clnt.c:1921: DBG(1)[28253]> Request to fetch pkg+https://pfsense-plus-pkg.netgate.com/pkg/pfSense_plus-v23_01_aarch64-core/meta.txz ... Unable to update repository pfSense Error updating repositories!The certificate error may be the issue?
I think the main difference being you're on amd64 and I'm on arm64 for a Netgate2100 which as above commenters have been stating that it's currently problematic for this branch.
jonathan.johnson
Netgate 2100
pfSense+ 22.05 (arm64) -
I only want to say to @TheGushi that not only the arm repo is not available, nothing more.
-
@jonathan-johnson said in Unable to check for updates:
I think the main difference being you're on amd64 and I'm on arm64 for a Netgate2100 which as above commenters have been stating that it's currently problematic for this branch.
Not problematic. The upgrade path is turned off while our engineers work on a solution to the storage space issue faced on some devices.
To upgrade to 23.01 right now on the 1100 and 2100 you have to request the image from TAC, back up your config, write the new image to your device, restore your backup config and reboot.
If you wish to maintain ZFS snapshots and roll-back capability you will have to wait for the online upgrade to be released.
-
Sorry if I missed it but has there been any resolution found?
There's no DNS issues that i've found, but I can say that https://repo.netgate.com/ could not resolve and https://firmware.netgate.com/ was able to populate.
Is the repo just down and my timing on the initial setup was just bad?
-
@tshaw256 said in Unable to check for updates:
Sorry if I missed it but has there been any resolution found?
At the moment there is no resolution. Please follow https://forum.netgate.com/topic/178049/pfsense-plus-23-01-updates-on-the-1100-and-2100-systems for any updates. Use the Bell icon on the top of any page to follow a topic.
-
@dobby_ OHHH so it's down at the moment? I have a 2100. If so, any timeframe on this by chance?
thanks!
-
@tshaw256 said in Unable to check for updates:
If so, any timeframe on this by chance?
When it's done it will be done.
-
@rcoleman-netgate "When it's done it will be done." ? I see this comment it's 7 days ago, at least netgate could send a banner about this issue. It cannot be that we're stuck in this, is there any update on this matter?
-
@anak1n https://forum.netgate.com/topic/178080/unable-to-check-for-updates/21
You can install from USB if you don’t want to wait. They need to make sure it will properly abort on affected devices. -
S SteveITS referenced this topic on
-
S SteveITS referenced this topic on
-
@anak1n Yeah it threw me off too, BUT, the v22 for the 2100 is working. I can vouch for that at least. v23 is not yet.
-
@tshaw256 That’s the other thing…unless someone needs a new feature 22.05 will continue to work and has the security patches backported. If they do need something new, or a package installed, the USB install works fine.
If Netgate had caught this before release* and just said 23.01 would be ready mid March then, no issues. :)
*at the time (at release) Netgate staff posted they couldn’t duplicate the problem which makes it hard to catch in testing. Obviously it affects a lot in the wild…my 2100 among them. And several of our clients judging by the partition sizes.
-
Having read more about this, I'm sort of fascinated by it (because nerd).
Netgate has a whole product team managing this that I'm sure will figure it out, but right now, there's a limitation in how pkg itself works that there's no way to just send a message, or say "there are updates, but you can't install them because of reasons".
Packages can't do things like require a set amount of disk space, or a set partition layout, or a set type of boot environment (uefi or bios). There's no mechanism to check these when pulling packages down.
I've thought of hacky ways around this, like installing a pkg that in turn ran a script that installed a "pseudo package" that met requirements if your root partition were big enough.
In production at work where I have distant machines with no remote hands, I've totally solved this issue by booting into a ramdisk with MFSbsd, ssh'ing back in, paving over the existing layout, then re-downloading the OS. Yes, this could be automated (but I didn't). Yes, this will brick your device if it goes wrong, but so will interrupting any update, really.
I've referred to this process (with a nod to ancient egypt) as "getting the brain out through the nose, then getting a new one back in the same way."
But again, making a package that does all that is way harder. Packages really can only have preinstall and postinstall scripts, and once the preinstall script is running, it can't really "nope out" and refuse to install.
That would be a very sidesteppy process that would have to be built into pfsense from an earlier version, and qa'd and tested. If we're at the point where we're telling people to restore from backup, telling them to break out their serial cables and run a script is not much better.
I am surprised that I can't check for updates in my existing release train, but that is perhaps just an overabundance of caution.
-
@thegushi Hmm, so a 22.05.02 that only adds a check for, and shows a warning on, devices with the (in hindsight, absurdly) small EFI partition? And then prevents updating to 23.01.
-
@steveits Right -- and if the partition scheme is okay, adds a "fake" package (i.e. runs a shell script to add manually) a pkg that cannot be installed normally from the repos, which 23.xx requires.
Hacky, yes, but until pkg in base FreeBSD gets fixed to be able to check more things, that would be how I went about it if I had a fleet of these in end-user places that I didn't have access to.
-
Dang this sucks. Hopefully, they have a fix soon.
https://forum.netgate.com/topic/178049/pfsense-plus-23-01-updates-on-the-1100-and-2100-systems
Says that if disk 1 is over 800k. It shouldnt be an issue. But mine is 200M and its still an issue.
=> 1 15273599 mmcsd0 MBR (7.3G)
1 409600 1 efi (200M)
409601 70012 2 fat32 (34M)
479613 14793987 3 freebsd [active] (7.1G)=> 0 14793987 mmcsd0s3 BSD (7.1G)
0 16 - free - (8.0K)
16 14793971 1 freebsd-zfs (7.1G) -
@emptyinbox I don't know if I fixed it or just well timed but I copied
/usr/local/share/pfSense/pkg/repos/pfSense-repo.conf
from a working 6100 and approx 30 mins later. I had updates and packages. Updates don't allow 23.01 but I think that's intentional. OK by me I just really needed ovpn package.
-
Ah thanks for the correction and the clarification! I'll look into requesting the 23.01 image from TAC.
