I tried to reply to an old thread at first, but it wouldn’t let me, since I’m a new user. But that old thread is the only hit I’ve found for a problem that’s been bugging me for a long time. We’re using the BigFix client 10.0.2.52 on Linux (RHEL 8) in our environment and we’ve had an issue on some machines that’s equivalent to the one mentioned above: “dmi inspector error creating dmi.info”. We could recreate the issue we’re having with a query via qna:
./qna
Q: serial_number of system_information of dmi
E: dmi inspector error creating dmi.info (Q: [FindDmiInfo failed - ])
T: 15229
I strace’d this command and could see that the client code was trying to build the dmi.info file by reading /dev/mem and it wasn’t being created because of some issue reading /dev/mem. I ran a similar query with python and dmidecode.py and I received “permission denied” even though I was running as root. That’s when I saw this comment and others that were similar. The BigFix client fails to read the dmi info when secure boot is enabled in the BIOS. (But reading /dev/mem isn’t the right way to query this info any longer).
Linux kernels expose info through /sys filesystem; /dev can be exposed for retro compatibility.
Per my experience, qna is not able to return a correct result if the DMI information are not correctly exposed by the kernel. dmidecode / biosdecode (these commands are distro independent and preinstalled in most of them) will read from the same sources of our inspector and should fail as well.
If there’s an UEFI Bios, you should find /sys/firmware/efi
Yes, please do open a support case if you haven’t yet.
We do have an option to blacklist an inspector, preventing it from executing (and potentially crashing the client). This will of course make any content depending on the inspector stop working, but if you can’t get the BESClient to run at all this may be a temporary workaround.
If you’d like to try blacklisting the ‘dmi’ inspector, try adding the following to /var/opt/BESClient/besclient.config :
[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_Inspector_Blacklist]
value = dmi
Turns out we have a lot of systems having this issue. But they are all running the older 9.x client. All the 10.x clients I’ve checked are not even trying to read /dev/mem and create info.dmi fine (from reading /sys/firmware/efi/systab, I guess?).