I have an HP Microserver (Gen8) running Debian Jessie. When I first set it up, I installed the optional HP daemons to see what benefit they gave. One, hp-health
, interfaces with the onboard iLO controller. I have since disabled the iLO because it requires a license to do anything useful, and I have no need of it. However, this has caused problems - the hp-health
package now will not update, and when trying to remove it, I get the following:
root@NAS:/home/gargravarr# dpkg --force-all -P hp-health
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: package is in a very bad inconsistent state; you should
reinstall it before attempting a removal
(Reading database ... 47028 files and directories currently installed.)
Removing hp-health (10.40-1815.49) ...
Trying to identify the Product Name...
ERROR: This server is NOT supported!
Error: No supported management controller found
invoke-rc.d: initscript hp-health, action "stop" failed.
dpkg: error processing package hp-health (--purge):
subprocess installed pre-removal script returned error exit status 1
Trying to identify the Product Name...
ERROR: This server is NOT supported!
Error: No supported management controller found
invoke-rc.d: initscript hp-health, action "start" failed.
dpkg: error while cleaning up:
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
hp-health
From the dpkg log, it seems like the init script is running hardware checks, failing to detect the iLO and determining it cannot run, thereby returning 1 to the calling command. Unfortunately, this means dpkg receives the exit code. Re-enabling the iLO controller means going into the BIOS and I am not able to do that. Instead, I tried adding an exit 0
into the init script immediately before the standard case
statement, but this seems to have done nothing. It's interfering with other package upgrades so it really needs to be uninstalled.
Okay, I was a bit hasty. As I wrote the question, I realised the init script must be performing the hardware checks before the case statement, so I looked back over it and found where the actual hardware check was done, added an
exit 0
there and sure enough the next run ofdpkg -P
succeeded. I'll mark the question as answered and leave it up in case anyone else encounters similar problems.