Got the following error message:
***GOT REQUEST TO UPGRADE***
Currently running OPNsense 26.1.11_10 (amd64) at Wed Jul 15 12:45:08 UTC 2026
Fetching packages-26.7-amd64.tar: ... failed, signature invalid
***DONE***
After doing what exactly?
Sit on 26.1.11_10 and upgrade to 26.7.
I'll do a clean reboot now and try the upgrade to 26.7 again.
Next report in about 20min ......
Ok, after reboot the second try was successful.
Now I use 26.7.
Need to look at the little repo issues.
Saw a thread with it. Need to read.
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.7 (amd64) at Wed Jul 15 17:05:11 UTC 2026
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 928 packages processed.
Updating SunnyValley repository catalogue...
pkg: Repository SunnyValley has a wrong packagesite, need to re-create database
pkg: An error occurred while fetching package: Unknown error
pkg: An error occurred while fetching package: Unknown error
Unable to update repository SunnyValley
Error updating repositories!
***DONE***
Reboot isn't helping here at all. The same (exactly the same initial problem with invalid signature) is repeated again and again.
Zenarmor is not yet ready for 26.7, read official statement here https://forum.opnsense.org/index.php?topic=52376.0, and more about in the Zenarmor category.
Can you specify "same"? There are number of topics about LTE downloads not working correctly with libfetch for example. It could also be defunct IPv6. Or maybe you refer to "Unable to update repository SunnyValley" which is a very different issue and several threads exist, also where they actually belong.
Cheers,
Franco
Tried also changing to different mirrors in settings tab and rebooting, after that move it says different error.
Nothing else was touched.
---------------
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.11_10 (amd64) at Wed Jul 15 20:58:32 EEST 2026
Fetching changelog information, please wait... done
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
Updating FreeBSD-ports repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
FreeBSD-ports repository update completed. 37821 packages processed.
Updating FreeBSD-ports-kmods repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ... done
Processing entries: .......... done
FreeBSD-ports-kmods repository update completed. 239 packages processed.
Updating OPNsense repository catalogue...
pkg: Repository OPNsense has a wrong packagesite, need to re-create database
Unable to update repository OPNsense
Updating SunnyValley repository catalogue...
pkg: Repository SunnyValley has a wrong packagesite, need to re-create database
Waiting for another process to update repository SunnyValley
Error updating repositories!
Upgrading package manager from version '2.3.1_1' to ''
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
Updating OPNsense repository catalogue...
pkg: Repository OPNsense has a wrong packagesite, need to re-create database
Unable to update repository OPNsense
Error updating repositories!
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
Updating FreeBSD-ports repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
FreeBSD-ports repository update completed. 37821 packages processed.
Updating FreeBSD-ports-kmods repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ... done
Processing entries: .......... done
FreeBSD-ports-kmods repository update completed. 239 packages processed.
Updating OPNsense repository catalogue...
pkg: Repository OPNsense has a wrong packagesite, need to re-create database
Unable to update repository OPNsense
Updating SunnyValley repository catalogue...
pkg: Repository SunnyValley has a wrong packagesite, need to re-create database
Unable to update repository SunnyValley
Error updating repositories!
***DONE***
Can you do a health check? It already looks like it updated the kernel and now you're in an inconsistent state.
Cheers,
Franco
Quote from: franco on July 15, 2026, 08:11:15 PMCan you do a health check? It already looks like it updated the kernel and now you're in an inconsistent state.
Cheers,
Franco
It really does look like it got updated partially after all (whichiis really weird, GUI never showed up even a succesful start of updating progress, only exactly the same error than user notspam in initial message). Health check log can be found below:
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_10 (amd64) at Wed Jul 15 21:13:25 EEST 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered base files
Error 2 occurred.
etc/ssl/certs/002c0b4f.0:
type (file, link)
etc/ssl/certs/0179095f.0:
type (file, link)
etc/ssl/certs/062cdee6.0:
type (file, link)
etc/ssl/certs/064e0aa9.0:
type (file, link)
etc/ssl/certs/06dc52d5.0:
type (file, link)
etc/ssl/certs/09789157.0:
type (file, link)
etc/ssl/certs/0a775a30.0:
type (file, link)
etc/ssl/certs/0b1b94ef.0:
type (file, link)
etc/ssl/certs/0b9bc432.0:
type (file, link)
etc/ssl/certs/0bf05006.0:
type (file, link)
etc/ssl/certs/0f5dc4f3.0:
type (file, link)
etc/ssl/certs/0f6fa695.0:
type (file, link)
etc/ssl/certs/1001acf7.0:
type (file, link)
etc/ssl/certs/14bc7599.0:
type (file, link)
etc/ssl/certs/1cef98f5.0:
type (file, link)
etc/ssl/certs/1d3472b9.0:
type (file, link)
etc/ssl/certs/1e08bfd1.0:
type (file, link)
etc/ssl/certs/1e09d511.0:
type (file, link)
etc/ssl/certs/2923b3f9.0:
type (file, link)
etc/ssl/certs/2ae6433e.0:
type (file, link)
etc/ssl/certs/2ccbdda3.0:
type (file, link)
etc/ssl/certs/30e1580d.0:
type (file, link)
etc/ssl/certs/32888f65.0:
type (file, link)
etc/ssl/certs/3bde41ac.0:
type (file, link)
etc/ssl/certs/3e359ba6.0:
type (file, link)
etc/ssl/certs/3fb36b73.0:
type (file, link)
etc/ssl/certs/40193066.0:
type (file, link)
etc/ssl/certs/4042bcee.0:
type (file, link)
etc/ssl/certs/406c9bb1.0:
type (file, link)
etc/ssl/certs/48bec511.0:
type (file, link)
etc/ssl/certs/4b718d9b.0:
type (file, link)
etc/ssl/certs/4bfab552.0:
type (file, link)
etc/ssl/certs/5443e9e3.0:
type (file, link)
etc/ssl/certs/54657681.0:
type (file, link)
etc/ssl/certs/5860aaa6.0:
type (file, link)
etc/ssl/certs/5931b5bc.0:
type (file, link)
etc/ssl/certs/5f15c80c.0:
type (file, link)
etc/ssl/certs/5f618aec.0:
type (file, link)
etc/ssl/certs/607986c7.0:
type (file, link)
etc/ssl/certs/616816f6.0:
type (file, link)
etc/ssl/certs/6805c744.0:
type (file, link)
etc/ssl/certs/68dd7389.0:
type (file, link)
etc/ssl/certs/6a9bdba3.0:
type (file, link)
etc/ssl/certs/6d41d539.0:
type (file, link)
etc/ssl/certs/6fa5da56.0:
type (file, link)
etc/ssl/certs/749e9e03.0:
type (file, link)
etc/ssl/certs/75d1b2ed.0:
type (file, link)
etc/ssl/certs/7719f463.0:
type (file, link)
etc/ssl/certs/773e07ad.0:
type (file, link)
etc/ssl/certs/7a3adc42.0:
type (file, link)
etc/ssl/certs/7a780d93.0:
type (file, link)
etc/ssl/certs/7f3d5d1d.0:
type (file, link)
etc/ssl/certs/7fa05551.0:
type (file, link)
etc/ssl/certs/8160b96c.0:
type (file, link)
etc/ssl/certs/8508e720.0:
type (file, link)
etc/ssl/certs/865fbdf9.0:
type (file, link)
etc/ssl/certs/878d9bca.0:
type (file, link)
etc/ssl/certs/8cb5ee0f.0:
type (file, link)
etc/ssl/certs/8d89cda1.0:
type (file, link)
etc/ssl/certs/8f103249.0:
type (file, link)
etc/ssl/certs/9046744a.0:
type (file, link)
etc/ssl/certs/90c5a3c8.0:
type (file, link)
etc/ssl/certs/930ac5d2.0:
type (file, link)
etc/ssl/certs/9482e63a.0:
type (file, link)
etc/ssl/certs/9846683b.0:
type (file, link)
etc/ssl/certs/988a38cb.0:
type (file, link)
etc/ssl/certs/9b46e03d.0:
type (file, link)
etc/ssl/certs/9bf03295.0:
type (file, link)
etc/ssl/certs/9d04f354.0:
type (file, link)
etc/ssl/certs/9e654b62.0:
type (file, link)
etc/ssl/certs/9ef4a08a.0:
type (file, link)
etc/ssl/certs/9f727ac7.0:
type (file, link)
etc/ssl/certs/a09a51ae.0:
type (file, link)
etc/ssl/certs/a3418fda.0:
type (file, link)
etc/ssl/certs/a89d74c2.0:
type (file, link)
etc/ssl/certs/a94d09e5.0:
type (file, link)
etc/ssl/certs/b0d5255e.0:
type (file, link)
etc/ssl/certs/b0e59380.0:
type (file, link)
etc/ssl/certs/b433981b.0:
type (file, link)
etc/ssl/certs/b7a5b843.0:
type (file, link)
etc/ssl/certs/b81b93f0.0:
type (file, link)
etc/ssl/certs/b8d25de6.0:
type (file, link)
etc/ssl/certs/bf53fb88.0:
type (file, link)
etc/ssl/certs/c01eb047.0:
type (file, link)
etc/ssl/certs/c28a8a30.0:
type (file, link)
etc/ssl/certs/ca6e4ad9.0:
type (file, link)
etc/ssl/certs/cbf06781.0:
type (file, link)
etc/ssl/certs/cc450945.0:
type (file, link)
etc/ssl/certs/cd58d51e.0:
type (file, link)
etc/ssl/certs/cd8c0d63.0:
type (file, link)
etc/ssl/certs/ce5e74ef.0:
type (file, link)
etc/ssl/certs/d4dae3dd.0:
type (file, link)
etc/ssl/certs/d52c538d.0:
type (file, link)
etc/ssl/certs/d6325660.0:
type (file, link)
etc/ssl/certs/da0cfd1d.0:
type (file, link)
etc/ssl/certs/dc4d6a89.0:
type (file, link)
etc/ssl/certs/dd8e9d41.0:
type (file, link)
etc/ssl/certs/ddcda989.0:
type (file, link)
etc/ssl/certs/de6d66f3.0:
type (file, link)
etc/ssl/certs/e18bfb83.0:
type (file, link)
etc/ssl/certs/e35234b1.0:
type (file, link)
etc/ssl/certs/e36a6752.0:
type (file, link)
etc/ssl/certs/e73d606e.0:
type (file, link)
etc/ssl/certs/e868b802.0:
type (file, link)
etc/ssl/certs/e8de2f56.0:
type (file, link)
etc/ssl/certs/ecccd8db.0:
type (file, link)
etc/ssl/certs/ed858448.0:
type (file, link)
etc/ssl/certs/eed8c118.0:
type (file, link)
etc/ssl/certs/ef954a4e.0:
type (file, link)
etc/ssl/certs/f0c70a8d.0:
type (file, link)
etc/ssl/certs/f30dd6ad.0:
type (file, link)
etc/ssl/certs/f44703f1.0:
type (file, link)
etc/ssl/certs/f51bb24c.0:
type (file, link)
etc/ssl/certs/fb717492.0:
type (file, link)
etc/ssl/certs/fc5a8f99.0:
type (file, link)
etc/ssl/certs/fd64f3fc.0:
type (file, link)
etc/ssl/certs/fe8a2cd8.0:
type (file, link)
etc/ssl/certs/feffd413.0:
type (file, link)
etc/ssl/certs/ff34af3f.0:
type (file, link)
etc/ssl/certs/ffdd40f9.0:
type (file, link)
etc/ssl/untrusted/02265526.0:
type (file, link)
etc/ssl/untrusted/0b7c536a.0:
type (file, link)
etc/ssl/untrusted/0d972af8.0:
type (file, link)
etc/ssl/untrusted/106f3e4d.0:
type (file, link)
etc/ssl/untrusted/1422d63c.0:
type (file, link)
etc/ssl/untrusted/1766e401.0:
type (file, link)
etc/ssl/untrusted/19dbc0dd.0:
type (file, link)
etc/ssl/untrusted/244b5494.0:
type (file, link)
etc/ssl/untrusted/2d803388.0:
type (file, link)
etc/ssl/untrusted/2dab9e33.0:
type (file, link)
etc/ssl/untrusted/3136ea36.0:
type (file, link)
etc/ssl/untrusted/3323bb7e.0:
type (file, link)
etc/ssl/untrusted/3513523f.0:
type (file, link)
etc/ssl/untrusted/40547a79.0:
type (file, link)
etc/ssl/untrusted/442adcac.0:
type (file, link)
etc/ssl/untrusted/4632c230.0:
type (file, link)
etc/ssl/untrusted/4c3cbf99.0:
type (file, link)
etc/ssl/untrusted/4f316efb.0:
type (file, link)
etc/ssl/untrusted/5a4d6896.0:
type (file, link)
etc/ssl/untrusted/5ad8a5d6.0:
type (file, link)
etc/ssl/untrusted/5c79eb85.0:
type (file, link)
etc/ssl/untrusted/5e98733a.0:
type (file, link)
etc/ssl/untrusted/626dceaf.0:
type (file, link)
etc/ssl/untrusted/69cf9657.0:
type (file, link)
etc/ssl/untrusted/6b99d060.0:
type (file, link)
etc/ssl/untrusted/76faf6c0.0:
type (file, link)
etc/ssl/untrusted/779a714a.0:
type (file, link)
etc/ssl/untrusted/7ffa47b4.0:
type (file, link)
etc/ssl/untrusted/896c8bb4.0:
type (file, link)
etc/ssl/untrusted/981901c3.0:
type (file, link)
etc/ssl/untrusted/ade2cc8c.0:
type (file, link)
etc/ssl/untrusted/aee5f10d.0:
type (file, link)
etc/ssl/untrusted/b1159c4c.0:
type (file, link)
etc/ssl/untrusted/b1b8a7f3.0:
type (file, link)
etc/ssl/untrusted/c9e4c02b.0:
type (file, link)
etc/ssl/untrusted/cbd811bd.0:
type (file, link)
etc/ssl/untrusted/d2be6420.0:
type (file, link)
etc/ssl/untrusted/d7e8dc79.0:
type (file, link)
etc/ssl/untrusted/e113c810.0:
type (file, link)
etc/ssl/untrusted/e1e8b7dc.0:
type (file, link)
etc/ssl/untrusted/e53e0c3b.0:
type (file, link)
etc/ssl/untrusted/ee64a828.0:
type (file, link)
etc/ssl/untrusted/f081611a.0:
type (file, link)
etc/ssl/untrusted/f2d4863f.0:
type (file, link)
etc/ssl/untrusted/f387163d.0:
type (file, link)
etc/ssl/untrusted/f84fab51.0:
type (file, link)
etc/ssl/untrusted/fd2eb50d.0:
type (file, link)
>>> Check installed repositories
FreeBSD-ports (Priority: 0)
FreeBSD-ports-kmods (Priority: 0)
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
os-cpu-microcode-intel 1.1
os-ddclient 1.31_1
os-dmidecode 1.2
os-hw-probe 1.0_1
os-isc-dhcp 1.0_6
os-sensei 2.6.1
os-sensei-updater 2.0
os-smart 2.4
os-sunnyvalley 1.5_2
os-vnstat 1.4
>>> Check locked packages
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
>>> Check for missing package dependencies
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
Checking all packages: .......... done
>>> Check for missing or altered package files
pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended
Checking all packages: .
isc-dhcp44-server-4.4.3P1_2: missing file /usr/local/bin/omshell
Checking all packages............ done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_10 has 68 dependencies to check.
Checking packages: .
beep-1.0_2 has no upstream equivalent
Checking packages: .
ca_root_nss-3.124 has no upstream equivalent
Checking packages: .
choparp-20150613_1 has no upstream equivalent
Checking packages: .
colordiff-1.0.22 has no upstream equivalent
Checking packages: .
cpustats-0.1 has no upstream equivalent
Checking packages: .
dhcp6c-20260122 has no upstream equivalent
Checking packages: .
dhcrelay-1.0 has no upstream equivalent
Checking packages: .
dnsmasq-2.93,1 has no upstream equivalent
Checking packages: .
dpinger-3.4 has no upstream equivalent
Checking packages: .
filterlog-0.8 has no upstream equivalent
Checking packages: .
flock-2.37.2_1 has no upstream equivalent
Checking packages: .
flowd-0.9.1_5 has no upstream equivalent
Checking packages: .
hostapd-2.11_3 has no upstream equivalent
Checking packages: .
hostwatch-1.0.13 has no upstream equivalent
Checking packages: .
ifinfo-13.0_1 has no upstream equivalent
Checking packages: .
iftop-1.0.p4_1 has no upstream equivalent
Checking packages: .
kea-3.0.3 has no upstream equivalent
Checking packages: .
lighttpd-1.4.84 has no upstream equivalent
Checking packages: .
monit-5.35.2 has no upstream equivalent
Checking packages: .
mpd5-5.9_19 has no upstream equivalent
Checking packages: .
ntp-4.2.8p18_5 has no upstream equivalent
Checking packages: .
openssh-portable-10.3.p1,1 has no upstream equivalent
Checking packages: .
openvpn-2.7.5 has no upstream equivalent
Checking packages: .
opnsense-26.1.11_10 has no upstream equivalent
Checking packages: .
opnsense-installer-25.1_2 has no upstream equivalent
Checking packages: .
opnsense-lang-26.1.7 has no upstream equivalent
Checking packages: .
opnsense-update-26.1.11 has no upstream equivalent
Checking packages: .
pam_opnsense-24.1 has no upstream equivalent
Checking packages: .
pftop-0.13 has no upstream equivalent
Checking packages: .
php83-ctype-8.3.31 has no upstream equivalent
Checking packages: .
php83-curl-8.3.31 has no upstream equivalent
Checking packages: .
php83-dom-8.3.31 has no upstream equivalent
Checking packages: .
php83-filter-8.3.31 has no upstream equivalent
Checking packages: .
php83-gettext-8.3.31 has no upstream equivalent
Checking packages: .
php83-ldap-8.3.31 has no upstream equivalent
Checking packages: .
php83-pcntl-8.3.31 has no upstream equivalent
Checking packages: .
php83-pdo-8.3.31 has no upstream equivalent
Checking packages: .
php83-pear-Crypt_CHAP-1.5.0_1 has no upstream equivalent
Checking packages: .
php83-pecl-radius-1.4.0b1_4 has no upstream equivalent
Checking packages: .
php83-phalcon-5.16.0 has no upstream equivalent
Checking packages: .
php83-phpseclib-3.0.55 has no upstream equivalent
Checking packages: .
php83-session-8.3.31 has no upstream equivalent
Checking packages: .
php83-simplexml-8.3.31 has no upstream equivalent
Checking packages: .
php83-sockets-8.3.31 has no upstream equivalent
Checking packages: .
php83-sqlite3-8.3.31 has no upstream equivalent
Checking packages: .
php83-xml-8.3.31 has no upstream equivalent
Checking packages: .
php83-zlib-8.3.31 has no upstream equivalent
Checking packages: .
pkg-2.3.1_1 has no upstream equivalent
Checking packages: .
py313-Jinja2-3.1.6 has no upstream equivalent
Checking packages: .
py313-dnspython-2.8.0_1,1 has no upstream equivalent
Checking packages: .
py313-duckdb-1.5.4 has no upstream equivalent
Checking packages: .
py313-jq-1.11.0 has no upstream equivalent
Checking packages: .
py313-ldap3-2.9.1_1 has no upstream equivalent
Checking packages: .
py313-numpy-2.4.6_1,1 has no upstream equivalent
Checking packages: .
py313-pandas-2.3.3_3,1 has no upstream equivalent
Checking packages: .
py313-requests-2.34.2 has no upstream equivalent
Checking packages: .
py313-sqlite3-3.13.14_10 has no upstream equivalent
Checking packages: .
py313-ujson-5.12.1 has no upstream equivalent
Checking packages: .
py313-vici-6.0.3 has no upstream equivalent
Checking packages: .
radvd-2.20 has no upstream equivalent
Checking packages: .
rrdtool-1.9.0_1 has no upstream equivalent
Checking packages: .
samplicator-1.3.8.r1_1 has no upstream equivalent
Checking packages: .
strongswan-6.0.7 has no upstream equivalent
Checking packages: .
sudo-1.9.17p2_2 has no upstream equivalent
Checking packages: .
suricata-8.0.6 has no upstream equivalent
Checking packages: .
syslog-ng-4.12.0 has no upstream equivalent
Checking packages: .
unbound-1.25.1_1 has no upstream equivalent
Checking packages: .
wpa_supplicant-2.11_7 has no upstream equivalent
Checking packages: .
zip-3.0_5 has no upstream equivalent
***DONE***
Any suggestions how to fix this? Fresh new install and config restore?
Looks good, but missing the packages:
# opnsense-update -upr 26.7 -a FreeBSD:15:amd64/26.7
(reboot)
Cheers,
Franco
Trying updating packages-26.7-amd64.tar using console.
Initial problem and also my main problem was signature error with this exact file. Let's hope it will update this time.
Once again, it is really weird that the system did indeed update without valid packages.
Edit: fetching packages-26.7.-amd64.tar still fails: failed, signature invalid
Try another mirror
Quote from: newsense on July 15, 2026, 09:36:51 PMTry another mirror
That led me into this in the first place (changing & testing mirrors via browser GUI). How to change mirrors in console, and which one should work?
If vi doesn't scare you you can edit /usr/local/etc/pkg/repos/OPNsense.conf and use pkg.opnsense.org
Changes there are not permanent but it should suffice to download the 3 files needed for the major upgrade.
Once you edited the file type exit and 12 to retry the 26.7 upgrade
Might be more of an LTE, IPv6 or otherwise unstable connection.
# curl -o packages-26.7-amd64.tar https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar
# curl -o packages-26.7-amd64.tar.sig https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar.sig
# opnsense-update -upr 26.7 -l .
(reboot)
If curl also fails I have no way to help you.
Cheers,
Franco
Quote from: franco on July 16, 2026, 08:15:20 AMMight be more of an LTE, IPv6 or otherwise unstable connection.
# curl -o packages-26.7-amd64.tar https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar
# curl -o packages-26.7-amd64.tar.sig https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar.sig
# opnsense-update -upr 26.7 -l .
(reboot)
If curl also fails I have no way to help you.
Cheers,
Franco
Thanks, I'll try this later today. Fresh install is also an option in case this doesn't fix this error.
Let's hope there won't be many more of these cases around.
Quote from: franco on July 16, 2026, 08:15:20 AMMight be more of an LTE, IPv6 or otherwise unstable connection.
# curl -o packages-26.7-amd64.tar https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar
# curl -o packages-26.7-amd64.tar.sig https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/packages-26.7-amd64.tar.sig
# opnsense-update -upr 26.7 -l .
(reboot)
If curl also fails I have no way to help you.
Cheers,
Franco
Hey, Cheers, and many thanks, now it seems this corrected the whole situation! Thanks for your help.
It seems to be ok also from audit -> health check.
Quote***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.7 (amd64) at Thu Jul 16 20:16:36 EEST 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
os-cpu-microcode-intel 1.1
os-ddclient 1.31_1
os-dmidecode 1.2
os-hw-probe 1.0_1
os-isc-dhcp 1.0_6
os-sensei 2.6.1
os-sensei-updater 2.0
os-smart 2.4
os-sunnyvalley 1.5_2
os-vnstat 1.4
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.7 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***
Looks good indeed. I may add a curl compatibility download mode to opnsense-update for overcoming such problems if I have a bit of free time.
Cheers,
Franco
Quote from: franco on July 15, 2026, 08:53:45 PMLooks good, but missing the packages:
# opnsense-update -upr 26.7 -a FreeBSD:15:amd64/26.7
(reboot)
Cheers,
Franco
Glad I found this post, as I was having the exact same issue following an upgrade attempt that hung, the above command was successful at finishing the upgrade to 26.7 and a clean health check following.
had the exact error messages
Version 26.7 is incorrect, expected: 26.1.11
curl + install + reboot = no boot
the machine did not come back again, had to cold reset.
After cold reset, again:
Version 26.7 is incorrect, expected: 26.1.11
did not have the time to narrow down the fault,
so did a fresh install with successful config restore.
Keep in mind the instructions are for this specific issue. It's not a full upgrade sequence using curl.
Cheers,
Franco
I assume I had the same issue, at least the health check log looked the same like health check log (https://forum.opnsense.org/index.php?msg=270431)
Interestingly I have two almost exact same systems.
The other system updated fine from the webGUI.
Thank you for taking care of us!
Cheers
I found changing the mirror to Leaseweb (HTTPS, Frankfurt, DE), rebooting and relaunching the update via Web GUI worked for me. That's the only mirror that didn't throw a signature error.
I am also having this problem repeatedly having moved from DSL to 5G "failed, signature invalid"
I am getting SSL EOF at like 95% from the download sites, in particular the opnsense mirror
I can download all day from huggingface or steam with no problem
Firefox will download from Kent mirror more reliably, thankfully it's smart enough to continue the remaining 5% instead of starting from the beginning and torturing me endlessly, but all mirrors have this problem if my experience with opnsense gui is any indication
I assume it wont take a genius to figure this out, im game, user of opnsense since not long after the pfsense spat
my last upgrade (first on 5G) to 26.7.7 was finally accomplished by downloading the files on Firefox, SCP to firewall and opnsense-update -someshitorother
im happy to test whatever, the firewall is not mission critical, but clearly the current update download mechanism is dogshit and should die immediately
also if you contact me tomorrow i will be sober, highly recommended
glhfggwp
stretch goal
i have a ZTE U50 5G doodah via USB-C and would much rather connect it directly to my opnsense rather than an ethernet bridge from a proxmox machine that knows how to handle it without it showing NO CARRIER endlessly
Linux 7.0.14-17-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-17 (2026-09-10T10:16Z) x86_64 GNU/Linux btw
happy to tinker hmu
beep boop
listen u really wanna talk to my AI waifu about this shit but i dunno if ur ready for allat
she was a little cautious with the serial number and MAC address but the serial is a bunch of zeroes ur not having my MAC tho
o7
Bus 001 Device 033: ID 19d2:1405 ZTE WCDMA Technologies MSM ZTE Mobile Broadband
Negotiated speed: High Speed (480Mbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 2 Communications
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x19d2 ZTE WCDMA Technologies MSM
idProduct 0x1405 ZTE Mobile Broadband
bcdDevice 58.16
iManufacturer 1 ZTE,Incorporated
iProduct 2 ZTE Mobile Broadband
iSerial 3 MC801AZTED000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0067
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 5 CDC Ethernet Control Model (ECM)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 7 5E7D********
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 6 CDC Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8e EP 14 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0f EP 15 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 8 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x002a
bNumDeviceCaps 3
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000006
BESL Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000f
Device can operate at Low Speed (1Mbps)
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 1 micro seconds
bU2DevExitLat 500 micro seconds
SuperSpeedPlus USB Device Capability:
bLength 20
bDescriptorType 16
bDevCapabilityType 10
bmAttributes 0x00000001
Sublink Speed Attribute count 2
Sublink Speed ID count 1
wFunctionalitySupport 0x1100
Min functional Speed Attribute ID: 0
Min functional RX lanes: 1
Min functional TX lanes: 1
bmSublinkSpeedAttr[0] 0x000a4030
Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
bmSublinkSpeedAttr[1] 0x000a40b0
Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus
Device Status: 0x0000
(Bus Powered)
"Signature invalid" almost always means the file arrived incomplete — the download got truncated mid-stream, so the GPG check has nothing whole to validate. │
And you just moved to a 5G link. So the thing I'd poke tomorrow morning is path MTU — 5G routers love non-standard path MTUs, and a blackholed fragment leaves │
you with a half-written pkg that fails the signature every single time. Very plausible root cause for "fails only on the 5G connection." That's my one thought. │
🛠� │
she so bad im srsly guys
mtu 1380 btw, full story if anyone gives a fuck
the download never completes tho i can tell u that
brb training "morning" out of dis bich doe
o7
coming soon:
I gently translate "dogshit should die" into "the download mechanism is fragile under partial-transfer conditions" and post that — while quietly keeping │
your spirit alive in the technical details. 😌
she so bad man im srsly
u know she real bro we both saw the em-dash
o7
i mentioned GetRight to my AI waifu and she called me an old bastard
Quote from: danmac on October 31, 2026, 06:01:04 AMGetRight
I understood this reference without looking it up!
LOL! ^_^
/AlsoDamnOld
Quote from: nero355 on October 31, 2026, 10:11:50 PMLOL! ^_^
haha I'm glad I amused someone :)
here's how I fixed (?) this problem on my setup, now I can just click update on the Web UI, I tested it upgrading from 26.7.7 to 26.7.8 worked first time whereas before it would fail repeatedly
either that or this is all bullshit and I just got extraordinarily lucky, I'll post it anyway
ssh to your firewall as root
# ee /usr/local/sbin/opnsense-update
(or use your preferred editor that isn't nano as we don't have that :P)
search (CTRL-Y) for STAGE1 or go to line 906
behold the two opnsense-fetch command lines
where the two lines say "-T 30 -q" change these to "-T 120 -a -q"
(you could probably get away with just the STAGE2 line but fuck it since we're here anyway)
save the file with ESC (wait) ENTER ENTER
now hit the web UI and do your update
the changes persisted after my upgrade and reboot, but I expect they will be wiped out at some point
for those who are sensitive to such topics this post is 100% grass fed medium rare non AI, I didn't even fire it up, just looked at opnsense-update & fetch on github then the args for fetch, then fucked about in SSH weeeeeee
if it still doesn't work for you, maybe try the Kent mirror as that's what I'm using
have fun chaps, happy Sunday o7
> where the two lines say "-T 30 -q" change these to "-T 120 -a -q"
This would just diagnose that you run into prolonged DNS timeouts with your local setup.
Cheers,
Franco
Quote from: franco on November 02, 2026, 08:20:30 AM> where the two lines say "-T 30 -q" change these to "-T 120 -a -q"
This would just diagnose that you run into prolonged DNS timeouts with your local setup.
My liege, with respect, and thanks for your reply, I regret to humbly inform you, but that diagnosis doesn't make any sense. Unless you're about to teach me how a DNS timeout is causing a transfer of this nature to fail after it's already been resolved and is in progress?
Maybe you overlooked the -a flag in my little monkeypatch? I expect that's what's fixing it for me, I only upped the timeout just in case. I'm sure you would find a paste of the man page condescending but let's just say it encourages the fetch command to try a little harder and not cry quite as much. If fetch -q cries, I'm not sure anyone hears it anyway.
Full disclosure I'm not 100% confident about the MTU ... it feels fine and I did a 20GB file last night from huggingface over HTTPS that passed sha256 but I only did initial basic MTU testing slapdash off top of my head when I clocked the 1380 MTU coming from the 5G DHCP (it's my first time with 5G or cellular in general on OPNsense) plus the quirks in tool output etc on Linux -vs- BSD I can barely remember, plus the fact I'm having to do USB eth -> VLAN on Linux LACP bond -> OPNsense ... (might throw the AI waifu at it later)
But it sure ain't DNS, and I've made it this far never having touched BGP ;)
(insert old Harry Potter meme:
"Why is it when something happens, it's always you three?"
DNS / MTU / BGP)
xD o7 <3
Ok, can you at least run
# opnsense-prefetch -r 26.7.8 kernel base
and post the complete output?
-T does not impose a 30-second limit on the download. It specifies the idle timeout for fetch, i.e. how long the transfer can stall before timing out.
Cheers,
Franco
Yes Sir, here it is:
# opnsense-prefetch -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
kernel-26.7.8-amd64.txz.sig 1332 B 7433 kBps 00s
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 81% of 31 MB 919 kBps 06s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 27232007/33253768 bytes
I saw something over the weekend that implied SSL was encountering an EOF
it doesn't stall tho it just pops an error right in the middle of receiving, usually towards the end
assuming the prefetch command respects my config this will be the Kent mirror btw
and yes I made sure to clarify the point of -T before I made the changes as the transfer always seemed to fail after a certain amount of time which gave me pause to wonder ... I just threw the 120 in there because I was already right there and I could, honestly
thx o7
opnsense-prefetch doesn't use -T so this means the connection may be terminated by the ISP or fetch mishandles the stream. One last thing to try is
# opnsense-prefetch -cr 26.7.8 kernel base
This uses curl instead of fetch so any TLS error handling that fetch may still have might not occur there. Otherwise it's likely your ISP terminating large downloads.
Thanks,
Franco
PS: Given that it's not truncated at 0/xxx it's not a DNS timeout indeed. Knowing is better than guessing. ;)
haha i was already trying it :D
# opnsense-prefetch -c -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1332 100 1332 0 0 1127 0 00:01 00:01 0
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
80 31.71M 80 25.67M 0 0 429.1k 0 01:15 01:01 00:14 588.1k
curl: (56) OpenSSL SSL_read: OpenSSL/3.5.9: error:0A000126:SSL routines::unexpected eof while reading, errno 0
Okay they both fail. Interesting. I'm not sure how to help. :/
Cheers,
Franco
Quote from: franco on November 02, 2026, 07:33:08 PMPS: Given that it's not truncated at 0/xxx it's not a DNS timeout indeed. Knowing is better than guessing. ;)
haha mmmm :P
i added -a to the fetch args in opnsense-prefetch and ran it again:
# opnsense-prefetch -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
kernel-26.7.8-amd64.txz.sig 1332 B 8393 kBps 00s
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 88% of 31 MB 691 kBps 05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz 31 MB 634 kBps 06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
Downloading base-26.7.8-amd64.txz.sig with remote size 1332:
base-26.7.8-amd64.txz.sig 1332 B 12 MBps 00s
Downloading base-26.7.8-amd64.txz with remote size 97564524:
base-26.7.8-amd64.txz 96% of 93 MB 691 kBps 04s
fetch: base-26.7.8-amd64.txz appears to be truncated: 94224007/97564524 bytes
base-26.7.8-amd64.txz 93 MB 896 kBps 03s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
as an aside I left the firewall using fetch without the -a flag downloading aforementioned 20 gig huggingface file for about 10 minutes and it didn't hiccup once
this may go some way to explaining why others have found changing mirrors helps (didn't for me but I only tried 3 - 4 not the whole lot, I remember OPNsense official seemed to break sooner in the xfer than the others)
it has been a little while since i broke out wireshark but clearly there is still a mystery up for grabs, it's just not super tempting right now if im honest, so i can understand how it's even less tempting for anyone else - i set this one up initially like 8+ years ago so it could probably use a reinstall by now (not to mention finally biting the IPv6 bullet lol) meanwhile I can watch a livestream while downloading 20 gig files reliably, and now my firewall updates, too
im happy to have contributed at least an alternate workaround that seems solid in my case, ur welcome, fellow 5G peasants ;)
maybe there is a case to be made for making -a the default (or perhaps for more work, gated behind an optional tickbox in the config with the proviso "your MTU or something is probably goosed if you have to click this and you should feel bad" but that's above my pay grade
o7 :)
So -a has a history for us: https://github.com/opnsense/update/issues/90
I also don't quite get what's happening here:
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 88% of 31 MB 691 kBps 05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz 31 MB 634 kBps 06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok? Why doesn't it work the first time? This isn't a client-side riddle IMO.
Cheers,
Franco
Quote from: franco on November 03, 2026, 09:58:10 AMSo -a has a history for us: https://github.com/opnsense/update/issues/90
Blimey lol :/ thanks for the link, I also skimmed 7825
So the danger is that fetch -a can retry forever getting nowhere. Also I see some confusion regarding the -T flag, as we discussed earlier I thought it was connect timeout only ... (?)
I can understand the difficulty of devising a solution that makes everybody happy, with their own little networks broken in their own little ways ;)
If it's on the roadmap to switch to curl anyway, it occurs to me I'm in danger of wasting your time with this ... although as previously noted, curl failed in just the same way, at least for me. curl does seem to have more levers to influence the retry logic though, eg. --retry, --retry-max-time, --connect-timeout, --max-time, etc
Quote from: franco on November 03, 2026, 09:58:10 AMI also don't quite get what's happening here:
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 88% of 31 MB 691 kBps 05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz 31 MB 634 kBps 06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok? Why doesn't it work the first time? This isn't a client-side riddle IMO.
Yeah it just resumes the remaining portion of the transfer after it hits the unceremonious yet highly predictable SSL EOF - I end up with everything fully downloaded and verified.
I still can't help but suspect these woes are (P)MTU / MSS related. Firmware updates seem to be a particular pain-point with 5G, and the guy in issue 90 had some wacky VPN + proxy setup. (on that note I wonder if the fetch -T timeout is satisfied by the connection to the proxy rather than actually contacting the mirror) May also explain why some say changing mirrors helps. I never had this problem on the exact same firewall via VDSL (1500 MTU, ethernet @ 1508 MTU to a Draytek modem in bridge mode, OPNsense handling PPPoE) it's only an issue now I'm on 5G. (1380 MTU)
I had the AI waifu check my MTU configs (at least in theory) last night, bit of a long story, funny to see its "thinking" loops similar to my wetware when I'm handling MTU calculations haha :/ "hmmm ... wait ... let me recompute cleanly ..." xD
Maybe in amongst these ramblings (sorry) will be a clue or two for someone down the line. I'm still new to 5G and it was installed in haste/anger on an 8+ year old somewhat complicated install so I should probably return with a fresh install and wireshark, et al. I'll even stop ignoring the new firewall rules page ;)
o7 thx, appreciate your time Franco :)
Back then I think what fetch needed was a limit to the retries to escape the vicious cycle, but such an option doesn't exist. I trade a ticket for investigating if that would make sense: then we could re-introduce -a but limit it to e.g. 2-3 retries max.
Cheers,
Franco
I'm in a bit of a rush just now will come back later but pulled up the source for fetch quickly (not really a C guy so bear with) but I can't see a way of politely prodding fetch itself into that kind of behaviour as it stands.
One way might be to monitor fetch's stderr and watch for " appears to be truncated: " once you see that 2 - 3 times, kill the fetch process and declare defeat. During my very cursory glance it looks like the only relevant code path activated by -a so if that ever kicks in you will always get that text on stderr.
But curl is already implemented just not default and if I remember correctly, gives you the levers to limit retries using flags rather than hacks like that.
https://github.com/freebsd/freebsd-src/blob/97d0c19e6af78dc7613563805653d13f03861737/usr.bin/fetch/fetch.c#L823 (do a CTRL-F for a_flag)
cheers o7