This is a HOWTO that hopefully helps someone else out later, and does not particularly require any response.
Having run several older PowerEdge server platforms for an engineering department, and having this be a secondary responsibility, I've never come to grips with how to determine what the blinking fault lights on the front of a server mean.  Also having recently experienced failure of all but the power supply fan in a PowerEdge 2300, the need for hardware status reporting became quite clear.  This prompted a struggle with learning about srvadmin/omsa and getting it to install on an non-supported Linux.  Here are some results for any other poor server admin that has old hardware: The server in question is a PowerEdge 4400.  It has Mandriva Enterprise Server 5.2 on it.  As this extended support OS is near its end-of-life, it has an older kernel, but one that is newer than the kernel that OMSA 4.5.0.1 was deployed under.  In this case, the kernel is 2.3.27.56-2mnb. First, it was a challenge just identifying the newest OMSA srvadmin that supported the 4400.  Web documents conflict with documents inside download files such that newer versions of ISM media contain information that appears to suggest they do not support the 4400 while web documents describing the media indicate otherwise.  In the end, it seemed that OMSA 4.5.0.1 was the most recent that supported the PowerEdge 4400, and this led to obtaining the 4.5_ISM_A00.ISO listed for the PowerEdge 4400 that contained the resources needed to set up the srvadmin software. Upon finding the srvadmin/linux/supportscripts folder on the media, attempts to get srvadmin and the omreport command working started to get promising.  Various attempts were made without success, though.  Experience shows that letting srvadmin-install.sh do as much of the work as possible (including service startup) is essential for success.  I'll summarize results here: $ sudo ./servadmin-install.sh Warning: the lockfile utilitis is not found in PATH or /usr/bin.  This utility prevents concurrent executions of srvadmin-install.sh which can lead to unexpected or invalid installation results. procmail resolved this issue. $ sudo urpmi procmail The next attempt at installation produced: error: Failed dependencies: libstdc++-libc6.2-2.so.3 is needed by srvadmin-omacore-4.5.0-335.i386 After trying a native MES 5.2 package unsuccessfully, an attempt was made to a rebuild of srvadmin/linux/SRPMS/compat-gcc-296-2.96-132.7.2.src.rpm since that seemed key to getting this working.  Doing this required installation of zlib-devel, dejagnu, bison, flex, texinfo, and their dependencies.  That failed miserably due to the new OS having significant issues some of which were related to use of a recent gcc toolchain.  The srvadmin/linux/RPMS/compat-libstdc++-296-2.96-132.7.2.i386.rpm binary package was installed instead (with fingers crossed). $ sudo urpmi ../RPMS/compat-libstdc++-296-2.96-132.7.2.i386.rpm At this point things start to look promising.  srvadmin-omilcore notes: To start all installed services without a reboot, enter the following command: srvadmin-services.sh start.  Various Warning: syslog is needed by instsvcdrv in runlevel n messages are disconcerting but seem to be innocuous.  Eventually an opportunity is given to let the script start the Server Administrator services.  At this point it seems essential to answer in the affirmative.  The script appears to do far more than just run `srvadmin-services.sh start`.  A working setup was never attained by manually starting the services.  In fact, doing the startup manually ended up distracting one from the root problem.  One such distracting message was the result of running `omdiag -?` and getting back "JniODB.static: UnsatisfiedLinkError loading data bridge JNI - Trying 64 bits.".  The main problem was that omreport commands did not sucessfully return any data about the chassis faults. When the script was allowed to start the services, error messages occurred that facilitated debug and correction of various problems.  The primary clue that something was wrong related to failure of instsvcdrv dcdbas startup.  The blow by blow details are not shared here, but essentially it was required to look in /var/log/dcdbas.dks.log and /var/log/dcdbas.log to determine what try next.  Many iterations were require to ultimately resolve the problems.  Resolving the problems boiled down to patching /opt/dell/srvadmin/hapi/drivers/x86/dks/common/dcddks.c.  This was done by creative googling of other kernel module patches that contained references to errors seen in /var/log/dcdbas.dks.log.  The patch ended up looking like this: --- /opt/dell/srvadmin/hapi/drivers/x86/dks/common/dcddks.c.orig        2005-10-03 13:50:39.000000000 -0500+++ /opt/dell/srvadmin/hapi/drivers/x86/dks/common/dcddks.c     2012-12-10 15:30:16.000000000 -0600@@ -26,7 +26,7 @@ // Include files //------------------------------------------------------------------------- #include -#include +/* #include */  #include  #include  #include @@ -568,6 +568,7 @@  //--------------------------------------------------------------------  // esm_verify_area_write  //-------------------------------------------------------------------- +#define verify_area( VERIFY_READ, uaddr, size ) (access_ok( VERIFY_READ, uaddr, size ) ? 0 : -EFAULT)  int esm_verify_area_write(void *arg,                                                   int size)  { @@ -1296,7 +1297,7 @@         return smp_call_function(                 func,                 info, -               nonatomic, +       /*      nonatomic, */                 wait                 );  } // esm_smp_call_function @@ -1386,6 +1387,8 @@  //--------------------------------------------------------------------  // esm_kill_thread  //-------------------------------------------------------------------- +#define kill_proc(p,s,v) send_sig(s,find_task_by_vpid(p),0) +  int esm_kill_thread(void *pThreadData)  {         int error;  Upon applying this patch, srvadmin-install.sh worked like a charm and `omreport chassis` told me what was wrong. It is probably important to note that the "PE Updates prereq cd.iso" listed for the PowerEdge 4400 was also to update the system and PERC BIOS.  That was a bit hard to figure out since the SUU ISO was not bootable and there was no bootable DOS partition on the system.  There did not seem to be any note related to how to get the system booted in order to apply the updates.  The prereq media was simple to use.  It did the update in a very automated way. Caveat: At one point while messing with omreport, the system hung solid and required a forced reboot via powercycle.  At this point it seemed prudent to start the services, find out what was wrong, and then use `srvadmin-services.sh stop` in case the lockup was related to the age of srvadmin and use on an unsupported operating system.  It's not 100% clear that the problems are related though as it turns out that the problems on the system included two critical Peripheral Bay Backplane voltages being seriously out of spec (>1V off).
OMSA 4.5_ISM_A00.ISO and Mandriva Enterprise Server 5.2 kernel (2.3.27.56-2mnb)