Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Hello Rajkumar, thank you for the information. Still, two questions remain: - Is there any workaround available until the fixed OMSA release is available? E.g. by fiddling around with some config files in /opt/dell/srvadmin ? - Will it really be October 2018 until the fixed version will be available? This issue has been reported in December 2017, confirmed 5 months later and another 5 months until fix availability. That is a very long time period :( Regards, Stefan - Original Message - > From: "Rajkumar S H" > To: linux-powere...@lists.us.dell.com > Sent: Wednesday, May 2, 2018 9:23:48 AM > Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0 > Dell - Internal Use - Confidential > > > > Hi Stefan, > > > > > > This is issue is fixed in current release and it will be available in October > 2018. > > > > > > Thanks and Regards > Rajkumar > > > > > > ___ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > https://lists.us.dell.com/mailman/listinfo/linux-poweredge ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Hi Rajkumar, On Wed, May 2, 2018 at 12:23 AM, wrote: > This is issue is fixed in current release and it will be available in > October 2018. Could you please explain how a *current* release could still be *6 months away* from availability? The commonly accepted definition of "current" is along the lines "available now", give or take days. But definitely not 6 months. Could you please clarify? Cheers, -- Kilian ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Dell - Internal Use - Confidential Hi Stefan, This is issue is fixed in current release and it will be available in October 2018. Thanks and Regards Rajkumar ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Hello Vivek, the problematic "SAS 6/iR Integrated" controller is running with the latest Firmware 00.25.47.00.06.22.03.00 [1]. Neither a restart of OMSA nor a reboot of the whole machine changed anything, controllers are not recognized by OMSA. In my case, I am running CentOS 7.4, but I can also reproduce the problem with Scientific Linux 6.9 (Rebuild of RHEL 6.9). As I wrote earlier, the PERC controllers are unaffected and running fine. Output of OMSA 8.5.0: [root@host ~]# omreport storage controller Controller SAS 6/iR Integrated(Embedded) Controller ID: 0 Status: Ok Name : SAS 6/iR Integrated Slot ID : Embedded State : Ready Firmware Version : 00.25.47.00.06.22.03.00 Minimum Required Firmware Version : Not Applicable Driver Version: 3.04.20 Minimum Required Driver Version : Not Applicable Storport Driver Version : Not Applicable Minimum Required Storport Driver Version : Not Applicable Number of Connectors : 1 Rebuild Rate : Not Applicable BGI Rate : Not Applicable Check Consistency Rate: Not Applicable Reconstruct Rate : Not Applicable Alarm State : Not Applicable Cluster Mode : Not Applicable SCSI Initiator ID : Not Applicable Cache Memory Size : Not Applicable Patrol Read Mode : Not Applicable Patrol Read State : Not Applicable Patrol Read Rate : Not Applicable Patrol Read Iterations: Not Applicable Abort Check Consistency on Error : Not Applicable Allow Revertible Hot Spare and Replace Member : Not Applicable Load Balance : Not Applicable Auto Replace Member on Predictive Failure : Not Applicable Redundant Path view : Not Applicable CacheCade Capable : Not Applicable Persistent Hot Spare : Not Applicable Encryption Capable: Not Applicable Encryption Key Present: Not Applicable Encryption Mode : Not Applicable Preserved Cache : Not Applicable T10 Protection Information Capable: No Non-RAID HDD Disk Cache Policy: Not Applicable [1] http://www.dell.com/support/home/de/de/dedhs1/drivers/driversdetails?driverId=G5TG7 Regards, Stefan - Original Message - > From: "Vivek S1" > To: linux-powere...@lists.us.dell.com > Sent: Tuesday, April 24, 2018 8:40:35 AM > Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0 > Dell - Internal Use - Confidential > > Hello Stefan, > > Just wanted to check if the Firmware is up to date. > > PERC H200 Integrated F/W --> > https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=D0KPX > > Further I want to share the context herewith. > H200/SAS6iR are officially supported with RHEL 6.7 as such with OpenManage 8.3 > version. (just googled to get this) > http://www.dell.com/support/manuals/us/en/04/dell-openmanage-software-v8.3/om_support_matrix/sas-6ir-integrated-and-adapter?guid=guid-d398d5b9-71da-4f2b-a35b-f39381d5ae5d&lang=en-us > > Now with latest RHEL 6.9 available, we got to try and see if this works. But > could you cross check if the Firmware are latest to start with. > Also if there could be a possibility, request to restart OpenManage services, > just to be sure if things can come back from baseline. > Give it a try and let us know. Thanks > > Regards, > Vivek > > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of linux-poweredge-request-Lists > Sent: Thursday, April 19, 2018 10:30 PM > To: linux-poweredge-Lists > Subject: Linux-PowerEdge Digest, Vol 167, Issue 17 > > Send Linux-PowerEdge mailing list submissions to > linux-poweredge@dell.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.us.dell.com/mailman/listinfo/linux-poweredge > or, via email, send a message with subject or body 'help' to > linux-poweredge-requ...@dell.com > > You can reach the person managing the list at > linux-poweredge-ow...@dell.com > > When replying, please edit your Subject line so it is more specific than "Re: >
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
Dell - Internal Use - Confidential Hello Stefan, Just wanted to check if the Firmware is up to date. PERC H200 Integrated F/W --> https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=D0KPX Further I want to share the context herewith. H200/SAS6iR are officially supported with RHEL 6.7 as such with OpenManage 8.3 version. (just googled to get this) http://www.dell.com/support/manuals/us/en/04/dell-openmanage-software-v8.3/om_support_matrix/sas-6ir-integrated-and-adapter?guid=guid-d398d5b9-71da-4f2b-a35b-f39381d5ae5d&lang=en-us Now with latest RHEL 6.9 available, we got to try and see if this works. But could you cross check if the Firmware are latest to start with. Also if there could be a possibility, request to restart OpenManage services, just to be sure if things can come back from baseline. Give it a try and let us know. Thanks Regards, Vivek -Original Message- From: linux-poweredge-bounces-Lists On Behalf Of linux-poweredge-request-Lists Sent: Thursday, April 19, 2018 10:30 PM To: linux-poweredge-Lists Subject: Linux-PowerEdge Digest, Vol 167, Issue 17 Send Linux-PowerEdge mailing list submissions to linux-poweredge@dell.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.us.dell.com/mailman/listinfo/linux-poweredge or, via email, send a message with subject or body 'help' to linux-poweredge-requ...@dell.com You can reach the person managing the list at linux-poweredge-ow...@dell.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Linux-PowerEdge digest..." Today's Topics: 1. Re: check_openmanage and OMSA 9.1.0 (Gregory Matthews) 2. Re: check_openmanage and OMSA 9.1.0 (Dietrich, Stefan) -- Message: 1 Date: Thu, 19 Apr 2018 09:12:18 +0100 From: Gregory Matthews To: "Stephen Berg (Code 7320)" , Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0 Message-ID: <6aea2137-d836-6fdf-a6f3-682f5a23d...@diamond.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed On 18/04/18 17:41, Stephen Berg (Code 7320) wrote: > > Gotten nothing as far as a fix goes.? It seems as if Dell is ignoring > this problem. > agreed. We have a bunch of 11G showing this problem even tho they are still in warranty! G -- Greg Matthews01235 778658 Scientific Computing Group Leader Diamond Light Source Ltd. OXON UK -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -- Message: 2 Date: Thu, 19 Apr 2018 13:27:58 +0200 (CEST) From: "Dietrich, Stefan" To: linux-poweredge Subject: Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0 Message-ID: <48500720.11956259.1524137278844.javamail.zim...@desy.de> Content-Type: text/plain; charset=utf-8 > On 18/04/18 17:41, Stephen Berg (Code 7320) wrote: >> >> Gotten nothing as far as a fix goes.? It seems as if Dell is ignoring >> this problem. >> > > agreed. We have a bunch of 11G showing this problem even tho they are > still in warranty! > > G > > -- > Greg Matthews01235 778658 > Scientific Computing Group Leader > Diamond Light Source Ltd. OXON UK I checked this again and it is really limited to the "SAS 6/iR Integrated" controller. Any PERC controller in a 11G server and OMSA 9.1.0 is running fine. At least for now, I will exclude the OMSA update for servers with that controller. Regards, Stefan -- 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 167, Issue 17 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
> On 18/04/18 17:41, Stephen Berg (Code 7320) wrote: >> >> Gotten nothing as far as a fix goes. It seems as if Dell is ignoring >> this problem. >> > > agreed. We have a bunch of 11G showing this problem even tho they are > still in warranty! > > G > > -- > Greg Matthews01235 778658 > Scientific Computing Group Leader > Diamond Light Source Ltd. OXON UK I checked this again and it is really limited to the "SAS 6/iR Integrated" controller. Any PERC controller in a 11G server and OMSA 9.1.0 is running fine. At least for now, I will exclude the OMSA update for servers with that controller. Regards, Stefan ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
On 18/04/18 17:41, Stephen Berg (Code 7320) wrote: Gotten nothing as far as a fix goes. It seems as if Dell is ignoring this problem. agreed. We have a bunch of 11G showing this problem even tho they are still in warranty! G -- Greg Matthews01235 778658 Scientific Computing Group Leader Diamond Light Source Ltd. OXON UK -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
On 04/18/2018 11:39 AM, Dietrich, Stefan 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 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. Hello Stephen, did you ever figure something out or received an answer from Dell for this issue? I have now run into the same situation, but so far only on M610 and M710: [M610]# omreport storage controller No controllers found This issue seems to be limited to the "SAS 6/iR Integrated" controller, e.g. all our M610 have this controller. A R510 with a PERC H700 is working fine with OMSA 9.1.0 Regards, Stefan Gotten nothing as far as a fix goes. It seems as if Dell is ignoring this problem. -- Stephen Berg, IT Specialist, Oceanography Division, Code 7320 Naval Research Laboratory W: (228) 688-5738 DSN: (312) 823-5738 C: (228) 365-0162 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
> 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 >> >> >> 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. Hello Stephen, did you ever figure something out or received an answer from Dell for this issue? I have now run into the same situation, but so far only on M610 and M710: [M610]# omreport storage controller No controllers found This issue seems to be limited to the "SAS 6/iR Integrated" controller, e.g. all our M610 have this controller. A R510 with a PERC H700 is working fine with OMSA 9.1.0 Regards, Stefan ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
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) < stephen.berg@nrlssc.navy.mil> wrote: > I see the same on an R610: > >System: PowerEdge R610 OMSA version:8.5.0 >ServiceTag: XXXPlugin 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: 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" >> To: >> 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 IIOMSA version:9.1.0 >> ServiceTag: xxx 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 IIOMSA 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) >> 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
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
I see the same on an R610: System: PowerEdge R610 OMSA version: 8.5.0 ServiceTag: XXX 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: 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" To: 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 IIOMSA version:9.1.0 ServiceTag: xxx 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 IIOMSA version:8.5.0 ServiceTag: xxx 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) 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:
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
# 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" To: 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 IIOMSA version:9.1.0 ServiceTag: xxx 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 IIOMSA version:8.5.0 ServiceTag: xxx 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) 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 I've restarted the OMSA services ev
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
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 IIOMSA version:9.1.0 ServiceTag: xxx 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 IIOMSA version:8.5.0 ServiceTag: xxx 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) 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 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 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) controlle
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> 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 >> >> >> 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 > 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. ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
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 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 stephen.berg@nrlssc.navy.mil NRL Logo ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
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 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. -- -- *Stephen Berg* Systems Administrator NRL Code: 7320 Office: 228-688-5738 stephen.berg@nrlssc.navy.mil NRL Logo ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] check_openmanage and OMSA 9.1.0
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" . <>___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
