I see the same on an R610:
System: PowerEdge R610 OMSA version: 8.5.0
ServiceTag: XXXXXXX Plugin version: 3.7.12
BIOS/date: 6.4.0 07/23/2013 Checking mode: local
OK | 0 | Controller 0 [SAS 6/iR Integrated] is Ready
OK | 0 | Battery probe 0 [System Board CMOS Battery] is Good
Didn't try it with OMSA 9.1.0 though.
On 02/08/2018 05:48 AM, Robert Jacobson wrote:
# 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: [email protected] [mailto:[email protected]]
Sent: Thursday, February 08, 2018 12:26 AM
To: [email protected]; [email protected]
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" <[email protected]>
To: <[email protected]>
Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Message-ID: <[email protected]>
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:[email protected]] On Behalf Of
Grant McChesney
Sent: Wednesday, January 24, 2018 10:20 AM
To: [email protected]
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)
<[email protected] <mailto:[email protected]>
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>
[email protected]
<mailto:[email protected]>
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
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
------------------------------
End of Linux-PowerEdge Digest, Vol 165, Issue 3
***********************************************
_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
--
Stephen Berg
Contractor
Code 7320
Naval Research Laboratory
W: (228) 688-5738
DSN: (312) 823-5738
_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
