Unsolved
This post is more than 5 years old
1 Rookie
•
19 Posts
0
7236
October 7th, 2012 16:00
DRAC4 Problem
I have a server that I manage which has a DRAC4 enterprise card in it. I recently took upon an initiative to change the SNMP community strings on all of the DRAC cards (DRAC4, DRAC5, and iDRAC6) in our infrastructure. This server, in particular, was having issues with reading the settings and applying the new settings. Figuring that maybe an updated firmware would help, I proceeded to update it as I did on quite a number of other servers without issue.
The update proceeded properly until the very end, due to IE's popup blocker. When it tried to refresh the page, IE blocked it, and so the update hung at 99%.
I went ahead and attempted to issue a racreset from the OS command line (we're using the latest Linux release of OpenManage, 7.1.0), but that failed with an error that a firmware update was in progress.
So we attempted the hard reset procedure I've seen mentioned elsewhere here, which is to power the server off, unplug the power cables and hold the power button in for 10 seconds, then plug it back in and power it on.
Unfortunately that did not work.
Next, we tried to swap the card out for a spare card. That seemed to work fine. I disabled the popup blocker and then updated the firmware again. This time it completed successfully. However, it still will not take the config settings, and the racreset command still says that a firmware update is in progress.
I left it alone for a couple of weeks, having other work to do, and came back tonight. Now, I get the message that the RAC cannot be communicated with.
Note that the DRAC interface is up and running just fine right now. The problem is that I need to set the cfgOobSnmpAgentCommunity string to something other than public.
I know I've read before that some of the DRAC stuff is stored on the motherboard. I've checked and made sure that /etc/sysconfig/dsm_sa_ipmi is configured the same as another production server with identical hardware.. Should we just go ahead and move the drives to another identical chassis which isn't in production yet, so that the motherboard and DRAC card are different, or is there something else we can try?
0 events found
Speeddymon
1 Rookie
•
19 Posts
0
October 8th, 2012 17:00
Is there a way to reset the the BMC like you can for the the CMOS? I haven't updated the BMC firmware on this server, maybe that would do it?
DELL-Jeff M
2 Intern
•
793 Posts
0
October 8th, 2012 17:00
The DRAC 4's really don't have anything on the system board, but they do interface with the BMC on the system board. If you've moved the DRAC 4 to another system and it still won't get out of the mid-firmware update state, then it may be stuck permanently. Some of the DRAC firmwares have a rollback feature on the same page where you update the DRAC from the web interface. Try that if the option is available, otherwise it is probably stuck.
DELL-Jeff M
2 Intern
•
793 Posts
0
October 9th, 2012 17:00
Updating the BMC might help, and the procedure to drain flea power on the server will reset it.
Speeddymon
1 Rookie
•
19 Posts
0
October 12th, 2012 21:00
Thanks for the updates. After attempting some more troubleshooting, we determined that the problem is happening from using the racadm command instead of racadm4. This was after swapping the drives, raid controller, and memory, to a new chassis with a different DRAC4 card and still seeing the same issue from 'racadm racreset'
Once we started using racadm4, things started working as they should. This is an R200 server by the way. Our R210's and PE2950s and R710's all properly work with racadm regardless of whether the RAC in use is DRAC4, DRAC5, or iDRAC6.
Is that possibly a bug?