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.
The "Kernel Version" parameter is not reported on AIX and HP-UX due to the lack of interface provided by the OS.
The "System Serial" parameter reported by SysInfo™
on most Sun SPARC systems (especially older systems) is not
the value recognized by Sun and physically printed on the system. This is
due to limits in most older SPARC based systems which do not encode the
System Serial number in an electronic form. The recommended workaround for
this is to install the
program available via Downloads on
program allows a system administrator to specify the
system serial value and store it for later retrieval.
SysInfo™ will use
sneep (if it's installed)
to retrieve the System Serial number on SPARC
based systems (requires SysInfo™ version 8-H31 and later).
Hardware class data is not reported when SysInfo™ is run inside of a Solaris Container/Zone. This is due to Solaris not providing access to the required data. Numerous Solaris commands like prtdiag(1M) also have the same issue.
Certain graphics drivers on Linux will momentarily
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:
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. Detailed memory configuration reporting on Solaris SPARC based systems is limited to Sun Fire E3x00/E4x00/E5x00/E6x00, Sun Fire v1280, Sun Fire v210, Sun Fire v240, Sun Fire v440, Sun Fire v880.
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.
CPU "Serial Number" is not reported on SPARC and PowerPC platforms since those CPU implementations do not have an encoded serial number.
VESA Extend Display Identification Data (EDID) for monitors appears to only be available from Creator Series 2 (FFB2) and later Creator frame buffers. No sign of EDID data on any other Sun framebuffer so far.
Support for querying SCSI devices has been added as of SysInfo™ version 4.2. However, devices in use - especially disks in use - will not contain the additional SCSI data because AIX (through at least version 4.3.3) does not provide a means of querying a SCSI device which is already in use.
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
in conjunction with
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
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.
The "Category" parameter is not reported on HP-UX. This is due to HP-UX not having the concept of a Category for software.
Some customers have reported that when SysInfo™ is run with
Hardware class discovery enabled, the system clock may advance by 2-3 seconds.
This occurs on a very limited number of X86/X64 based systems
running Linux due to bugs
in system firmware (BIOS). A workaround is to add the
/opt/sysinfo/config/mcsysinfo.cfg and add the
define|BlinkCards||1|.*|.* to the file