iDRAC7 goes unresponsive - can't connect to iDRAC7
Spontaneous hanging: with time iDRAC7 turns unresponsive and nothing but reboot via
I-button can fix the problem. Sometime you need to shutdown the server and remove server power cables
to fix this problem.
DRAC 7 is a specialized computer (on a separate card) which is powered directly (always on). It is
not affected by server power button. But it has its own reboot button of the front pnel called i-button.
While here Dell beats HP (which can't do even that) that create a very difficult situation when you
use it for remote access to the server on the other continent without access to the server by qualified
on site personnel and both the server and DRAC hang. It's a real SNAFU for Dell.
Unfortunately this affects DRAC 7 on R620 and probably on all rack servers. Blades are not affected
as DRAC in blades can be rebooted from the enclosure controller.
This is essentially the same blunder as as HP SNAFU with
iLO 3 -- often it became irresponsive with time
and after that you can't connect neither via Web interface, no via ssh. In this state no ports are visible,
if you try to scan the IP-address using nmap from the other server on the same network.
Older version often hangs if console is opened and default timeout reached. The most recent hands
after some time of being up (around a month). So you have the situation, when the last time
you use DRAC it was OK, then the next time, in a month or two you can't connect. See
iDRAC7 may become slow or unresponsive after several weeks of continuous usage.
There are several ways to reset DRAC:
If DRAC is still alive you can reboot it via ssh, or racadm.
In case you don't have personnel on a remote site and you experience this situation with rack mounted
server, or if blade sever does not reacts to the attempt reboot the DRAC from the enclosure "frozen"
DRAC is a real SNAFU. It's so sad that in the rat race for additional functionality Dell engineers forgot
the primary purpose of the DRAC -- to be reliable KVM. The main criteria of its usefulness --
reliability, and if DRAC hangs the situation is much worse that its complete absence (in this case you
just buy a standalone KVM).
| In case you don't have personnel on a remote site and you experience this situation with
rack mounted server, or if blade sever does not reacts to the attempt reboot the DRAC from the
enclosure, "frozen" DRAC is a real SNAFU. It's so sad that in the rat race for additional
functionality Dell engineers forgot the primary purpose of the DRAC -- to be reliable KVM.
The main criteria of its usefulness -- reliability, and if DRAC hangs the situation is much
worse that its complete absence (in this case you just buy a standalone KVM). |
Another bug that might be corrected in later versions of DRAC firmware is that timeout for console
is not affected by setting of timeout for WEB interface (the same problem that was observed in HP ILO
3). So long period of work with GUI console (installation of the OS is a typical example) reliably locks
DRAC.
But, in a way, DRAC went one step further that HP is this "spontaneous hanging" problem: it hangs
just after certain amount time of being up. No user input required ;-). Brilliant automation of locking
sysadmin out of the remote server !
Note: The default session timeout value is five minutes, you
need to increase it to more reasonable value, say 10800 seconds (which is upper allowed limit). You
can do it from Remote Access /Configuration/Services menu via HTTP. Increase /iDRAC
Settings/Network/Services/Web server timeout to 10800 sec which is 180 min or
3 hours. Uncheck "Automatic
System Lock"
tab (it is checked by default).
| Note: The default session timeout value is
five minutes, you need to increase it to more reasonable value, say 10800 seconds (max allowed
by DRAC). You can do it from Remote Access /Configuration/Services menu via HTTP. Uncheck
"Automatic
System Lock"
tab (it is checked by default). |
DRAC with firmware version up to and including 1.56.55 looks like a beta product which DELL does
not have money and resources and decided to ship "as is" for debugging by the users. It still hands
during regular operations, for example operations with vFlash. Again, this "internal crash of OS" lead
to the situation in which DRAC enters "dead" state, that state in which no ports are opened.
There were few cases when the crash is partial and you can get to the initial screen of the WEB interface.
But attempt to login producing infinite display of "Verifing credentials" message. In
other words this message with rotating ring icon are running forever.
This is so similar to ILO 3 behavior that I suspect that both Dell and HP licensed the codebase from
the same source.
Recent version, such as 1.57.57 are better but still hands during regular operations, for example
if you perform some operations with vFlash. This vFlash GUI is definitely semi-debugged. also they require
recent version of Lifecycle controller and BIOS to the installed too. God forbid you to update just
DRAC firmware, you might completely hose the box and DRAC even after shutting server down and removing
cable will remain un-operational, or operational for a minute or two, after which it hangs.
I would like to stress that the gravity of this situation is that for rack or standalone server like
R620 you need to shutdown the server, disconnect cables and reconnect them and reboot the
server just to make DRAC working again.
NOTE:
After you re-connect the power cables DRAC access is not instant. Booting DRAC is a long
process that last probably a couple of minutes. Please be patient, and do not attempt disconnecting
and reconnecting the server before, say, five minute period. If in five minute DRAC is still dead
then another attempt is warranted.
That means the for the remote rack servers instead of providing remote administration services DRAC
became a nuisance. It is worse then no DRAC ;-). This is a huge SNAFU for DELL. And as for use in remote
site without qualified personnel it makes any such Dell rack server a lemon.
Again this problem exists in the most ugly form only for remote rack servers, as for blades there
is a way to reset the DRAC within CMC console.
| In a month or two DRAC spontaneously became irresponsive and after that you can't connect
neither via Web interface, not via ssh. In this state no ports are visible. Looks like either
network layer or the whole imbedded computer OS crashed. |
Random hangings of iDRAC7 on R620 when you can't connect to it remotely either via ssh or HTTPS proved
to be very consistent if you access DRAC with large intervals.
What Dell (unlike
HP and CISCO) did right is that on rack servers like R620 and R720 it provides a button with the letter
i on it (i-button) to reset DRAC on the front panel of the server. On R620 it is to the right of power
button and it has letter i on it. On R710 it is below (shown on the picture).
In order to reboot the iDRAC you need to press the button for 20 sec,
Paradoxically despite chronic problems with DRAC this button is well kept Dell secret and it is easy
to learn about its existence by placing a support call.
I was unable to get information about
it (and does not suspect about it existence for the first 9 month of the life of my first R620 server
despite opening several tickets about DRAC problems.
Note: on M1000e enclosure you can reset drac from
enclosure interface. See
Theoretically instead of racadm you can try to reboot DRAC from the server OS using
the ipmitool command from ipmitool-1.8.11-16.el6.x86_64 package. And there are several
post on the Internet suggesting this command:
ipmitool mc reset warm
It does not work with Dell DRAC Enterprise edition. Use a local installation of racadm instead. In my
version of impitool even command ipmitool mc info hangs with iDrac7 Enterprise edition.
Attempt to find channel does not work either (MykoSpark blog,
February 25, 2014):
for channel in {0..15}; do
ipmitool lan print ${channel} &>/dev/null
[[ $? -eq 0 ]] && echo "${channel}"
done
IPMITool is separate non-Dell software, and it looks like Dell does not provide support for it for iDRAC7
Enterprise. IPMI is also used extensively in the BMC, which is a remote management tool with significantly
reduced functionality compared to iDRAC 7 enterprise.
Looks like you cannot reset the iDRAC using ipmitool.
You can do it using either ipmitool or racadm. In the letter case reset can be
done from computer other then the computer on which DRAC is installed but you need to provide password
to DRAC. The frequency should be at least once a week. My experiments had should that two weeks
(1 and 15 each month) are not enough to prevent freezing:
00 5 * * 1 /opt/dell/srvadmin/bin/racadm5 -r z99-rm -u root -p xxxxxx racreset
This RACADM tool provide command line
interface allowing to script set-up and update of DRAC. So it you have a lot of identical or similar
Dell servers (for example Dell enclosure with 165 blades) it has additional value as automation tool
for routine operations
- 1.57.57 A04 It is mandatory to upgrade BIOS and Lifecycle controller firmware before
applying this version, especially if you upgrading from 1.56.55. With old version
of lifecycle controller and BIOS update can make the situation worse -- DRAC will crash all the
time staying "well" just for short period time after reboot. DRAC still freezes but when it is up
working with it is simpler and more reliable then with previous version. But even with the last
version of both lifecycle controller and BIOS the problem still is not solved.
To stay functional DRAC requires periodic reset can be done via cron weekly on byweekly as described
above. You can also use ipmitool command to do it from the server (see above).
Note: resetting DRAC also fixes the "slowdown effect" --
DRAC with time became slower and slower to the level then it is a pain to work with. This probably
should be the first operation you should do when you logged to the DRAC after a long time
(if you can login at all :-).
-
1.56.55, A00 (Released 03/11/2014). Usable. It's a better version then previous (especially
in handling vFLash which was very buggy in prev versions), but still does not solve the problem.
And "DRAC-hanging" problem is less pronounced, but still exist. It also needs updating lifecycle
controller and BIOS simultaneously with updating DRAC firmware. I also recommend adding
additional users and setting console expiration time to max and no action on timeout.
- 1.46.45 (Build 04). Unusable. The initial version on which I first experienced
this problem. This is horrible, simply horrible version which can't be called production version
by any stretch. Shame on Dell for releasing this junk.
| In case you don't have personnel on a remote site this is a disaster and big SNAFU for
DELL. In the rat race for additional functionality they forgot the primary purpose of the DRAC
-- to be reliable KVM -- and the main criteria of its usefulness -- reliability. |
From Google search on the topic it is clear that this problem exists since the release of DRAC7 at
the beginning of 2013. It still is not fixed as of version 1.57.57. The problem is acute only
for remote servers without any qualified personnel to access the server.
| From Google search on the topic it is clear that this problem exists since the release
of DRAC7 at the beginning of 2013. Many users just don't notice this problem as they have local
server and install OS using regular keyboard and monitor. The problem is acute only for remote
servers without any qualified personnel to access the server. |
Hard crash:
This problem was already discussed above,. It is still not fixed in the most recent version of Dell
firmware. Preventive measure that works is periodic reboots of DRAC via cron (see above)
This is slightly different but similar problem to spontainious death after certain number of days
up
This one was probably fixes in the most recent version of firmware. From my experience with similar
situation in ILO 3 I suspect that at least partially this issue might be connected with incorrect
processing of timeout of login session. I recommend explicitly logout when you finish your
work with DRAC. One useful tip is to increase /iDRAC Settings/Network/Services/Web server timeout
to 10800 sec which is 180 min or 3 hours.
| TIP: increase /iDRAC Settings/Network/Services/Web server timeout to
10800 sec which is 180 min or 3 hours. But looks like in version up to 1.51.57 the
bug prevent any this change from working. In other words you change timeout but actually it
stays the same. |
As installation of OS requires more time that extended timeout of console that supposedly cause hanging
of DRAC this problem is more severe when there is no OS installed on the server.
Three things to do to minimize this horrible effect are:
- Set
"Default action upon session sharing request timeout" to "Full access"
- Uncheck "Automatic
System Lock"
tab (it is checked by default,
- Max the lockout period to 10800 sec (this should be done in different place: iDRAC
settings/Network/Services). It looks like iDRAC has a bug that does not allow to actually change
those settings and lockout happens in 30 min anyway (instead of 180) but at the least change provides
psychological comfort. Dell programmers should look into it because this is just extremely silly,
amateurish bug.
One way to avoid this during the installation of OS is to use build in Linux installer (such
as
anaconda) ability to switch to VNC.
If you have KVM on site, such as Avocent, you also can try to use to use temporary Avocent connection
to solve the problem of abrupt loss of console during OS installation.
| Using
anaconda ability to switch to VNC or Avocent KVM connection can help to solve the problem
of abrupt loss of console during OS installation |
If might well be that certain version of DRAC require updated version of lifecycle controller. So
it make sense to update both. Not that it helps, but still ;-). The same is true for BIOS.
All three should be upgraded to recent versions, not only DRAC. For version 1.57.57 A04
it is mandatory to upgrade BIOS and Lifecycle controller firmware before applying
this version, especially if you upgrading from 1.56.55.
In case of hard crash of DRAC on Dell rack servers currently the only solution is to use i-button
(see above). Which is much better that to power the rack server down, disconnect cables, and the power
it back, the steps I learned very well with HP servers.
Preventive reboots via cron are highly recommended if you experience this problem. Two weeks
interval might work well.
It goes without saying that this still defeats the idea of remote administration. So, in a way, Dell
got in the same SNAFU as HP with ILO 3.
The severity of this problem for Dell rack servers is greatly less then in case of HP as Dell engineers
provided a reboot button for DRAC. This capability is present for blades as you can rebott DRAC from
enclosure controller, but for obvious reasons it proved to be extremely useful for standalone and rack
servers too.
In case i-button does not work, shutting down the server and disconnecting the power cables is necessary
for "reviving" of hanged DRAC.
| The severity of this problem for Dell rack servers is greatly less then in case of HP
as Dell engineers provided a reboot button for DRAC. |
Still this is a serious SNAFU for Dell which essentially makes the remote management of Dell rack
servers problematic. To less extent then HP servers but still reliable remote management is especially
important to remote system administration. In other words Dell got into "HP trap". See
iLO 3 -- HP engineering fiasco
In case you don't have personnel on a remote site this is still a disaster. In the rat race
for additional functionality Dell like HP forgot the primary purpose of the DRAC -- to be reliable KVM
-- and the main criteria of its usefulness -- reliability.
The problem is acute only for remote servers without any qualified personnel to access the server.
Issue:
Servers utilizing an iDRAC7 may become slow or completely unresponsive after approximately 45
to 100 days of continuous use.
Solution:
Update iDRAC7 firmware to version
1.57.57 or higher.
Workaround:
Perform a RACADM RACRESET every 30 days or prior to the iDRAC7 becoming unresponsive.
Once the iDRAC7 becomes unresponsive, perform an AC power reset on rack and tower server models,
or a Virtual Reseat on a Blade server.
Additional Information:
iDRAC7 firmware versions 1.50.50 through 1.55.55 does not disable the extra debug logging, which
will eventually cause the iDRAC7 memory to be filled as the log file grows. As available memory
decreases, performance can be reduced and eventually the iDRAC7 may stop responding. This
occurs approximately after 45 to 100 days of continuous operation. The issue may be accelerated
when using OMSA and OME.
The latest
RACADM Command Line Reference Guide is for version 1.57.57. An updated version should
be released soon.
iDRAC7 firmware version 1.57.57 supersedes all previous versions of 1.5x.5x. The versions
that exhibit this problem have been removed from our website.
Additional information about the iDRAC can be found at the
Dell TechCenter Systems Management page.
nadogmoney
We have a random issue with idrac7 (R620s) where the idrac becomes almost totally unresponsive
but magically seems to fix itself within 24 hours.Here is what we have observed:
- "ERROR: Unable to perform requested operation" errors message when trying to run local
racadm commands. Occurs on Windows and Linux
- No ssh access to the idrac. The ssh attempt hangs then reaches the timeout.
- No idrac webpage access or limited access
- Ping still works to the idrac
- The idrac tracelog has missing content for the problem time then logs start appearing
when the idrac resets itself.
- Draining flea power fixes the issue but this is not an acceptable solution for OOB managment.
Has anyone else seen this?
I dont have an SR open but have been in contact with Dell IPS.
nadogmoney
I think my issue is fixed with idrac7 FW 1.37.35. There was a memory leak which was fixed.
I ran "racadm racdump" and looked for memory usage deltas.
Dell-Chris H
Nadogmoney,
Is the server currently up to date? Also, to clarify, you said that you were running local
racadm commands, but also say you tried linux and windows to connect, was this remotely?
What is the racadm command you are trying to run?
Lastly, have you tried uninstalling Rac Tools and reinstalling.
Let me know what you find.
Dell | Social Outreach Services - Enterprise
Get Support on Twitter @DellCaresPro
Download the Dell Quick Resource Locator app today to access PowerEdge support content on your
mobile device! (iOS, Android, Windows)
nadogmoney
Chris H,
We are two revs back on production systems:
PowerEdge R620
Bios Version = 1.2.6
iDRAC Version = 1.23.23
USC Version =
1.0.8.42
Racadm commands were run locally on Windows and Linux. Remote racadm was not tried.
Any local racadm command gets "ERROR: Unable to perform requested operation"
We have not uninstalled rac tools and reinstalling. The issue has persisted from OMSA 7.1 to
7.2 so we may have covered this testing when running 7.2. Also, not being able to ssh and use
the web gui point to the cause not being rac tools related.
John Lloyd
jal at mdacorporation.com
Mon Apr 29 11:42:31 CDT 2013
We've been seeing intermittent issues with this -- the remote console fails to start, or once started then stops with "session disconnect" in the bottom left-land-corner of the screen. Sometimes it just hangs (for hours -- I have a lot of patience). Restarting IE seems to resolve this, but then I only start IE just to connect to the iDRAC so it seems wrong. Resetting the iDRAC also helps often.
IE 8 seems not so bad.
We've updated to latest 1.37.35 firmware. We use native access (activeX not java). These are Enterprise iDRAC with their own Ethernet interface, we have 6 on various models (r620 r720), all seem to show similar symptoms.
Is there any magic to getting remote console to reliably work?
--John
Mike Says Meh
Recently ran into an issue with a Poweredge r620 and iDrac. The server was up but giving a memory
error and I couldn't get into iDrac. This is the error I saw when trying to login.
RAC0218: The maximum number of user sessions is reached
Very frustrating when I knew there was no one else logged in. A brief search online revealed
that we can reset iDrac through SSH, but that didn't help since even SSH gave the same error when
trying to login. The server is in a data center and I avoid the data center like the plague. I know
there are some sys admins that just love the DC, the rows and rows of servers, the unbearable noise,
the too hot and too cold isles. Maybe I'm old, or I've been doing this too long ...
If the OS is working you can use a tool in Dell OpenManage to reset iDrac remotely.
1. Make sure you have Dell OpenManage installed on the server.
Download here.
2. Next open a command prompt as Administrator and CD to "C:\Program Files\Dell\SysMgt\idrac".
3. Now run the command "racadm racreset soft" (without the "" of course). racadm is the iDrac
CLI admin, racreset is the subcommand, and soft is the parameter. This particular subcommand has
3 different methods to restart Hard, Soft, Graceful, and you can also delay the restart. I recommend
that you start with a soft reset so you don't lose your settings. I imagine a hard reset would remove
your login info, TCP/IP settings, etc. To be honest I haven't tested it to find out since the servers
I have are in production. You can find more info
here.
- A hard reset resets the entire RAC and is as close to a power-on reset as can be achieved
using software. The RAC log, database, and selected daemons are shutdown gracefully prior to
the reset. A hard reset should be considered as a final effort. PCI configuration is lost.
- A soft reset is a microprocessor and microprocessor subsystem reset that resets the processor
core to restart the software. PCI configurations are preserved. The RAC log, database, and selected
daemons are shutdown gracefully prior to the reset.
- A graceful reset is the same as a soft reset.
- The user is allowed to select how many seconds of delay occur before the reset sequence
is started. A valid delay entry is between 1-60 seconds. The default is 3 seconds.
4. After running the command you should see the message below.
RAC reset operation initiated successfully. It may take a few
minutes for the RAC to come online again.
5. Give it a few minutes and then try and login to iDrac through the web interface or SSH. I
was able to after running this reset.
6. If you still cannot login you can try a hard reset. Run the command "racadm racreset hard".
7. If that doesn't work, there is one last option but you'll need to physically access the server.
Shut the server down then pull the power from it. Make sure there is no AC power to the server.
Then hold the power button on the server for 30 seconds. This should completely reset the iDrac.
You may need to reconfigure your login information and TCP/IP settings.
Tagged as:
Dell,
iDrac,
PowerEdge
Leave a comment
Comments (3)Trackbacks
(0)(
subscribe to comments on this post )
November 12, 2011
by
superjameszou
#!/bin/bash
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 mc info
sleep 2
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 sensor
while true;
do
#ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 mc reset cold
echo BMC IP $1 Cold Reset and wait for 68 Sec. Date : `date`
count=$((count+1))
echo Success: "$count" times
sleep 7
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 mc info
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 sdr
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 sensor
ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 lan print
#ipmitool -I lanplus -U ADMIN -P ADMIN -H $1 -t 0x2C mc info
sleep 1
done
Softpanorama Recommended
Society
Groupthink :
Two Party System
as Polyarchy :
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers
and Control Freaks : Toxic Managers :
Harvard Mafia :
Diplomatic Communication
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
: The Iron
Law of Oligarchy :
Libertarian Philosophy
Quotes
War and Peace
: Skeptical
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Classic books:
The Peter
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater’s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
Humor
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Last modified:
October, 13, 2020
July 7th, 2014 - 21:39
thanks for the info, none of the software resets was helping for me sadly so I had to physically go there for a reset.
but instead of powering off the server, the owners manual says you can hold the glowing blue 'i' system identification button on the back down for 15seconds and it resets the drac, worked for me.
StevenOctober 1st, 2014 - 05:48
I faced a similar problem, but holding the blue 'i' button didn't do it for me either. Reasoning that iDRAC is nothing more than some chrome sprayed over IPMI, I figured I'd try it over the direct IPMI route. I still had access to the O/S, so I installed "ipmitool" and "ipmitool mc reset cold" did the trick in the end (it takes a while for the MC to reset itself, so be patient).
Needless to say, I'm now configuring "lanplus" on the bare IPMI as well.
Mike KauspedasOctober 1st, 2014 - 12:23
That sounds neat. Is this what you are doing?
http://serverfault.com/questions/398759/force-dell-idracs-and-bmcs-to-use-lanplus-instead-of-lan-interface