mick.rip

The hidden HP setting that lets my Z440s boot unattended

My two HP Z440 Proxmox hosts stopped at every POST warning and waited for a human. A two-stage setting HP ships but does not show made them carry on by themselves.

I run two second-hand HP Z440 workstations as Proxmox hosts. They are cheap, quiet enough, and still useful. They also shared one terrible server habit: every boot stopped at a POST warning and waited for someone to press Enter.

The warnings were real. Both machines are missing hardware HP expects to find, the memory fan and the front audio assembly, so the firmware reported the 517 and 520 memory-fan messages and the 917 front-audio message, then stopped. Under a desk, that is a shrug. In a closet, it means an outage, a kernel update, or a remote reboot can leave a host sitting at POST forever.

The obvious fixes were not fixes

  • Install the missing parts. That is the correct repair, and it is still on the list. It did not help me reboot safely that evening.
  • Intel AMT. Both boards have it, and in theory it offers a remote console. I never verified it can send input at this particular pre-boot screen, and even if it can, recovery would still depend on someone connecting and pressing a key.
  • A small USB device left plugged in, pretending to be a keyboard. It would probably work. I did not want permanent hardware whose only job is to dismiss a warning.
  • Modify the firmware. A read-only look at HP’s image made the cost obvious: compressed UEFI modules, checksums, signatures, recovery logic, and no proven safe place to change anything.

The useful discovery was much less exciting. HP had already built the behaviour I wanted into the stock firmware. It just does not show you the switch.

HP hides the second half of the setting

On Linux, the hp-bioscfg driver exposes HP’s supported firmware settings under:

/sys/class/firmware-attributes/hp-bioscfg/

One of them was already there:

Advanced Error Control

Its values are Disable and Enable. A second setting exists in the firmware but was not listed yet:

Accept Liability for Circumventing POST Error Messages

The name is not subtle. The two controls are a deliberate two-stage process. Enable advanced error control, reboot, and HP exposes the liability setting. Accept it, reboot again, and POST shows its errors for about 10 seconds and then continues without input.

The exact sequence I tested

I ran this from a root shell on Z440s with BIOS M60 v02.62 and no setup password. On these machines the driver still insists on a non-empty value in its transient current_password attribute, so none below is a placeholder, not a BIOS password. If your machine has a setup password, do not copy that line.

First, the visible setting:

base=/sys/class/firmware-attributes/hp-bioscfg

printf none > "$base/authentication/Setup Password/current_password"
printf Enable > "$base/attributes/Advanced Error Control/current_value"
cat "$base/attributes/Advanced Error Control/current_value"

The readback said Enable. Reloading the Linux driver did not reveal the second setting, so the machine needed a reboot. That first reboot still stopped at the warnings and needed one last Enter.

When the host came back, the number of exposed firmware settings had gone from 221 to 222. The new one showed Decline as its current value and Decline;Accept as its options.

I accepted it:

base=/sys/class/firmware-attributes/hp-bioscfg
setting="Accept Liability for Circumventing POST Error Messages"

printf none > "$base/authentication/Setup Password/current_password"
printf Accept > "$base/attributes/$setting/current_value"
cat "$base/attributes/$setting/current_value"

The readback said Accept. I rebooted again and left the keyboard alone.

The warnings appeared. Ten seconds later the machine carried on booting by itself. I repeated the whole sequence on the second Z440 with the same result. Both Proxmox hosts and their containers came back normally after the unattended test boots.

The 10-second wait is fixed

The Z440 firmware has a setting called POST Delay (in seconds), but it does not control this screen. The error path uses its own fixed 10-second delay. Pressing Enter skips it, and I found no supported setting that shortens the automatic wait.

Ten seconds is fine. The difference between 10 seconds and forever is the whole point.

This bypasses errors, it does not repair them

There is a real tradeoff. The policy applies to all six of HP’s POST error classes, not only the warnings my machines show today. A future critical fan or thermal fault could also continue after 10 seconds if HP routes it through one of those classes. I did not test such a fault.

I accepted that risk for two monitored homelab hosts. I would not apply it blindly to a machine where a missed hardware warning could cause damage. The proper repair is still to install the missing parts and make the errors go away.

For now, both Z440s recover after a power failure, reboot after updates, and return to service without anyone standing in front of them. No firmware patch, no remote-control trick. Just a setting HP shipped and never put in the menu.