I find myself going back to the same text file with ipmitool command that I use most often. I figured I should add them here in case anyone else needs a quick list of the most useful commands (at least to me). These are all commands that I use remotely to check on/power cycle servers. Also, I only really use these on Dell Poweredge servers. So if your servers have some goofy IPMI implementation, then they might not work the same. I will probably do a post soon on setting up the IPMI controller with ipmitool.
The different options used are:
- -I lan = tells ipmitool to use the network to send commands instead of interfacing with the local IPMI controller on the server you’re running it from
- -H <IP> = The IP of the IPMI controller you want to access. NOTE: This is not the server’s main IP. The IPMI controller should have it’s own unique IP.
- -U root = The username you want to connect to the IPMI controller with. Leave this as root unless you set up custom users.
- You can also use “-P <PASSWORD>” with the password on the command line, but be advised that it will store the password in your history file and may be visible to other users (through “ps” or similar).
For sensor/temp data in compact format:
ipmitool -I lan -H 10.0.0.1 -U root sdr
For sensor/temp data in wide table format:
ipmitool -I lan -H 10.0.0.1 -U root sensor
More verbose output:
ipmitool -I lan -H 10.0.0.1 -U root sensor -v
System event log:
ipmitool -I lan -H 10.0.0.1 -U root sel list
Same event log data, but more human readable:
ipmitool -I lan -H 10.0.0.1 -U root sel elist
Clear event log:
ipmitool -I lan -H 10.0.0.1 -U root sel clear
Power off chassis (does not do clean shutdown):
ipmitool -I lan -H 10.0.0.1 -U root chassis power off
Power on chassis:
ipmitool -I lan -H 10.0.0.1 -U root chassis power on
Power cycle (power off of 1 second):
ipmitool -I lan -H 10.0.0.1 -U root chassis power cycle
ipmitool -I lan -H 10.0.0.1 -U root chassis power reset
If you have any suggestions for frequently used commands, let me know and I’ll add them.
The full list of commands can be found in the man page here: http://ipmitool.sourceforge.net/manpage.html
If you have ever had to call the technical support of any of the major computer manufacturer’s, then you know the pain of outsourced technical support.
You know what I’m talking about… You have a problem with your new computer, so you call the support number. You wade through the annoying voice menus, which take even longer and are more annoying if you have to speak the answers, trying to get to a person. When you finally get to a person, you get someone with a less-than-acceptable grasp of the English language. They always have a thick Indian accent, and some American sounding name like “John” or “Michael” (like they are fooling anyone). Congratulations, your call has just been outsourced to India.
A lot of the computer manufacturer’s all outsource to India. HP, Dell, Acer, and others all do it. They are all trying to cut costs by aggravating their customers. Now, how do you get past this?
A guy I work with let me in on a little secret to get USA based tech support. He was helping his mother with a computer she bought. She called the tech support line, and since she speaks Spanish as her native language, chose “2” at that first prompt that said hit “2” for Spanish. She was having trouble with them on the phone, so he took over the call. Apparently the guy on the other end of the line didn’t speak Spanish that well, and he was having trouble understanding. So he asked the guy “do you speak english?” The guy answered “Yeah, what’s up”. And there we have it. He finished the tech support call and asked the guy where he was. Apparently this guy was in California. This makes perfect sense when you think about it. Nobody in India speaks Spanish really, so they open a call center in California or somewhere else with a large Hispanic population just to handle the Spanish technical support. So all you need to do to talk to US based tech support, is to choose Spanish! They will always speak English also, and will be more than likely willing to help you. It seems like a crazy concept to choose Spanish to get someone who can actually speak English, but it works.
My friend has done this a dozen times since then, and says it has worked every time. So if you can’t get through to the guy in India, give this method a try.
So I needed to install Debian 5.0 Lenny x64 on a server at work. It happened to be a new model PowerEdge R710. We don’t really support Debian, so on the odd occasion it needs to be installed we do it by CD. I was using a net-install CD to start the installer as I normally do. The only problem was the installer would not recognize the NIC. Since this was a net-install CD, it tends to be a problem. I can’t go forward with the install and load the NIC drivers later.
So I do some research on google, and find out that I have the Broadcom 5709 chipset for the NIC card. It also needs some non-free firmware to load, which is apparently why it would not load automagically.
I then download all the files needed, and put them on an external floppy. I figured I would load them and be on my merry way… Wrong.
No matter what I did, I could not get it to load the NIC drivers/firmware and work. I tried everything I could think of for almost 2 hours. It also did not recognize the Perc 6 and RAID array, but that did not matter if I can’t even get the NIC to work. It was just another thorn in my side knowing there was another battle with the RAID controller drivers after I got the NIC working.
I eventually found out what the cause was. The BIOS.
The R710 I was trying to install on had BIOS version 1.0.4. I updated it to version 1.1.4 found Here. Apparently the new version fixes some PCI bugs that were giving me problems.
After that, the install ran mostly normal. It recognized the Broadcom NIC, and popped up a message saying it needed non-free firmware. I loaded the files I got from the debian mirror HERE on to a floppy, and loaded them into the installer. After that, it worked normally. It even recognized the RAID array on it’s own.
So after all that misery, it turned out to be a BIOS update. The only way I figured it out, was that we had another R710 with Debian installed the night before with no issues. After looking at it I noticed it had a newer BIOS version.