Built this one on 2026-10-29: Debian 13, hardened, reboot-tested. Monitoring stack itself — LibreNMS doing SNMP against the SG300 and OPNsense, central syslog, NetFlow/Zeek later — isn't installed yet. That's still ahead of me, not behind me.
Why this box and not the t655
Swapped roles with the t655 the same day. This one has a real SATA SSD, and that handles the constant log/graph writes a monitoring host generates far better than the t655's eMMC-style flash would. The other reason: this box's BIOS situation matters less sitting inside the network than it would at the edge. Worth remembering that logic next time I'm deciding which box gets which job — storage type and exposure, not just whichever one's free.
The BIOS flash fight
Before: AMI M43 v01.09 (06/09/2021). After: M43 v01.24, via HP SoftPaq sp173784. This took three tries.
First try: HP's supported flash tool wants Windows running on the t640 itself, not on something else pointed at it. I ran the updater from a Windows laptop anyway, and it tried to load a driver that Windows' own vulnerable-driver blocklist blocked. I left the blocklist on. Turning off a security control globally to solve a problem on one box is never the right trade, even when it's inconvenient.
Second try: plain F10 → Flash System BIOS with a hand-built USB layout. Failed with a file missing or damaged error.
Third try, the one that worked: HP publishes a Windows-only "ToolLess" procedure, so I translated each step to its Linux equivalent instead of giving up and finding a Windows box.
- Where the Windows steps copy files into the EFI System Partition with
xcopy, I did the same withcp -r. - Where the Windows config utility sets the
BIOS Updateflag to Auto, I used the F10 BIOS Config Utility to save the current settings to a file on the ESP instead.
That settings file turned out to be UTF-16LE with a BOM — plain grep saw nothing in it. Converted it with iconv, flipped the BIOS Update setting from Disable to Auto in the converted text, converted it back, and made sure the BOM was still there before saving. Restored that file from the F10 menu, saved, and on reboot HP's own flasher ran from the EFI partition. Once it was done I reversed the same edit to put BIOS Update back to Disable.
Lesson for later: HP's "Windows-only" tools are mostly just Windows-only packaging. The actual operations — copy files, edit a settings file, trigger a flasher via firmware menu — have Linux-side equivalents if you're willing to read the Windows procedure as a spec instead of a script.
The scare afterward
After the flash, nothing would boot — not the existing Debian install, not the Debian installer either. Kernel hung right after EFI stub: Measured initrd data into PCR 9. Tried nomodeset, tried removing vga=788. Neither helped.
What fixed it: F10 → Apply Defaults and Exit. That's it. Lesson, stated plainly so I don't relearn it the hard way: after an HP BIOS flash, load defaults before blaming the OS.
Known noise, logged and ignored
There's a recurring ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT ... \_SB.WMID.WQBE at boot. Traced it to a bug in HP's own WMI ACPI tables (the hotkey/BIOS-settings interface), not anything I did. It's logged, ignored, and hidden from the console since I already quieted boot output via a sysctl drop-in for other reasons.
What's actually running vs. what isn't
Hardening is in: root login disabled, sudo-only access, PasswordAuthentication no and PermitRootLogin no in sshd, verified by opening a second session before closing the first one I was hardening from — the one rule that actually matters when you're editing sshd config remotely. Apt is on unattended-upgrades. DHCP reservation for this box is locked in as of 2026-10-29.
None of that is the job yet, though. LibreNMS and SNMP polling against the switch — not done. The rsyslog receiver for switch and firewall logs, with rotation set up from day one instead of bolted on later — also not done. The box is ready to be a monitoring host. It isn't one yet.