# ipmitool sensor | grep CMOS
CMOS Battery     | 0x0        | discrete   | 0x0080| na        | na        |
na        | na        | na        | na
# ipmitool sdr | grep CMOS
CMOS Battery     | 0x00              | ok


-----Original Message-----
From: chandrasekha...@dell.com [mailto:chandrasekha...@dell.com] 
Sent: Thursday, February 08, 2018 12:26 AM
To: linux-powere...@lists.us.dell.com; teri...@gmail.com
Subject: check_openmanage and OMSA 9.1.0 

Dell - Internal Use - Confidential  

Hello Mr Jacobson,

Thank you for letting us know about this issue. Can you please help us
providing the below commands response for further analysis?
1. ipmitool sensor | grep CMOS
2. ipmitool sdr | grep CMOS

Regards,
Chandra 


   1. Re:  check_openmanage and OMSA 9.1.0 (Robert Jacobson)


----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Feb 2018 07:02:36 -0500
From: "Robert Jacobson" <teri...@gmail.com>
To: <linux-poweredge@dell.com>
Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Message-ID: <005f01d39f42$61d62b40$258281c0$@gmail.com>
Content-Type: text/plain;       charset="UTF-8"


FWIW, I ran into a similar error on an ancient PE2950 with a PERC 5/I
controller.  But on my server, it was the CMOS Battery presence detection
that failed with OMSA 9.1.0.  Reverting to OMSA 8.5.0 fixed the problem.


# /usr/lib64/nagios/plugins/check_openmanage -d
   System:      PowerEdge 2950 II        OMSA version:    9.1.0
   ServiceTag:  xxxxxxx                  Plugin version:  3.7.12
   BIOS/date:   2.7.0 10/30/2010         Checking mode:   local
[...]
CRITICAL |    0 | Battery probe 0 [System Board CMOS Battery] is Absent

# /usr/lib64/nagios/plugins/check_openmanage -d
   System:      PowerEdge 2950 II        OMSA version:    8.5.0
   ServiceTag:  xxxxxxx                  Plugin version:  3.7.12
   BIOS/date:   2.7.0 10/30/2010         Checking mode:   local
[...]
      OK |    0 | Battery probe 0 [System Board CMOS Battery] is Good

-----Original Message-----
From: Linux-PowerEdge [mailto:linux-poweredge-boun...@dell.com] On Behalf Of
Grant McChesney
Sent: Wednesday, January 24, 2018 10:20 AM
To: linux-poweredge@dell.com
Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0



On Thu, Dec 28, 2017 at 5:18 AM, Stephen Berg (Contractor, Code 7320)
<stephen.berg....@nrlssc.navy.mil <mailto:stephen.berg....@nrlssc.navy.mil>
> wrote:


        On 12/26/2017 11:17 AM, Stephen Berg (Contractor, Code 7320) wrote:
        

                On 12/26/2017 10:55 AM, Patrick Boutilier wrote:
                

                        On 12/26/2017 09:26 AM, Stephen Berg (Contractor,
Code 7320) wrote:
                        

                                Been updating quite a few systems to OMSA
9.1.0 on SciLinux 7.4 the last few days.  Something in there is breaking my
check_openmanage services in check_mk.
                                
                                The last time this happened it was finally
figured out that a slight mod to
/opt/dell/srvadmin/etc/srvadmin-storage/stsvc.ini fixed the issue.  I had to
make one change in that file:
                                
                                "vil7=dsm_sm_psrvil" needed to be ";
vil7=dsm_sm_psrvil"
                                
                                That same change now does not seem to be
working.  Checked that srvadmin-services.sh reports all the services are
running.
                                
                                During the update to the srvadmin packages
that stsvc.ini file was created as stsvc.ini.rpmnew.  Tried using it as is
and with the vil7 line commented out and still no luck seeing any
controllers in the system with omreport.
                                
                                Anyone else seeing this and found a
fix/workaround?
                                
                                


                        What error are you getting? Works fine here on
CentOS 7.4 after a "srvadmin-services.sh restart" .
                        

                On these two M610's which are pretty much identical I get
one failure and one succeeds.
                
                [root@hostname1 ~]# omreport storage controller
                No controllers found
                
                [root@hostname2 ~]# omreport storage controller
                 Controller  PERC H700 Modular(Embedded)
                
                Controller
                ID                                            : 0
                Status                                        : Ok
                Name                                          : PERC H700
Modular
                Slot ID                                       : Embedded
                State                                         : Ready
                Firmware Version                              : 12.10.6-0001
                <snip>
                
                I've restarted the OMSA services even rebooted one of the
systems where I'm seeing the problem.  It doesn't want to see the controller
after all that.  The system is working just fine besides not being able to
run any omreport functions for storage.
                
                


        I have figured out that removing OMSA 9.1 and reinstalling with 8.5
fixes the problem.  So far I've only seen this issue on a couple dozen
M610's and R610's.  Other systems (of the same models) are not affected.  I
think it comes down to which RAID controller is installed but haven't had
time to confirm that yet.




        -- 
        *Stephen Berg*
        Systems Administrator
        NRL Code: 7320
        Office: 228-688-5738 <tel:228-688-5738> 
        stephen.berg....@nrlssc.navy.mil
<mailto:stephen.berg....@nrlssc.navy.mil> 
        NRL Logo
        
        


I have the same issue running OMSA 9.1 and CentOS 7 on R410s with SAS 6/iR
Integrated (Embedded) controllers. Downgrading to OMSA 8.5 is the only
workaround I've found so far. Other servers with PERC 6/i Integrated
(Embedded) controllers work fine with 9.1.



------------------------------

Subject: Digest Footer

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

------------------------------

End of Linux-PowerEdge Digest, Vol 165, Issue 3
***********************************************

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Reply via email to