Table of Contents
While we strive to produce a problem free product, there are sometimes issues which are not easily resolved or for which special consideration is required. This chapter discribes known issues and workarounds for this release of the software.
SysInfo™ is installed by default to run as user "root" (aka Super User) with the UNIX setuid bit enabled.
Root access is needed in order for SysInfo™ to provide the most complete asset and configuration data of a system. This is due to the inherent security restrictions that most operating system vendors deliberately design in to their OS. Some, but not all of the data that SysInfo™ discovers is provided via non-root methods, but the list is far from complete.
You can run SysInfo™ without any root privileges. However the amount and quality of data reported will be severely reduced.
SysInfo™ is perfectly safe to run with full root privileges. It is very careful about raising and lowering it's root privileges to use only the access necessary to obtain the data it reports.
When SysInfo™ is run on an OS which is run inside a Virtual Machine such as VMware or Xen, nearly all attributes of the underlying hardware are not reported. This includes the physical system's "System Serial Number", true memory configuration, controllers, etc. This is because the inherent nature of VM technology is to mask the physical attributes of the system. This is done deliberately by the VM products.
Certain graphics drivers on Linux will momentarily
blink the
attached monitor
when SysInfo and other similiar programs such as
ddcprobe are run.
The blink occurs when the monitor is probed via the DDC protocol.
The blinking is a bug in the graphics drivers themselves rather than a bug
in the SysInfo.
If you wish to avoid blinking monitors, specify the
--avoidblink command line option.
When specified, DDC probing will not be performed when graphics cards
known to have this problem are installed.
The list of known graphics cards known to have this problem is as follows:
Matrox G200
Intel 815
Memory module details such as the memory slot layout are not reported on AIX, Solaris SPARC, and Solaris X86 prior to Solaris 10 06/06. These platforms lack the interfaces which would allow us to determine this data.
CPU cache details are not reported on Solaris X86 prior to Solaris 10 06/06, AIX, and MacOS PowerPC due to the lack of OS interface to obtain this data.
The "BootLevels", "RcCmd", "RcStartNum", and "RcStopNum" parameters are not reported on all platforms. This is due to the lack of use of the older "rc style" of service management. OS like Solaris 10 and later and MacOS do not use rc style service management and they have no equivilant values for these parameters.
You may receive an "Out of Memory!" error on HP-UX when
generating HTML output, especially if using
--msglevel all
in conjunction with
--class software.
This error is due to the default maximum data memory allowed by the kernel
being set too low.
To avoid this error,
you can adjust the maxdsize kernel parameter from
it's typical default of 500MB to 1000MB or more.
Alternatively you can first create a SysInfo report of the data you want, transfer the report data to a system with lots of memory, and then create the report. Here's the basic procedure:
On the HP-UX system with the error run:
mcsysinfo --nw --class software --msglevel all --format report > sw.rpt
Copy the sw.rpt file to
a host with enough memory and then run:
mcsysinfo --nw --class software --msglevel all --encode html --infile sw.rpt > sw.html
The "InstDate" and "InstDateNum" parameters are not always reported.
This issue is due to the lack of data available on some OS like AIX which simply do not provide this data nor any means for SysInfo™ to calculate the data.