It can be tiring focusing on one thing for too long. I can feel my body physically resistent to the code which I have spent many hours on. So today I spend the whole day with something seemingly boring but at least deviant from my previous work.
Google is always my (and our) best friend. If I didn't explain every detail in the following sections, you can leave a message below or email me for detail.
Update BIOS and firmware in Debian
The default Linux distribution supported by Dell is RHEL. Update process on Debian/Ubuntu can be a little different. In my case, the server is PowerEdge R910. Target BIOS is PowerEdge R910 BIOS 2.10.0. Target PERC firmware is DELL PERC H700 Int v12.10.6-0001,A12.
PERC firmware update
Reference: DELL PERC Firmware Upgrade on Debian amd64
The first thing to do is replace
bash for default shell
/bin/sh. Otherwise you will experience errors like "typeset is not found"
or automatic reboot.
Here is the list of commands:
sudo dpkg-reconfigure dash # choose No, make bash the default /bin/sh sudo aptitude install rpm libstdc++5 sudo ./SAS-RAID_Firmware_C3X7D_LN_12.10.6-0001_A12.BIN --extract /tmp/update cd /tmp/update rpm2cpio srvadmin-storelib-sysfs-7.2.0-4.1.1.el4.x86_64.rpm | sudo cpio -idmv sudo cp -a /tmp/update/opt/lsi/3rdpartylibs/x86_64/libsysfs.so* /opt/lsi/3rdpartylibs/x86_64 echo /opt/lsi/3rdpartylibs/ | sudo tee -a /etc/ld.so.conf.d/dellfw.conf echo /opt/lsi/3rdpartylibs/x86_64 | sudo tee -a /etc/ld.so.conf.d/dellfw.conf # update dynamic linker cache sudo ldconfig cd - sudo ./SAS-RAID_Firmware_C3X7D_LN_12.10.6-0001_A12.BIN
Follow the instructions and everything should be OK.
BIOS update is simpler.
Follow the instructions in installation program until you lose your patience with the screen full of dots. So WTF is the installation program doing?
Actually it stuck with the following process:
To avoid the hanging problem as well as a failure caused by "Unable to get
the System Generation", one solution is to add a file to cheat the
installation program. Put the following string in
Red Hat Enterprise Linux Server release 6.3 (Santiago)
To be honest, I don't know how I fixed this. But after searching and trial and error I finally got BIOS successfully updated once when I stroke CTRL+C in 10s after the update process started. It was definitely a wrong decision but I was lucky. It took the machine like 10 minutes to reboot after the update and I thought it must be dead.
Set Dell OEM in iDRAC using ipmi
Referring to http://sourceforge.net/projects/ipmitool/files/ipmitool/1.8.13/, new sysinfo interface was added in 1.8.13 but the stable(wheezy) version is 1.8.11.
So the first thing to do is install a newer version of ipmitool. Make sure you have correctly set testing(jessie) repository and the priority preferences.
$ apt-cache policy ipmitool ipmitool: Installed: 1.8.11-5 Candidate: 1.8.11-5 Version table: 1.8.14-4 0 750 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages *** 1.8.11-5 0 995 http://ftp.us.debian.org/debian/ stable/main amd64 Packages 100 /var/lib/dpkg/status
Install the 1.8.14 version from jessie repo.
sudo apt-get install ipmitool/jessie
After this, you should be able to execute some commands using ipmitool. The following command uses OpenIPMI kernel interface to read the management controller data.
$ sudo ipmitool -I open mc getsysinfo os_name Linux
Download the init script here: exchange-bmc-os-info
In default case, the kernel will set default values through IPMI to
iDRAC. This script will collect distribution and kernel infomation mainly
/etc/lsb-release. Then it uses
setsysinfo to change values in iDRAC.
If you have installed "Dell OpenManage Server Administrator", then it is possible that this script won't work.
The reason is:
- Kernel will install the module
ipmi_sifor the first time at boot time and creating a kernel thread
kipmi0. Then the script
exchange-bmc-os-infois able to change the BMC values.
OMSA's init script
/etc/init.d/dataengwill try to unload and load again the module
/etc/init.d/instsvcdrv. I still can't figure out how OMSA use this script but simple print test shows someone invokes the script similar to
So, the second load of kernel module resets the values set previously by
My solution is remove the operations for disablethread. Change the file
/etc/init.d/instsvcdrv as follows:
disablethread) # instsvcdrv_openipmi_force_thread disable $2 # EXIT_STATUS=$? EXIT_STATUS=0 ;;
More problems and solutions can be found OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)