Updating the BIOS and deferring the CPU

The plan for this window was a BIOS update on one Proxmox node and a CPU replacement on the same node. I did the first and deferred the second. This post explains that split, what the window turned up afterward, and what I checked before calling it done.

Splitting the scope

The CPU replacement needs thermal paste, and I did not have any on hand. The BIOS update did not depend on the paste, so I ran it. I wrote the CPU upgrade down as a deferred item, with the reason next to it: the replacement waits until the paste is available.

That was a scope decision, not a setback. Doing half the work on schedule and naming the other half as deferred is better than holding the whole window for a part I did not have.

What happened in the window

The steps went in this order:

I captured a preflight baseline and exported the VM configurations.
I wrote a rollback runbook for the node.
I tested DNS failover before the maintenance started, so I would know the baseline worked before anything changed.
I updated the BIOS. The node booted successfully.
The VMs on the node returned to service.
I validated the DNS virtual IP and both Pi-hole VMs, then the other services that depend on them.

The backup storage on that node did not come back cleanly after the reboot. I investigated it and recovered it. The record I wrote does not name a root cause, and I am not claiming one here. What I can say is that the window did not end at “the host came back up”. It ended when the storage was working again.

The adapter warning

During the BIOS update, the firmware reported a warning about the AC adapter’s wattage and type. The adapter in use has been stable for that node in day-to-day operation. I am recording it as a documented hardware finding. It is not resolved, and it does not block work on the other nodes.

Before the CPU replacement happens, the plan calls for a short go/no-go check. The services that other parts of the lab depend on stay online during that check.

What I checked, and what I did not claim

Checking that the node booted is not the same as checking that the lab works. I looked at these after the window:

the DNS virtual IP answered;
both Pi-hole VMs were up and validated;
the other VMs and services on the node came back and were checked.

Failover itself was tested before the window, not after it. I have not claimed a post-maintenance failover test that the record does not show.

I also did not claim three things. The CPU was not replaced. The adapter warning was not resolved. The storage problem’s root cause is not proven by the closeout record alone.

The lesson

Split maintenance scope on purpose. If a dependency is missing, do the work that can safely happen now and write the rest down with its reason. The CPU upgrade is recorded as deferred, not dropped.

Check recovery beyond power-on. A host that boots has not proven much. Test the things its users actually depend on, and do that test before the change too, so you know the baseline was good.