Hi All,

I have a CentOS 4.7 server which automatically downloaded and installed OMSA 6.1
last night after it was released onto the repo. I noticed this morning that it
had broken all SNMP hardware checks, and on investigation this was caused by the
fact that IPMI was not running.

 

A "srvadmin-services.sh start" came back with:

 

Starting Systems Management Device Drivers:

Starting dell_rbu: Already started                         [  OK  ]

Starting ipmi driver: Unsupported version                  [FAILED]

Starting Systems Management Device Drivers:

Starting dell_rbu: Already started                         [  OK  ]

Starting ipmi driver: Unsupported version                  [FAILED]

Starting DSM SA Shared Services:                           [  OK  ]

 

"Unsupported version"? Hmm.... It worked OK yesterday with 5.5! I started
pulling things apart and found that it was failing when starting IPMI in
/etc/rc.d/init.d/instsvcdrv. A manual run of that script provided:

 

/etc/rc.d/init.d/instsvcdrv start

instsvcdrv_oihapicfg_validate_addheader()

Starting Systems Management Device Drivers:

Starting dell_rbu: Already started                         [  OK  ]

Starting ipmi driver: CheckOpenIPMIVersion: FAILED to determine OS

CheckOpenIPMIVersion: kernel version minimum is: 2.6.15

CheckOpenIPMIVersion: running kernel version is: 2.6.9-78.0.5.ELsmp

CheckOpenIPMIVersion: failed: kernel patch version < minimum

instsvcdrv_oihapicfg_validate_addheader()

Unsupported version                                        [FAILED]

 

Aha! The script is failing to determine which OS the server is running, and then
using the kernel requirement of 2.6.15 as a fallback/failsafe. CentOS 4.7 is
still on 2.6.9, hence the "Unsupported Version".  RHEL4 is however a "supported
OS" for OMSA6.1, so what is going on here? Obviously the script is failing to
pick up on the fact that it is Centos 4.7.

 

vi /etc/rc.d/init.d/instsvcdrv

 

    365         ##elif [ ! "`grep 'Nahant' /etc/redhat-release 2>/dev/null`" ==
"" ];

    366         then

    367                 debugprint "${l_fname}: OS is RHEL4"

    368                 l_maj_ckey=${OPENIPMI_RHEL4_VERMAJ_CONFIG_KEY}

    369                 l_maj_dflt=${OPENIPMI_RHEL4_VERMAJ_DEFAULT}

    370                 l_min_ckey=${OPENIPMI_RHEL4_VERMIN_CONFIG_KEY}

    371                 l_min_dflt=${OPENIPMI_RHEL4_VERMIN_DEFAULT}

    372                 l_modext=".ko"

 

But my /etc/redhat-release doesn't contain "Nahant"....

 

cat /etc/redha-release

CentOS release 4.7 (Final)

 

A quick amendment of line 365:

 

365        elif [ ! "`grep 'CentOS release 4.' /etc/redhat-release 2>/dev/null`"
== "" ];

 

And it works:

 

srvadmin-services.sh start

Starting Systems Management Device Drivers:

Starting dell_rbu:                                         [  OK  ]

Starting ipmi driver: CheckOpenIPMIVersion: OS is RHEL4

CheckOpenIPMIVersion: minimum version is 33.13

CheckOpenIPMIVersion: version >= minimum

instsvcdrv_oihapicfg_validate_addheader()

Already started                                            [  OK  ]

Starting Systems Management Data Engine:

Starting dsm_sa_datamgr32d:                                [  OK  ]

Starting dsm_sa_eventmgr32d:                               [  OK  ]

Starting dsm_sa_snmp32d:                                   [  OK  ]

Starting DSM SA Shared Services:                           [  OK  ]

 

I hope someone else finds this useful, or that the nice folks at Dell can please
put a clause into this script to identify Centos 4 using this string and
classify it as RHEL4 equivalent. FWIW, I have tested OMSA 6.1 on some CentOS 5.3
servers, and they all seem unaffected.

Best Regards, 

Richard Garner (A+, N+, AMBCS, MOS-O) 



 
 
All E-Mail communications are monitored in addition to being content checked 
for malicious codes or viruses. The success of scanning products is not 
guaranteed, therefore the recipient(s) should carry out any checks that they 
believe to be appropriate in this respect.
 
This message (including any attachments and/or related materials) is 
confidential to and is the property of Computer Service Centre, unless 
otherwise noted. If you are not the intended recipient, you should delete this 
message and are hereby notified that any disclosure, copying, or distribution 
of this message, or the taking of any action based on it, is strictly 
prohibited.
 
Any views or opinions presented are solely those of the author and do not 
necessarily represent those of Computer Service Centre.
_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge@lists.us.dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Reply via email to