DEV Community: LK Wood IV

Raw data is useful only when the caveats travel with it

LK Wood IV — Sun, 20 Sep 2026 08:03:54 +0000

When comparing public benchmark datasets, the method and limitations should travel with the download. That is the point of the TechFuelHQ dataset hub: the evidence trail is part of the data.

Use it this way:

Open the dataset page before the file. Check the collection date, test setup, attribution, correction history, and dataset-specific license.
Download the CSV or JSON. CSVs work in a spreadsheet or with pandas; JSON works well in scripts and small tools. Keep blanks as blanks instead of silently converting “not measured” into zero.
Follow the reproduction material. Depending on the release, that may be an evidence manifest, a corpus/scorer README, or a Python runner with per-repetition output. Read code before running it and preserve the documented hardware, model, and settings when comparing results.
Cite the dataset version and capture date in anything you publish.

The hub currently includes first-party GPU and local-LLM measurements, Home Assistant voice results, component-reference JSON, and price-observation CSVs. A price row describes its capture date; it is not a live-price claim. The PC-builder reference data stores compatibility attributes and source pages without storing prices.

Browse or download the files.

Disclosure: This is my site. This post was prepared and checked by AI agents; the file types and resources described here were checked against the published hub.

How to Test a UPS: Charge Is Not Health

LK Wood IV — Wed, 16 Sep 2026 19:31:55 +0000

The number on the front of a UPS is a charge reading. It is not a health reading.

A unit showing full can drop the load the moment it transfers. The display will have been telling you everything was fine right up until the instant it stopped being fine, and it was not lying — it was answering a different question than the one you thought you were asking.

That gap between charged and working is the whole subject here. Sizing the unit is settled territory: VA against watts, runtime against your shutdown window. This is about what comes after you have bought the right size — proving it does the job, on a schedule, before the power goes out and proves it for you.

The built-in self-test is not a runtime test

Most units test themselves. The test covers less than the name suggests.

Schneider's documentation for the Smart-UPS line says the unit self-tests when you switch it on and every two weeks after that, and that during the test it runs on battery for approximately ten seconds (Schneider Electric FA405317). The Back-UPS line runs the same ten seconds on a different clock — Schneider describes the automatic test as happening every seven days after the unit is powered on — and its replace-battery alarm is framed against a standard two-minute runtime limit (Schneider Electric FAQ000267818).

Ten seconds is a genuinely useful test of one thing: the transfer relay closes and the inverter comes up. Keep it enabled. But read what it is measuring. A battery that has lost most of its useful capacity will hold ten seconds without complaint, and it will hold two minutes for a while after that. By the time the automatic test starts failing, you have already been running on a battery that would not have finished a shutdown.

Charge is a percentage. Capacity is minutes. The panel shows you the first one and you need the second one.

An untested UPS is a surge protector with a battery in it

So test on a schedule, and make it a real test.

Connect the load the unit actually protects. Pull the input cord. Watch what the load does at the moment of transfer, and time how long the battery holds before the shutdown you configured actually fires. That one pull exercises the transfer, the inverter, the battery under its real load, and your shutdown chain, in the order they will happen for real.

Nothing else does. A ten-second self-test skips the load. A runtime figure from a spec sheet skips your gear. The UPS runtime calculator will model the curve for you, and the model is worth having as a starting expectation — but a modelled forty minutes and a measured forty minutes are not the same claim, and only one of them is about the battery currently sitting in your rack.

If you would rather not pull a cord on live equipment, NUT will start a deep battery test on hardware that exposes one:

upscmd -u <user> <upsname> test.battery.start.deep

test.battery.start.quick, test.battery.start.deep and test.battery.stop are all standard NUT instant commands (NUT instant command reference), and upscmd -l <upsname> lists what your specific unit supports (upscmd man page).

There is a second reason to test that has nothing to do with the battery. A UPS can fail in a way that takes the load down with it. That is a real failure mode, not a freak event. The box you bought to prevent an unclean shutdown sits in series with everything it protects, and the only way to find out how yours behaves when it goes wrong is to make it transfer while you are standing there rather than at 3am while you are not.

Pure sine, or don't put a server PSU behind it

This one has a mechanism, and the mechanism is published by the people selling the cheaper option.

CyberPower's explanation of its own PFC Sinewave line is that a simulated sine wave produces a zero-output state during the phase change — a gap in the waveform — and that this gap can interrupt equipment running an active-PFC power supply when the unit switches from mains to battery (CyberPower, PFC Sinewave Series).

Read where that failure lands. Not during a brownout, not on a slow degrade — at transfer. The single event the UPS exists to handle is the event a simulated-sine unit is worst at, and active PFC is standard in modern PC and server supplies; CyberPower's own page dates that transition to the last fifteen years.

Simulated sine into an active-PFC supply is asking for trouble on transfer. Pure sine for anything with a server PSU behind it.

USB and NUT, not a network management card

Network management cards cost absurd money next to the UPS they plug into. A UPS network management card is a separate accessory bought on top of the unit, and for a single-site homelab it buys network-side monitoring you can get from a cable.

USB plus NUT does the job and is what I'd run. Three pieces:

usbhid-ups should detect anything implementing the HID Power Device Class, with the amount of data varying by manufacturer and model. NUT lists all MGE, Dell and AMETEK Powervar USB models, the newer Eaton USB models, and specific models from APC, CyberPower, TrippLite, Belkin, Powercom and PowerWalker (usbhid-ups man page). Check your exact model against the compatibility list before you count on it.
upsmon watches for the critical condition — on battery, low charge — sets the forced-shutdown flag, and lets every machine it is monitoring run its own shutdown command with a delay you set (NUT configuration notes).
upscmd gives you the battery tests above and the alarm control below.

That is the entire feature set most homelabs wanted from the card.

If it can't trigger a clean shutdown of what's plugged into it, most of the value is gone. A UPS that only buys you a few minutes of uptime during which nobody is home to act is a very expensive way to delay the same unclean power-off. The shutdown chain is the product. Configure it the day the unit arrives, then test that it fires — which is the same plug-pull from two sections up, and the reason that test is worth doing properly.

The alarm will go off at 3am

It will. The alarm is standard equipment, and the first time it fires is the worst possible moment to be learning where the mute button is.

Decide now what you want it to do, and set it now. NUT exposes beeper.disable, beeper.mute, beeper.enable and beeper.toggle as instant commands (same reference), so this is one upscmd call, done while you are awake and thinking clearly about whether you actually want an audible alarm in that room.

Batteries are a consumable

Plan for the replacement rather than being surprised by it. Sealed lead-acid cells are on a several-year cycle, and third-party replacements are standard practice — not a corner cut.

Schneider puts most APC batteries at three to five years and notes that every 8°C (15°F) of extra operating temperature halves that life (Schneider Electric FA158934). That second figure is the one people miss. A UPS in a warm closet is not on the same schedule as the same UPS in a basement, and if you have put yours in the warm closet, the replacement year on your calendar is optimistic.

Which puts you back at the test. The only way to know where your battery is on that curve is to have measured it recently under load.

What I'd do: pure sine, USB, NUT, and a plug-pull on a schedule

Buy a pure sine wave unit sized to your load, connect it over USB, run NUT, and pull the plug on a schedule. No management card. That configuration covers the transfer, the shutdown, the alarm and the tests, and there is nothing left in the card that a homelab with one rack needs.

The plug-pull is the part people skip and the only part that produces information. Put it on a recurring reminder alongside whatever else you check, keep the number you measured, and compare it to the last one. When the measured runtime has fallen far enough that your shutdown no longer finishes inside it, buy cells — before the automatic self-test gets around to agreeing with you.

This is wrong for a few situations. Simulated sine into active PFC — do not, at any price. A consumer unit under a full rack, where the load is past what the unit is rated to hold and the runtime is theatre. And anyone who will not set up automatic shutdown, because at that point the money bought a surge protector with a battery in it, which is where this started.

Testing does not make a UPS more reliable. It tells you whether the one you own is still doing the job, which is a different and more useful thing than a green light. And none of it replaces keeping backups somewhere else — a clean shutdown protects the pool, not the data.

Originally published on techfuelhq.com.

How to Install Proxmox VE (2026): Install + Update Reference

LK Wood IV — Sat, 04 Jul 2026 16:35:39 +0000

Installing Proxmox VE is genuinely easy. The graphical installer is a few screens, and it writes itself to disk in a couple of minutes. What trips people up is not the install itself: it is the first fifteen minutes afterward, where a default install points at a repository you cannot use without paying, and the longer-term question of how you keep the thing updated once it is running.

This is the generic reference for both. It is hardware-agnostic on purpose: the steps below apply to a mini PC, a used office desktop, an old gaming rig, or a rack server. If you want a hands-on, click-by-click walkthrough on a specific small box, the Proxmox mini PC setup guide is the hardware-specific companion to this one. If you are still choosing hardware, start with the Proxmox hardware requirements. And if you already run VE 8 and want to jump to VE 9, that is a different, planned operation covered in the 8-to-9 upgrade gotchas.

Everything below is cited to the official Proxmox documentation. The current release as of this writing is Proxmox VE 9.2-1 (released May 21, 2026), built on Debian 13 "Trixie." If a command or file path is here, it is real and current for VE 9.

Part 1: The clean install (any hardware)

Step 1: Download and verify the ISO

Grab the latest Proxmox VE ISO from the official downloads page. As of June 2026 that is the VE 9.2-1 installer, about 1.7 GB.

Do not skip the checksum. The download page publishes a SHA256 value next to the ISO. After downloading, compute the hash and compare it to that published value:

# Linux / macOS
sha256sum proxmox-ve_9.2-1.iso

# Windows (PowerShell)
Get-FileHash proxmox-ve_9.2-1.iso -Algorithm SHA256

If the two strings do not match, the download is corrupt or tampered with. Delete it and re-download. This takes ten seconds and it is the one verification step that matters before you write installation media.

Step 2: Write the USB installer

A USB stick is the standard install medium. The tool depends on your OS, and the official guidance is specific about which ones work:

Linux: use dd. Identify the USB device first with lsblk, then write with dd bs=1M conv=fdatasync if=./proxmox-ve_9.2-1.iso of=/dev/XYZ (replace /dev/XYZ with your actual USB device; getting this wrong overwrites the wrong disk).
Windows: Etcher works with no configuration. Rufus also works, but you must select DD mode when it prompts, not ISO mode.
macOS: convert the ISO to a raw image, then write it (see the official media-prep page for the exact hdiutil and dd sequence).

One specific warning from the docs: do not use UNetbootin. It is incompatible with the Proxmox installer.

Step 3: Boot the installer and pick your filesystem

Plug the USB into the target machine, power on, and bring up the boot menu (commonly F11, F12, or Del). Select the USB device, then choose Install Proxmox VE.

Two decisions matter. Target disk and filesystem: select the SSD or NVMe you want Proxmox on, and be careful not to pick the USB installer drive by accident.

Filesystem	When to choose it
ext4 (default)	Single-disk machine. Simple, fast, reliable, uses an LVM-thin pool Proxmox manages natively. The right first-install answer.
ZFS	Two or more drives and you want a mirror or RAID-Z, plus snapshots, checksums, and self-healing. Wants meaningful RAM for its cache.
XFS	Offered with LVM, but far less common in Proxmox setups than ext4.
Btrfs	A technology preview. Not recommended for a production-style install yet.

The official installer note is blunt that ZFS on top of any hardware RAID is unsupported and can cause data loss, so if you run ZFS, give it the raw disks. For a first build on one drive, choose ext4 and move on.

Network and password: set a hostname, then set a static IP outside your DHCP range so the web UI always lives at the same address. Set a strong root password. The installer builds a Linux bridge called vmbr0 on your first NIC so VMs and containers can reach the network. Click install; it writes to disk in a few minutes and reboots.

Step 4: Reach the web interface

Point a browser on another machine at the IP given during install, on port 8006:

https://your-ip:8006

Note the https and the :8006. Plain http or a missing port is the single most common "it didn't work" mistake, and the install is almost certainly fine. You will get a certificate warning because Proxmox uses a self-signed cert; accept it and log in as root.

Part 2: The first fifteen minutes (the repository fix)

This is the part generic install guides skip, and it is the one step every Proxmox install needs. A fresh install points apt at the enterprise repository, which requires a paid subscription. Without a key, every apt update ends in 401 Unauthorized and your package lists never refresh.

Proxmox VE 9 also changed the repository file format to the deb822 .sources format, so the files look nothing like the one-line sources.list entries from VE 8.

Disable the enterprise repository

Open the node shell (web UI, your node, Shell) and edit /etc/apt/sources.list.d/pve-enterprise.sources, adding a single line so it reads Enabled: no. That suppresses the enterprise repo without deleting it.

Enable the no-subscription repository

Create the no-subscription sources file with the exact deb822 contents the docs publish for VE 9:

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

You can do all of this from the web UI instead: node, Updates, Repositories, Add, pick No-Subscription, then highlight the enterprise row and click Disable. The GUI writes the same files for you.

The no-subscription repo ships the same packages as enterprise without a key. Proxmox is explicit that these are "not always as heavily tested and validated," so it is fine for a home lab but is not their recommendation for production.

Run the first update

apt update
apt full-upgrade

Use full-upgrade, not plain upgrade, more on why in Part 3. Reboot if a new kernel was installed. The subscription-nag popup at login is cosmetic; click OK and move on.

Part 3: How to update Proxmox over time

Once Proxmox is running, "update" means two very different things, and conflating them is where homelabs get into trouble.

Routine updates (within a major version)

Normal maintenance, keeping VE 9 current as point releases ship (9.1 to 9.2). From the shell, apt update then apt full-upgrade; or in the web UI, select the node, open Updates, Refresh, then Upgrade.

Why full-upgrade and not apt upgrade? Plain upgrade refuses to install anything that requires a new dependency, and on Proxmox that means the kernel and the pve-manager stack get held back, exactly the packages you want updated. full-upgrade installs them. A reboot is only needed when a new kernel arrives.

Major upgrades (across major versions)

Moving from VE 8 to VE 9 is a different animal. It crosses to a new major version, which moves the underlying Debian base and kernel, and it carries real breaking changes: LVM autoactivation defaults change, network interfaces can be renamed, and PCI passthrough can need attention. That is a planned event with its own pre-flight checklist: back up first, run the pve8to9 --full checker, pin your NIC names, and have console access that is not the web GUI. The full procedure is in the Proxmox VE 8 to 9 upgrade guide. VE 8.4 gets security and bug-fix updates until August 2026, so there is no pressure to rush.

Common install gotchas

apt update returns 401 Unauthorized. You are still on the enterprise repository. Disable it and enable pve-no-subscription (Part 2). This is the number-one new-user issue.
The web UI will not load. You used http instead of https, or forgot :8006. The correct URL is https://your-ip:8006.
VMs will not start ("KVM not available"). Hardware virtualization (Intel VT-x or AMD-V) is disabled in the BIOS/UEFI. Reboot into firmware and enable it, plus IOMMU (VT-d / AMD-Vi) if you plan passthrough.
You picked ZFS and the host feels short on RAM. ZFS reserves RAM for its cache. Size it deliberately.
You accidentally installed onto the USB stick. Always confirm the target disk in the installer is your internal SSD/NVMe.

After the install: what to build

For a screen-by-screen walkthrough on a specific small machine, follow the Proxmox mini PC setup guide.
For each service, decide between a container and a full VM. The LXC vs VM in Proxmox guide has the decision tree.
To size your box, how many VMs and containers your RAM and cores can support with ZFS overhead included, the Proxmox capacity planner does the math.

The install is the easy part. The repository fix is what makes updates work, and knowing the difference between a routine update and a major upgrade is what keeps the box healthy for years.

Sources

Originally published at techfuelhq.com.