HP ProLiant disk failure, proceed or do not proceed

You may have a spare (replacement) drive whose size in sectors is slightly less than the original drive.

What operating system are you using? We can look at the hpacucli output to determine this for sure.

I will update this answer once we get more information.

Edit:

See my answer on: Smart Array P400i Physical Drive failed after being replaced for the tool download link for Windows 2008...

I'm specifically looking for the output of ctrl all show config.

Edit:

Now that I've seen your hpacucli output, you're in an incredibly rare situation.

  logicaldrive 1 (68.5 GB, RAID 1, Interim Recovery Mode)

  physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SAS, 73.5 GB, OK)
  physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SAS, 72 GB, Failed

Your original 72GB drives were actually larger than 72GB. As you can see, your healthy disk is a 73.5GB disk. HP changes disk manufacturers during the product lifetime, keeping the same spare part numbers. In this case, the replacement sent to you is a true 72GB drive. The rebuild would definitely not work.

The only thing that can fix this one is an equal or larger-size physical drive. Simply send this output to HP and ask for a 146GB disk if you're under warranty. If you're not under warranty, just get a 146GB disk and it'll rebuild as a "68.5 GB" RAID-1 member.

Also, ask for a 10k RPM 146GB disk. Your old 72GB disk is a 10k RPM (which was discontinued in that capacity LONG ago). The HP replacement is a 15k RPM drive.

So, after bringing a third system into the mix, and experiencing the same issue, we began to question the environment. I dug up a copy of the HP ProLiant Servers Troubleshooting Guide and found the POST problems flowchart shown below.

Carefully running through the steps in the chart, we realized that the one constant across all of the servers was a KVM switch attached to the data center crash cart. This was a consumer-class USB-enabled KVM. As per the highlighted node in the flowchart, Do you have known good KVM?, I could not answer conclusively.

So, we unplugged the servers from the KVM switch and ran an automated boot, sleep 300; reboot sequence in rc.local. The servers had no issues with this, regardless of the normal DIMM, low-voltage DIMMs, PSU wattage, etc.

This was all the result of a poor interaction with a USB KVM switch. By virtue that this was the console, it ensured we'd see the failure if we were looking for it. Self-fulfilling...