This server was delivered with ESXi preinstalled
Who is delivering "preinstalled" ESXi with incompatible NIC and unable to even boot past IPMI module load?!?
Anyway, It hangs on that module for over one hour and then it continiues.
I guess for now we have to live with a very slow post until supermicro comes out with a BIOS fix.
I'm pretty sure if you add the actual SuperMicro IPMI module, this problem will go away. If you get the version with KVM capability then you get a significant benefit ("lights out" remote keyboard/mouse/video access). I have one of those in my main test box and it's a real boon. Unlike most of the OEM KVM solutions, this one actually works. I thought it was well worth the price of around $100.
But throwing hardware at a software problem is irksome. How can you fix this in software?
I think there must be more graceful ways to do this, but since I don't know them, here's the brain surgery way... Actually four ways since 3.5 and 4.0 differ, and ESXi differs from ESX, on this issue.
To disable the IPMI driver on ESXi 3.5 (booting from USB key):
#. shut down the ESXi host.
#. remove the USB key.
#. take it to a host which can mount FAT filesystems read/write and which is happy with tar format (most Linux boxes, or Windows with Cygwin or other Unix emulation environment).
#. you will be modifying environ.tgz from the bootbank. The bootbank is usually partition 5 (according to Linux fdisk), but may be partition 6 depending on system history. Find environ.tgz on one or both of these banks.
#. extract it:
# mkdir -p /root/esxi-environ
# cd /root/esxi-environ
# tar xzf /path-to-mounted-bootbank/environ.tgz
#. edit the file sbin/config:
# sed -i '/loadIPMI = /s/1/(disable IPMI)/' sbin/config
#. repack the environ tarball:
# tar czf /path-to-mounted-bootbank/environ.tgz *
#. repeat for environ.tgz on the other bootbank, if both exist.
#. unmount the USB key.
#. carry it back to the ESXi host, boot up.
To disable the IPMI driver on ESX Classic 3.5:
#. login as root on the service console.
#. disable the driver with:
# chkconfig ipmi off
#. if HP Insight Manager is installed, you may need to remove HP's IPMI driver:
# rpm -e hp-OpenIPMI
#. other management agents may explicitly start IPMI by running e.g. service ipmi start; if so, you may need to make additional changes to stop that. One way would be to add an "exit 0" to the top of /etc/init.d/ipmi.
#. IPMI will be disabled on the next reboot.
To disable the IPMI driver on ESXi 4.0 (booting from USB key):
#. turn on the "sticky bit" on /etc/vmware/init/init.d/72.ipmi:
# cd /etc/vmware/init/init.d
# chmod +t 72.ipmi
#. edit the file to disable IPMI:
# sed -i '/Exec/s/^/return ${SUCCESS} # disable IPMI\n\n/' 72.ipmi#. IPMI will be disabled after the next graceful shutdown and reboot.
To disable the IPMI driver on ESX Classic 4.0:
#. login as root on the service console.
#. edit /etc/vmware/init/init.d/72.ipmi to disable IPMI:
# cd /etc/vmware/init/init.d
# sed -i '/Exec/s/^/return ${SUCCESS} # disable IPMI\n\n/' 72.ipmi#. IPMI will be disabled after the next reboot.
If you are booting ESXi from a hard disk (ESXi Installable), you need to do the same edits as in the ESXi instructions above, but the file locations may differ. I don't have an Installable setup here to check the details.
Disabling IPMI has the following effects:
#. OEM management agents running on the host will no longer get IPMI-based information like CPU temperatures, fan speeds, power alerts.
#. Remote management consoles may or may not lose this information. They can get IPMI readings from daemons running on the host, but they can also talk to a host's IPMI BMC (Baseboard Management Controller) directly over TCP/IP, bypassing the host OS, in which case they can still get this information. All of the management consoles I'm familiar with use agents on the host, but they might also be programmed to fall back to direct IPMI-over-TCP access.
#. VI Client "Health Status" information will be reduced (losing the same CPU temperatures, fan speeds, event alerts, etc.).
#. On some hosts, kernel threads named "kipmi0" and possibly "kipmi1" will no longer be created. These kernel threads can consume significant CPU on some hosts (less than it looks in top, since they run at lowest possible priority and will be preempted by anything else that needs to run).
Hope this helps,
>Bela<
Message was edited by: filbo: added "effects of disabling IPMI" topic.