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 Sun sneep program available via Downloads on www.sun.com. The sneep 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).

The "System Serial" parameter is not reported on X86 and X64 systems running versions of Solaris prior to Solaris 10 0606. Releases prior to Solaris 10 0606 lack the ability to access the SMBIOS data which contains the System Serial number data.

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 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:

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.

Support for collecting License class data from Macrovision's FLEXlm works with Solaris 7 and later.

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.

The "State" parameter is not reported on HP-UX due to the lack of support by the OS to provide this data.

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:

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 line avoidblink=YES to /opt/sysinfo/config/mcsysinfo.cfg and add the line define|BlinkCards||1|.*|.* to the file /opt/sysinfo/lib/sid/linux.sid.

RPM package version 4.2.3 or later is required for reliable Software class data. Older versions of the RPM package are prone to hanging which will result in little or no Software class data being reported.