Hi, I'm also seeing storage controllers missing after a recent update to Scientific Linux 7.4 / OMSA
The affected servers are 11th generation PowerEdge R410 and R610. Newer generation servers (R620,R630,r730xd) work fine. Exemplary on a R410, I see the same results as reported above: # ipmitool sensor | grep CMOS CMOS Battery | 0x0 | discrete | 0x0080| na | na | na | na | na | na # ipmitool sdr | grep CMOS CMOS Battery | 0x00 | ok Best regards, Karsten On Thu, Feb 8, 2018 at 1:06 PM, Stephen Berg (Contractor, Code 7320) < [email protected]> wrote: > 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:stephen.berg.ctr@nrlss >> c.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> >> [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 >
_______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge
