Hi!
When I switch the type to "Development" I end up with 24.7.b_215. No additional updates are offered after that one. When I switch the type back to "Community" it offers me to downgrade to 24.1.10.
So ... how?
Thanks!
Patrick
On the latest development release do
https://github.com/opnsense/core/commit/9ddd363bd
# opnsense-patch 9ddd363bd
Aaaand check for updates :)
The community release will ignore it because it doesn't have the 24.7 fingerprints yet for failsafe reasons. It's not impossible to patch them as well but I would advise against posting it here.
Cheers,
Franco
Sorry, no banana.
"Your packages are up to date."
Poor opnsense-patch. I think you need to go to /usr/local/etc/opnsense-update.conf and replace "%%CORE_ARCH%%" with "amd64". Sorry.
Cheers,
Franco
Here we go ... 8)
Thanks!
Time to create a new boot environment ...
mkdir /root/upd
cd /root/upd
wget https://pkg.opnsense.org/FreeBSD:14:amd64/24.7/sets/kernel-24.7.r1-amd64.txz
wget https://pkg.opnsense.org/FreeBSD:14:amd64/24.7/sets/base-24.7.r1-amd64.txz
wget https://pkg.opnsense.org/FreeBSD:14:amd64/24.7/sets/packages-24.7.r1-amd64.tar
opnsense-update -fiur 24.7.r1 -l /root/upd
exit
Choose option 6 (reboot), answer Y.
Not that I said anything of the sort, but telling people to use '-i' as in insecure unverified upgrades and telling them to avoid the appropriate update-related scripting (console menu or GUI page) as well is not so nice.
Cheers,
Franco
24.7.r1 now in Vagrant. Apart from the fact that the download took hours, no noticeable problems or surprises.
Love the new dashboard and the Caddy widgets!
When can I expect an updated bootstrap.sh.in? I assume one starts with a FreeBSD 14.1 install then?
Quote from: franco on July 16, 2024, 05:13:13 PM
Poor opnsense-patch. I think you need to go to /usr/local/etc/opnsense-update.conf and replace "%%CORE_ARCH%%" with "amd64". Sorry.
Cheers,
Franco
Is this manual change still needed or has it been corrected in the upgrade?
It is, however it is best to wait for RC2 at this point in time. There's a crash happening on RC1 which doesn't appear to have been there on the beta.
Thank you!
> Is this manual change still needed or has it been corrected in the upgrade?
There is nothing to correct. Once the next 24.1.x arrives all this will be automatic. It was explained in the release notes. And even opnsense-patch is allowed its limits here ;)
Cheers,
Franco
So here's a bit of a show stopper, DuckDB again, that I found trying to upgrade the last FW I have. Ran this twice to make sure it is consistent. After reboot nothing happens since the process crashed and the kernel/base haven't been installed.
Proceed with this action? [24.7.r1/y/N]: 24.7.r1
Fetching packages-24.7.r1-amd64.tar: ... done
Fetching base-24.7.r1-amd64.txz: ................................ done
Fetching kernel-24.7.r1-amd64.txz: ................. done
Extracting packages-24.7.r1-amd64.tar... done
Extracting base-24.7.r1-amd64.txz... done
Extracting kernel-24.7.r1-amd64.txz... done
Please reboot.
>>> Invoking upgrade script 'squid-plugin.php'
Squid web proxy is not active. Not installing replacement plugin.
>>> Invoking upgrade script 'unbound-duckdb.py'
Unbound DNS stats disabled
>>> Invoking upgrade script 'unbound-duckdb.py.orig'
Traceback (most recent call last):
File "/usr/local/opnsense/site-python/duckdb_helper.py", line 65, in __enter__
self.connection = duckdb.connect(database=self._path, read_only=self._read_only)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
duckdb.duckdb.IOException: IO Error: Trying to read a database file with version number 39, but we can only read version 64.
The database file was created with DuckDB version v0.6.0 or v0.6.1.
The storage of DuckDB is not yet stable; newer versions of DuckDB cannot read old database files and vice versa.
The storage will be stabilized when version 1.0 releases.
For now, we recommend that you load the database file in a supported version of DuckDB, and use the EXPORT DATABASE command followed by IMPORT DATABASE on the current version of DuckDB.
See the storage page for more information: https://duckdb.org/internals/storage
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/etc/rc.syshook.d/upgrade/20-unbound-duckdb.py.orig", line 41, in <module>
if export_database('/var/unbound/data/unbound.duckdb', '/var/cache/unbound.duckdb', 'unbound', 'unbound'):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/opnsense/site-python/duckdb_helper.py", line 147, in export_database
with DbConnection(source, read_only=True) as db:
File "/usr/local/opnsense/site-python/duckdb_helper.py", line 75, in __enter__
raise StorageVersionException(str(e))
duckdb_helper.StorageVersionException: IO Error: Trying to read a database file with version number 39, but we can only read version 64.
The database file was created with DuckDB version v0.6.0 or v0.6.1.
The storage of DuckDB is not yet stable; newer versions of DuckDB cannot read old database files and vice versa.
The storage will be stabilized when version 1.0 releases.
For now, we recommend that you load the database file in a supported version of DuckDB, and use the EXPORT DATABASE command followed by IMPORT DATABASE on the current version of DuckDB.
See the storage page for more information: https://duckdb.org/internals/storage
>>> Error in upgrade script '20-unbound-duckdb.py.orig'
*** OPNsense.localdomain: OPNsense 24.1.10_3 ***
Resetting the DNS DB in Reporting worked of course and the FW is now rebooting and performing the upgrade.
Since statistics gathering was already disabled on this system and likely due some legacy cruft it caused the crash anyway, I'm wondering if it wouldn't be better to straight out delete that DB on systems where the DNS statistics gathering is already disabled ?
If you look closely:
>>> Invoking upgrade script 'unbound-duckdb.py'
Unbound DNS stats disabled
That part was handled previously...
>>> Invoking upgrade script 'unbound-duckdb.py.orig'
Looks like an opnsense-patch victim, an older version of an unpatched script which can't be cleaned up. We may be able to ignore .orig / .rej files created by diff(1) but it's a bit of a broader issue that would just receive a localised fix for a non-standard file.
Cheers,
Franco
In a weird twist, this APU didn't come back online after going down for 24.7.r1. Waiting to hear if it is operational and only Zerotier is misbehaving or something else went wrong.