Health check - Reporting mismatches when update is available

[upended]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

When running a Health check, the report will erroneously state there are mismatches for the section "Check for core packages consistency" when there is an update available for download. Currently system is running 25.7.9_7, and received the multiple mismatches expecting 25.7.10.

The health check is expecting an O.S. version that it has never downloaded nor installed. This is confusing since the version detect is
Currently running OPNsense 25.7.9_7 (amd64) at Sat Dec 20 10:31:01 PST 2025

the installed kernel version, and base version in the report are also both showing correct.

Check installed kernel version
Version 25.7.8 is correct.
Check for missing or altered kernel files
No problems detected.
Check installed base version
Version 25.7.8 is correct.

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce

Steps to reproduce the behavior:

1. (assuming this is the same process for all versions) OS must be on a lower version than what is currently available for download.

2. Run a health check

Expected behavior

When the health check runs, the health check should look at what version is installed (in this case 25.7.9_7 ) and compare the packages for that version not a different version.

The report is stating some parts are correct for the version installed and other are incorrect even if the installed version is correct for the installed O.S. It should be verifying what it "is / should be" for all areas (kernel, packages, base, etc), not what it can be for packages with updates available.

Basically the report should check what OS version installed, and use that as the reference for all software. Not to pull from the repository what the latest software version is and use that as its' reference.

Describe alternatives you considered

A health check would look at the OS version installed and all the packages version, then compare to repository for that version currently installed.

Screenshots

If applicable, add screenshots to help explain your problem.

Relevant log files

GOT REQUEST TO AUDIT HEALTH
Currently running OPNsense 25.7.9_7 (amd64) at Sat Dec 20 10:31:01 PST 2025

Root file system: zroot/ROOT/current
Check installed kernel version
Version 25.7.8 is correct.
Check for missing or altered kernel files
No problems detected.
Check installed base version
Version 25.7.8 is correct.
Check for missing or altered base files
No problems detected.
Check installed repositories
OPNsense (Priority: 11)
Check installed plugins
os-cpu-microcode-intel 1.1
os-dmidecode 1.2
os-openvpn-legacy 1.0
os-smart 2.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 25.7.9_7 has 67 dependencies to check.
Checking packages: ........
dpinger-3.3 version mismatch, expected 3.4
Checking packages: ...............
opnsense-25.7.9_7 version mismatch, expected 25.7.10
Checking packages: ...
opnsense-update-25.7.8 version mismatch, expected 25.7.10
Checking packages: ..............
php83-phpseclib-3.0.47 version mismatch, expected 3.0.48
Checking packages: .............
py311-numpy-1.26.4_10,1 version mismatch, expected 1.26.4_11,1
Checking packages: ............... done
DONE

Additional context

Since 25.7.10 was release 2 days ago, most users have not even been made aware of the update or have had time to review what changes have been made.

The current method is also confusing as it is attempting to indicate a problem when there really is not one since an upgrade is not a health issue, and it should not be report a mismatch when it's making a comparison to something irrelevant to the system being checked.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 23.7.8 (amd64).
Intel® Xeon™ E3-1225V5 3.3Ghz Quad Core
Network Intel® I210-AT

[fichtner]

Hi @upended,

In a nutshell the health check compares the local database with the remote one. This can be considered intentional, or incidental if you follow the normal release cycle.

You can also set the firmware flavour to each minor release, but this requires your manual maintenance and update management. In that case, however, the health check works as you would expect.

Cheers,
Franco

[upended]

In a nutshell the health check compares the local database with the remote one.
I figured this was the case as the report specifically stated .10 when 9_7 is installed. Whether incidental or intentional, it is still an error. The issue is that the health report does not report correctly as it should / expected, hence my ticket.

As for setting the firmware manually, instead, would it be possible to alter the report by first looking up the firmware version, save the minor / major release value as a variable and continue with the report process. This way there are no settings / configuration changes and it would not have any effect on what is already save as it could be discarded after the script ran?

[fichtner]

Feel free to propose a fix. I don’t know what it could be.

Cheers,
Franco