pfSense

First reported here:

https://forum.netgate.com/topic/160762/cpu-info-disappear-on-pfsense-2-5-0-rc/2

Jim Pingle wrote:

This is because the number of packages and cores is currently scraped from /var/log/dmesg.boot, and when you reset all log files, that file gets reset since it's also a log file.

There doesn't appear to be any way to get the equivalent information out of sysctl (e.g. under kern.smp.*), since that seems to only count the total number of cores and not the number of physical CPUs ("packages"). We can't rely on it being in the kernel message buffer either since that gets cycled out as new messages come in.

It's cosmetic only and only affects the rare occasion someone resets log files, so given the very low impact and lack of easy workaround, I don't see it being worth dedicating a lot of resources to fix. If someone happens to come up with a viable workaround, feel free to submit a PR.

Hi Jim,

Okay, thanks for the information. It didn't happen with previous pfSense versions so that's why I report it :)
But, what about AES-NI CPU Crypto: Yes (active) change to AES-NI CPU Crypto: NO after RESET LOG FILES. I do have Intel CPU that supports AES and I use couple of OpenVPN too. :)

Same issue with finding the CPU flags to see what the CPU supports.

On older versions, dmesg.boot wasn't cleared, but also on older versions there wasn't a log tab for dmesg.boot and there is now (Status > System Logs, System tab, OS Boot sub-tab).

Would it work to just copy the file to dmesg.boot.current or whatever, after each boot, and then parse that? It should always be small (?) and dmesg.boot could be rotated on demand.

e.g. cron:
@reboot sleep 120 && cp /var/log/dmesg.boot /var/log/dmesg.boot.current

The dmesg.boot file is the copy of the kernel message buffer for that purpose.

Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.

People may have been in the habit of doing it for various reasons on old versions with clog (like changing log sizes/options) but that isn't necessary anymore.

Jim Pingle wrote:

The dmesg.boot file is the copy of the kernel message buffer for that purpose.

Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.

People still need to reset log files in some cases (e.g. clearing history)

keep dmesg.boot on log reset, as it is the copy of the kernel message buffer, and not a log file:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/173

To test:

On a system without the fix:

• Check System Information Widget on the Dashboard for "AES-NI CPU Crypto: Yes"
• Reset all log files from Status > System Logs, Settings tab
• View the OS Boot log at Status > System Logs, System, OS Boot. It will be empty.
• Check System Information Widget on the Dashboard and it now displays "AES-NI CPU Crypto: No"
• Reboot and check the widget again, and the expected value has returned.

Repeat the test again on a snapshot with the fix and resetting the log files will not change the dashboard output nor will it clear the OS boot log.

Cherry-picked to RELENG_2_5_1

Bearny B. wrote:

Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.

Jim Pingle wrote:

Updating subject for release notes.

It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)

Bearny B. wrote:

Bearny B. wrote:

Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.

Jim Pingle wrote:

Updating subject for release notes.

It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)

Tested on 21.02.2-RC (amd64) built on Thu Apr 01 11:53:58 EDT 2021, fix confirmed.