2

I recently purchased an HP DL380 G6 for homelab-esque usage, and I've found a few issues that I think are all caused by a nonresponsive iLO 2:

  1. POST takes several (e.g. 5) minutes, longer than would be expected.
  2. On POST, after the splash screen, it says Warning: iLO 2 not responding. System health monitoring has been disabled.
  3. On a CentOS 7 live USB, udev hangs while detecting devices, and dmesg shows that it tries to talk to the IPMI interface and times out.
  4. Booting into an HP SPP hangs after selecting Automatic/interactive modes, probably because it tries to detect the iLO and hangs.
  5. Fans constantly run at 100% speed.
  6. The front-panel system health LEDs (e.g. showing fans, RAM slots, CPUs) are all off except for the Ethernet 1 light (which is plugged in).
  7. Normally the POST screen is supposed to show something like "Press F8 to Enter iLO Rom-Based Setup Utility", I think, but that does not appear, so I can't configure iLO.
  8. iLO does not show up on the network at all. No pings, no IPs, nada.

Hardware summary

  • HP DL380 G6, on latest BIOS update, other firmware not updated
    • 48 GB RAM
    • 2x Intel Xeon X5560 CPUs
  • P410i integrated RAID card, LSI 9211-8i HBA card installed on latest (P20) IT firmware
  • Initial iLO version: unknown. (I upgraded it to 2.33, unsure if successful.)

My attempts to resolve the problem

(None of these have worked.)

  1. According to this site, power cycling and doing a full power flush usually fixes iLO not being responsive. In my case, I've unplugged the power cord and held down power for 30 seconds, but on the next boot, the iLO remains unresponsive.
  2. I updated the BIOS to the latest version. This changed nothing.
  3. I updated the iLO firmware to the latest version, v2.33, from CentOS 7 using the HP SPP ISO burnt onto a USB drive. This worked, but it had to flash using direct mode, and even after doing another power cycle, the iLO remains unresponsive.
  4. Fiddled around with the iLO Security DIP switch, setting it both on and off.
  5. Reset NVRAM (and thus iLO) settings by removing the button battery in the server and then replacing it.

What I haven't tried yet

I don't currently have physical access to the server, but I will tomorrow, at which point I'll try the following:

  1. According to a sketchy Russian site, perhaps flashing iLO firmware 1.77 in direct mode from the 8.50 Firmware CD can fix it.
  2. I haven't removed the power supplies physically from the server during my previous power flushes, so it's possible that the iLO somehow retained power and didn't reboot?! Not sure if this is actually important, though.

If anyone has experienced this issue or has any advice on how to deal with it, it would be greatly appreciated.

Pneumaticat
  • 121

2 Answers2

0

If you bought it intact there should be a label on the inside of the cover for it. It should show you a switch bank with some switches to clear CMOS (reset defaults). Its a a multi-switch combination and when you power it on you get a beep code, then you set them back after you power back off.

Lots of stuff you describe can be set up in BIOS and iLO (you can configure iLO to disable iLO). One way to get it back is to restore defaults, but that comes with its own set of risks. Sounds like you are at least booting now.

BTW removing the coin battery can clear CMOS, but if you do it too quick, I doubt all the bits will clear. We used to ground it, or try to close the power rail. You'll be surprised how much capacitance is in system.

Dan
  • 111
0

This is an old question and a very old server, but maybe this will help someone.

For me updating iLO2 to 2.33 made the iLO unaccessible. The server was far away, but I had access to the running OS and the network. Downgrading to 2.32 solved everything. I could do it via TFTP load that I initiated with hponcfg.

danca
  • 1